109423 - FreeType2 on Linux Mozilla with/without Xft

Status: RESOLVED FIXED

(Core :: Internationalization, defect)

Description

[kill this account]

This bug is a forum to discuss the advantages and disadvantages of using
Xft to access FreeType2 on the Linux/Unix Mozilla builds.

This is a serious issue and deserves to be addressed as such.

Comment 1

[kill this account]

My criteria is:

 1) Does it fit well with the Linux/Unix mozilla code?

 2) Does it support the Mozilla product adequately?
    *especially* internationalization (i18n) since the i18n
    department is responsible for text and this is a text
    issue.

 3) Does it meet Mozilla performance/bloat needs?

 4) Is it stable and robust enough to use?

Comment 2

[kill this account]

 5) Does it support the Linux/Unix platforms Linux/Unix Mozilla supports?

Comment 3

[kill this account]

Anyone else have thoughts on the criteria for using/not-using Xft to
access FreeType2?

This will set the ground work for this discussion.

Comment 4

[keithp]

I'd like to reframe the discussion to how X font handling can be changed to most
effectively support Mozilla and other applications.

The most important requirement is that Mozilla share font configuration and
naming with other applications in the system. A secondary desire is to share as
much underlying code as reasonable with other applications, both to reduce the
work needed for Mozilla and to provide a significant source of ideas and testing
for that infrastructure.

To the end of a shared configuration mechanism, I'm splitting that portion of
Xft into a separate library so that all font consumers on the system can share
it, instead of being limited to those connected to the display through Xft.
While Xft will continue to expose the existing API to remain compatible with
existing applications, those routines are simply wrappers around functionality
to be provided by a non-X dependent library.

The separate issue of using Xft for accessing the Render extension should be
addressed by investigating how Xft needs to be enhanced to fully support Mozilla
text output requirements.  We've already learned a lot about this and I've
started implementing some of it.  There are two areas of improvement: caching
and fontset support.

Caching is largely transparent to applications; there may be some minor changes
to the API to ensure that applications access cached objects in appropriate
ways.  Xft should cache both FreeType font objects and server-side glyphs;
server-side glyph caching is quite easy to implement, the only real issue is how
the library can learn the limits of the X server.  I suspect we'll need to
provide some manual configuration mechanism which is not my first choice.

As most fonts don't support enough Unicode for truely international output,
there needs to be support for using multiple fonts to fill in unavailable
glyphs.  While I'd love to leave this to a higher layer, I was chatting with
Owen Taylor at ALS and we came up with a mechanism that needs support within the
font matching code. The essential requirement is that the font used for any
particular glyph should be the same regardless of what glyphs have appeared
before in the document, and it turns out to be relatively easy to do this within
the font matching code.  As this font matching code is migrating from Xft to a
separate library, it may be that this particular issue is more pressing than the
caching issue above.

Comment 5

[R.K.Aa.]

Please keep AA fonts out of the UI at least. At those sizes glyph edges tend to
bleed so bad they get unreadable. Big fonts are beautiful when AA'ed - small
look like wet wool.

Comment 6

[keithp]

One of the significant advantages for having Mozilla share font configuration
and customization mechanisms with other applications is that user preferences,
such as which sizes should be anti-aliased, will not need to be customized
specifically for Mozilla.  Additionally, using Xft would automatically give
Mozilla the advantages of sub-pixel decimation for improved text display on
digital LCD monitors; a capability which sways many people in favor of AA text
at all sizes (given reasonable fonts).

Comment 7

[kill this account]

> I'd like to reframe the discussion to how X font handling can be changed to 
most
> effectively support Mozilla and other applications.

This is an entirely different matter quite suitable for a long term
discussion, say over a year or more. This is not suitable for this year
or next year or maybe even the year beyond. Even if we had a working
design it will take a few years to get common libraries on to the bulk of the 
Linux and Unix systems. This should be covered in a different (long term) forum.
Once the common code is ready Mozilla should then consider using it.
Until that happens I want Mozilla to benefit from better font support
available with TrueType fonts.

Netscape learned a hard lesson with Java. Netscape made Java popular but
to Netscape's detriment. While I want Xft to succeed and become a
standard I want to hear the advantages *to* *Mozilla* not to Xft.

> The most important requirement is that Mozilla share font configuration and
> naming with other applications in the system. 

As long as the Mozilla user can control their fonts within Mozilla.
Requiring a user to go outside Mozilla to configure fonts (especially 
without a GUI) would be a very major loss of functionality.

> A secondary desire is to share as much underlying code as reasonable with 
> other applications, both to reduce the work needed for Mozilla and to provide 
> a significant source of ideas and testing for that infrastructure.

Again this is suitable for a long term discussion and should be covered
in a different forum. Once the common code is ready Mozilla should then 
consider using it.

> To the end of a shared configuration mechanism, I'm splitting that portion of
> Xft into a separate library so that all font consumers on the system can share
> it, instead of being limited to those connected to the display through Xft.
> While Xft will continue to expose the existing API to remain compatible with
> existing applications, those routines are simply wrappers around functionality
> to be provided by a non-X dependent library.

What API do you propose to allow applications to individually modify
the font configuration?

What will/should the GUI look like?

> The separate issue of using Xft for accessing the Render extension should be
> addressed by investigating how Xft needs to be enhanced to fully support 
Mozilla
> text output requirements.  We've already learned a lot about this and I've
> started implementing some of it.  There are two areas of improvement: caching
> and fontset support.

I will address this and a variety of other related issues in a later (longer)
addition.

> Caching is largely transparent to applications; there may be some minor 
changes
> to the API to ensure that applications access cached objects in appropriate
> ways.  Xft should cache both FreeType font objects and server-side glyphs;
> server-side glyph caching is quite easy to implement, the only real issue is 
how
> the library can learn the limits of the X server.  I suspect we'll need to
> provide some manual configuration mechanism which is not my first choice.

Mozilla is under tremendous pressure to reduce memory footprint. Please
be prepared to discuss how an Xft application can control bloat (eg: release
unused memory).

> As most fonts don't support enough Unicode for truely international output,
> there needs to be support for using multiple fonts to fill in unavailable
> glyphs.  While I'd love to leave this to a higher layer, I was chatting with
> Owen Taylor at ALS and we came up with a mechanism that needs support within 
the
> font matching code. The essential requirement is that the font used for any
> particular glyph should be the same regardless of what glyphs have appeared
> before in the document, and it turns out to be relatively easy to do this 
within
> the font matching code.  As this font matching code is migrating from Xft to a
> separate library, it may be that this particular issue is more pressing than 
the
> caching issue above.

Let me state this slightly differently:

  most font will *never* support enough Unicode to be truly international

Netscape and Mozilla have been working on this for years.

Mozilla has a well debugged code for the lower level part of this (handling
the font lists) and a fairly well debugged upper level (generating the font
lists). Getting this to work was a very big job.

I certainly do not want to casually trade a working piece of code for an
untested (much less not even built yet) piece of code.

> One of the significant advantages for having Mozilla share font configuration
> and customization mechanisms with other applications is that user preferences,
> such as which sizes should be anti-aliased, will not need to be customized
> specifically for Mozilla.  

I think it should be the users choice (not the developer's choice) to have 
separate AA setting for Mozilla if they want. I certianly do not see dictating 
this at the system level as attractive.

> Additionally, using Xft would automatically give
> Mozilla the advantages of sub-pixel decimation for improved text display on
> digital LCD monitors; a capability which sways many people in favor of AA text
> at all sizes (given reasonable fonts).

Is "sub-pixel decimation" part of Render or FreeType2? 

Or does it only exist in Xft?

Comment 8

[keithp]

> Netscape learned a hard lesson with Java. Netscape made Java popular but
> to Netscape's detriment. While I want Xft to succeed and become a
> standard I want to hear the advantages *to* *Mozilla* not to Xft.

For the Mozilla user, the ability to have Mozilla automatically adopt the font
configuration from the rest of the desktop should be compelling enough; a
multiplicity of independent configuration mechanisms has been a long failure of
the X environment.  In addition, I hope to convince various printing mechanisms
to be involved in this discussion; Qt already uses it and I believe Gnome-print
will as well.  Getting Ghostscript to adopt this will require the cooperation of
Raph who is rather busy these days.

(In the interests of brevity, I will use 'Xft' to refer to Xft and the separate
font configuration library currently known as 'fontconfig')

The important issue is to allow Mozilla to use a common configuration database.
 Xft does not provide any configuration interface for the user; that is done
within the various applications. I suspect one important piece of information
here is what exactly is to be configured.  Xft is interested in three separate
configuration issues: locating font files, providing font aliases and adjusting
the rendering results.  The Xft configuration provides a list of directories
containing font files, a list of alternate names for each font and some simple
rules that adjust the rendering of glyphs.

> As long as the Mozilla user can control their fonts within Mozilla.
> Requiring a user to go outside Mozilla to configure fonts (especially 
> without a GUI) would be a very major loss of functionality.
Of course Mozilla can provide whatever level of configuration is necessary; many
users don't have another GUI available.

> What API do you propose to allow applications to individually modify
> the font configuration?

As I've said, the library interface itself is of significantly less interest
than the shared configuration.  I understand that some application developers
want an API to edit the configuration file, but unless the parameters of the
desired configuration modifications are specified, it's pretty hard to come up
with an API.

> Mozilla is under tremendous pressure to reduce memory footprint. Please
> be prepared to discuss how an Xft application can control bloat (eg: release
> unused memory).
There are essentially three pieces of separately cachable information -- the
server side glyph images, the local per-glyph metrics and the original TrueType
data itself.  Render provides client control over server-side glyph caching; Xft
can trivially count total server memory and discard glyphs.  As the per-glyph
metrics are available only through the library interface, Xft can internally
discard per-glyph metrics.  Whole TrueType fonts can be discarded with some
minor additions to the Xft API.  

These pieces are all straightforward, the reason they haven't been implemented
to date is that the conditions for deciding to discard information are not well
described; a workstation with several gig of memory will want to cache more data
than a remote terminal with tens of megabytes.  X doesn't provide any hint to
the remote capabilities of the display device and so I expect that we'll just
have to allow the values to be configured manually.

> Mozilla has a well debugged code for the lower level part of this (handling
> the font lists) and a fairly well debugged upper level (generating the font
> lists). Getting this to work was a very big job.
Xft will probably not provide code for selecting which font in a list is used
for each glyph; that requires significant interaction with the underlying text
data itself as one likes to preserve font apperance across multiple adjacent
glyphs.  It may be that the upper level code from Mozilla could be of use within
Xft; I'll go take a look at it.  

Certainly applications will not be forced to use this particular Xft interface;
the separation of  Xft from the font configuration mechanism provides
applications enough visibility into the database of avaliable fonts to perform
their own matching and selection.

> I think it should be the users choice (not the developer's choice) to have 
> separate AA setting for Mozilla if they want. I certianly do not see dictating 
> this at the system level as attractive.
You can assume that any configuration within Xft is bent entirely on providing
defaults which can be adjusted by the application.  The goal is to share
configuration which applications might not provide themselves, not to override
the application developers will.

> Is "sub-pixel decimation" part of Render or FreeType2? 
> 
> Or does it only exist in Xft?
The Render protocol provides for per-channel alpha compositing which forms the
underlying primitive for sub-pixel rendering.  Xft uses FreeType to transform
the glyph appropriately and then it filters the resulting images to create the
per-channel image.  Configuring this requires only a description of the
underlying sub-pixel geometry of the screen; if Mozilla shared the common
configuration mechanisms it would presumably be able to discover that
configuration and perform its own image generation.

Comment 9

[kill this account]

> The Xft configuration provides a list of directories
> containing font files, a list of alternate names for each font
> and some simple rules that adjust the rendering of glyphs.

I'd like to look at these. Would you kindly attach a URL referencing 
these APIs?

> > What API do you propose to allow applications to individually modify
> > the font configuration?
>
> As I've said, the library interface itself is of significantly less interest
> than the shared configuration.  I understand that some application developers
> want an API to edit the configuration file, but unless the parameters of the
> desired configuration modifications are specified, it's pretty hard to come up
> with an API.

Lacking an API that allows a user to control their font setting
I do not see how this is of much use to Mozilla.

> > Mozilla is under tremendous pressure to reduce memory footprint. Please
> > be prepared to discuss how an Xft application can control bloat (eg: release
> > unused memory).
> 
> There are essentially three pieces of separately cachable information -- the
> server side glyph images, the local per-glyph metrics and the original 
TrueType
> data itself.  Render provides client control over server-side glyph caching; 
Xft
> can trivially count total server memory and discard glyphs.  As the per-glyph
> metrics are available only through the library interface, Xft can internally
> discard per-glyph metrics.  Whole TrueType fonts can be discarded with some
> minor additions to the Xft API.  
> 
> These pieces are all straightforward, the reason they haven't been implemented
> to date is that the conditions for deciding to discard information are not 
well
> described; a workstation with several gig of memory will want to cache more 
data
> than a remote terminal with tens of megabytes.  X doesn't provide any hint to
> the remote capabilities of the display device and so I expect that we'll just
> have to allow the values to be configured manually.

I'd like to be kept informed as these are implemented. Until then I'm
certainly not going to add code without bloat control when one of the main
goals right now is bloat control.

> Mozilla has a well debugged code for the lower level part of this (handling
> the font lists) and a fairly well debugged upper level (generating the font
> lists). Getting this to work was a very big job.

> Xft will probably not provide code for selecting which font in a list is used
> for each glyph; that requires significant interaction with the underlying text
> data itself as one likes to preserve font apperance across multiple adjacent
> glyphs.  It may be that the upper level code from Mozilla could be of use 
within
> Xft; I'll go take a look at it.  

There is a lot of code involved and I'd be glad to discuss this 
(outside of this bug). There is not a single well written summary
of this but here are some potential starting points:
http://www.mozilla.org/projects/intl/fonts.html
http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsGTK.cpp#4054
http://bugzilla.mozilla.org/show_bug.cgi?id=67732
http://bugzilla.mozilla.org/show_bug.cgi?id=69139
http://bugzilla.mozilla.org/show_bug.cgi?id=73697
http://bugzilla.mozilla.org/show_bug.cgi?id=90736

> > I think it should be the users choice (not the developer's choice) to have 
> > separate AA setting for Mozilla if they want. I certainly do not see 
dictating 
> > this at the system level as attractive.
> You can assume that any configuration within Xft is bent entirely on providing
> defaults which can be adjusted by the application.  The goal is to share
> configuration which applications might not provide themselves, not to override
> the application developers will.

Can the applications adjust the Xft configuration?

If not, could you describe the UI for setting the defaults?

> > Is "sub-pixel decimation" part of Render or FreeType2? 
> > 
> > Or does it only exist in Xft?
> The Render protocol provides for per-channel alpha compositing which forms the
> underlying primitive for sub-pixel rendering.  Xft uses FreeType to transform
> the glyph appropriately and then it filters the resulting images to create the
> per-channel image.  Configuring this requires only a description of the
> underlying sub-pixel geometry of the screen; if Mozilla shared the common
> configuration mechanisms it would presumably be able to discover that
> configuration and perform its own image generation.

Sounds like a bug should be open to address this.

Comment 10

[Justin Mason]

I'd like to throw in a user comment, if I can ;)

Keith is spot on about sub-pixel decimation on LCD screens 
at low resolutions.  I'm using 1024x768 with SPD, and it's
totally changed my opinion on AA.

I agree that AA is not constructive at small font sizes on a
CRT, resulting in plenty of fuzziness; but using SPD on an 
LCD makes output *much* clearer. It's a big win, and IMO
should be a supported feature within Mozilla.

SPD support is my primary criterion in judging a web
browser's visual output at the moment.  

Comment 11

[keithp]

> I'd like to look at these. Would you kindly attach a URL referencing 
> these APIs?

At present, there are no programmatic mechanisms for modifying the Xft
configuration files.  The intent is to standardize on the format of the
configuration files so that multiple interfaces can be written to satisfy the
needs of a variety of environments.  Given the lack of user interface paradigms
related to configuration customization, I'm not sure what interfaces would be
appropriate.  The file syntax is not so complicated that a simple external agent
couldn't modify it by referring only to the specification.  A current Xft
document is available as

   http://xfree86.org/~keithp/talks/xtc2001/

> I'd like to be kept informed as these are implemented. Until then I'm
> certainly not going to add code without bloat control when one of the main
> goals right now is bloat control.
As I said, the caching is essentially independent of the API, hence discussions
about how to make the Xft API workable for Mozilla seem more pressing at present
than this trivial implementation issue.  Certainly once implemented, Xft will be
better placed to control server and client memory usage than applications using
core fonts.  I plan on doing this work in conjunction with the restructuring of
Xft which will not be a part of XFree86 4.2, but will be a part of 4.3 which
will be released around April or May of next year.

> Can the applications adjust the Xft configuration?
One missing piece in the current Xft code is the ability for Xft to re-read the
configuration files.  The new configuration library exposes this ability.
Combine this with code that modifies the configuration files and applications
will be able to adjust the global configuration quite easily.

There are internal interfaces within the library designed to programmatically
modify the configuration without modifying the configuration files; do you see
particular value in exposing these to applications?

> If not, could you describe the UI for setting the defaults?
I have no plans to create any user interfaces at all -- this is system software
that requires separate configuration interfaces suitable for the particular
desktop environment. Can you describe what you expect Mozilla will want to
configure at this level?

Comment 12

[Justin Mason]

Keith, I think if Mozilla can ask Xft to load a TT font with
a specific set of Xft "edits", that would probably be
enough?

Comment 13

[kill this account]

> > The Xft configuration provides a list of directories
> > containing font files, a list of alternate names for each font
> > and some simple rules that adjust the rendering of glyphs.
> 
> I'd like to look at these. Would you kindly attach a URL referencing 
> these APIs?

http://xfree86.org/~keithp/talks/xtc2001/

I've seen this URL:

  http://xfree86.org/~keithp/talks/xtc2001/

but did not see anything about:

  "The Xft configuration provides a list of directories containing 
   font files"

Is there information on this particular feature?

> At present, there are no programmatic mechanisms for modifying the Xft
> configuration files.  The intent is to standardize on the format of the
> configuration files so that multiple interfaces can be written to satisfy the
> needs of a variety of environments.  Given the lack of user interface 
paradigms
> related to configuration customization, I'm not sure what interfaces would be
> appropriate.  The file syntax is not so complicated that a simple external 
agent
> couldn't modify it by referring only to the specification.  A current Xft
> document is available as

This does not seem like it is ready to be used. Please keep me 
informed when/as this develops.

> I'd like to be kept informed as these are implemented. Until then I'm
> > certainly not going to add code without bloat control when one of the main
> > goals right now is bloat control.
> As I said, the caching is essentially independent of the API, hence 
discussions
> about how to make the Xft API workable for Mozilla seem more pressing at 
present
> than this trivial implementation issue. 

I'm glad to hear it is trivial. Let me know when it is ready as I 
do not intend to add code without bloat control since bloat control
is one of the main current goals.

> Can the applications adjust the Xft configuration?
> One missing piece in the current Xft code is the ability for Xft to re-read 
the
> configuration files.  The new configuration library exposes this ability.
> Combine this with code that modifies the configuration files and applications
> will be able to adjust the global configuration quite easily.

Are there references or a sample application somewhere?

Also, how would an application like Mozilla add a new font (read
downloaded font) and how does an application get informed that 
fonts have been added/removed?

> There are internal interfaces within the library designed to programmatically
> modify the configuration without modifying the configuration files; do you see
> particular value in exposing these to applications?

Not at this moment.

> If not, could you describe the UI for setting the defaults?
> I have no plans to create any user interfaces at all -- this is system 
software
> that requires separate configuration interfaces suitable for the particular
> desktop environment. Can you describe what you expect Mozilla will want to
> configure at this level?

For example, Xft proposes to set the AA minimum size threshold. 
This can have a large effect on the user's perception. While it 
is possible for mozilla to have a separate value from the Xft 
value it would be a messy solution. What should happen if the 
user sets the value in Mozilla, then latter sets the value in
Xft? Should the new changes to the Xft value be ignored? Either
answer seems wrong.

Comment 14

[keithp]

>  "The Xft configuration provides a list of directories containing 
>    font files"


 Xft takes a simplistic view in configuring where fonts are to be found.  A
 list of directories are specified and Xft searches those for font files, all
 of the font files it finds are added to the list of available fonts for
 matching.  The order within the directories is irrelevant; Xft always
 searches for the best match among all of the fonts.  Directories are
 specified in the config file with a line of the form:

        dir "/usr/X11R6/lib/X11/fonts/Type1"

> This does not seem like it is ready to be used. Please keep me 
> informed when/as this develops.

Then we differ in opinion on how configuration specifications should be used;
the library currently specifies the format and content of the configuration
file, the ability for applications to modify that is beyond the scope of this
particular library.  Whether another library is needed is a separate issue. 
Certainly the Xft specification contains enough information for applications to
completely control its configuration, there's just not any convenience API.

> Also, how would an application like Mozilla add a new font (read
> downloaded font) and how does an application get informed that 
> fonts have been added/removed?

That's actually relatively simple -- the Xft API is layered so that the matching
function is separate from the font file opening function.  By creating a pattern
with an explicit file name in it along with appropriate rendering instructions,
the font file may be opened directly:

    pat = XftPatternBuild (0, XFT_FILE, XftTypeString, filename,
                           XFT_INDEX, XftTypeInteger, index,
                           XFT_SIZE, XftTypeDouble, size,
                           NULL);
    XftDefaultSubstitute (dpy, screen, pat);
    font = XftFontOpenPattern (dpy, pat);
A better interface might be nice; suggestions are always welcome.

> For example, Xft proposes to set the AA minimum size threshold. 
> This can have a large effect on the user's perception. While it 
> is possible for mozilla to have a separate value from the Xft 
> value it would be a messy solution. What should happen if the 
> user sets the value in Mozilla, then latter sets the value in
> Xft? Should the new changes to the Xft value be ignored? Either
> answer seems wrong.
I would suggest that one reasonable answer is that Mozilla modify and use the
Xft configuration so that instead of two separate values, there is only one.  It
doesn't seem likely that the user would want to display fonts differently within
Mozilla than the rest of the screen; Mozilla is only a part of the users desktop
environment.

Comment 15

[kill this account]

> >  "The Xft configuration provides a list of directories containing 
> >    font files"
> 
>  Xft takes a simplistic view in configuring where fonts are to be found.  A
>  list of directories are specified and Xft searches those for font files, all
>  of the font files it finds are added to the list of available fonts for
>  matching.  The order within the directories is irrelevant; Xft always
>  searches for the best match among all of the fonts.  Directories are
>  specified in the config file with a line of the form:
> 
>         dir "/usr/X11R6/lib/X11/fonts/Type1"

What is the API that an app. uses to get the list of directories?

> > This does not seem like it is ready to be used. Please keep me 
> > informed when/as this develops.
> 
> Then we differ in opinion on how configuration specifications should be used;
> the library currently specifies the format and content of the configuration
> file, the ability for applications to modify that is beyond the scope of this
> particular library.  Whether another library is needed is a separate issue. 
> Certainly the Xft specification contains enough information for applications 
to
> completely control its configuration, there's just not any convenience API.

So does moz get to own the configuration file? 

If not, what implements the sharing?

If there is not sharing then what is the value of a common file?

> > Also, how would an application like Mozilla add a new font (read
> > downloaded font) and how does an application get informed that 
> > fonts have been added/removed?
> 
> That's actually relatively simple -- the Xft API is layered so that the 
matching
> function is separate from the font file opening function.  By creating a 
pattern
> with an explicit file name in it along with appropriate rendering 
instructions,
> the font file may be opened directly:

The question is not about opening an existing font file, this is 
about adding an entirely new font file to the available fonts.

And the question is also about being informed when the available 
fonts change.

> > For example, Xft proposes to set the AA minimum size threshold. 
> > This can have a large effect on the user's perception. While it 
> > is possible for mozilla to have a separate value from the Xft 
> > value it would be a messy solution. What should happen if the 
> > user sets the value in Mozilla, then latter sets the value in
> > Xft? Should the new changes to the Xft value be ignored? Either
> > answer seems wrong.
> I would suggest that one reasonable answer is that Mozilla modify and use the
> Xft configuration so that instead of two separate values, there is only one.  
It
> doesn't seem likely that the user would want to display fonts differently 
within
> Mozilla than the rest of the screen; Mozilla is only a part of the users 
desktop
> environment.

Yes, I agree that Moz is only one of several apps.

What is the API that an application should use when changing the 
config values?

How is sharing implemented?

Comment 16

[kill this account]

-> 0.9.8

Comment 17

[kill this account]

It looks like we will try to merge the existing moz linux truetype code with
xft

Comment 18

[keithp]

I'll be maintaining an Xft patch against current Mozilla until it goes into the
tree, available at http://keithp.com/mozilla.  The patch includes some minor
refactoring of the font code which would actually be useful for the current
FreeType patch -- font information is now loaded using a subclass method
instead of inline in the rendering code.

Comment 19

[kill this account]

Keith: please open a bug for your work (you will need it to check anything in)

We are currently aiming to have both direct FreeType2 access in moz and
FreeType2 via Xft in moz. Hopefully these will merge.

The point of this bug is no longer meaningfull so I am closing it.

Comment 20

[keithp]

I've opened bug 126919 for discussions on getting Xft ready for Mozilla.