Closed Bug 109423 Opened 23 years ago Closed 23 years ago

FreeType2 on Linux Mozilla with/without Xft

Categories

(Core :: Internationalization, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.1alpha

People

(Reporter: bstell, Assigned: bstell)

Details

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.
Status: NEW → ASSIGNED
Summary: FLAMEWARE: FreeType2 on Linux Mozilla with/without Xft → FreeType2 on Linux Mozilla with/without Xft
Target Milestone: --- → mozilla0.9.7
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?
5) Does it support the Linux/Unix platforms Linux/Unix Mozilla supports?
Anyone else have thoughts on the criteria for using/not-using Xft to access FreeType2? This will set the ground work for this discussion.
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.
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.
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).
> 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?
> 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.
> 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.
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.
> 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?
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?
> > 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.
> "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.
> > "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?
-> 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → mozilla0.9.9
It looks like we will try to merge the existing moz linux truetype code with xft
Target Milestone: mozilla0.9.9 → mozilla1.1
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.
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.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
I've opened bug 126919 for discussions on getting Xft ready for Mozilla.
QA Contact: teruko
You need to log in before you can comment on or make changes to this bug.