|Summary:||fontconfig support to exclude glyphs from fonts|
|Product:||fontconfig||Reporter:||Simos Xenitellis <simos.bugzilla>|
|Component:||library||Assignee:||Keith Packard <keithp>|
|Status:||RESOLVED FIXED||QA Contact:|
|Priority:||high||CC:||bl.bugs, dr.khaled.hosny, freedesktop, jay.hobson, nicolas.mailhot|
|i915 platform:||i915 features:|
|Bug Depends on:|
|Attachments:||Patch to enhance fonts.conf and provide support to exclude glyphs from fonts|
Description Simos Xenitellis 2006-07-15 05:24:18 UTC
[copying from http://lists.freedesktop.org/archives/fontconfig/2006-June/002332.html Jay Hobson writes:] I have been working with Nicolas Mailhot to provide a solution to allow DejaVu to be added to fontconfig enabling support for some languages while excluding support for others. I have attached a patch which works with fontconfig-2.3.95. The patch adds two new tags to supported XML tag list. The tags work in conjuction with other tags already present in the library. The tags require fonts.conf or its included counterparts to be amended, detailing languages to restrict in specified families. The first added tag "hide" documents which languages are restricted from use for the family. The second tag "only" documents which languages the family is allowed to support. The patch works by copying the pattern out of the cache, then modifying the local copy of the pattern to remove either a list of languages to be hidden, or deleting the language set, creating a new one and adding only the supported languages. This new pattern is then used for comparison for a match, after which point it is deleted. This patch only affects the comparison for families within an alias. If the user requests a specific family by name, no modification of the language set will occur. Additionally, as some families may be used in more than one alias and need differing support for each, the alias name is required, and modifications to the language set needs to be dynamic. The key benefits for this patch are the ability to use fonts that are works in progress, broken, or have poor quality glyphs for particular languages. This patch can also be used to allow fonts to be placed higher in the alias list with support for only targeted languages without interfering with fonts intended for other language support. Syntax for the new commands is shown in the following example: <alias> <family>Sans-serif</family> <only> <family>Arial</family> <lang>en</lang> <lang>de</lang> </only> <hide> <family>DejaVuSans</family> <lang>ar</lang> </hide> </alias> <alias> <family>Serif</family> <hide> <family>Times</family> <lang>en</lang> <lang>de</lang> <lang>es</lang> </hide> </alias> The above XML would only allow Arial to be used for English and German, disallow DejaVu for Arabic, and disallow Times with English, German and Spanish. I am interested in your comments/questions and willing to work with you to make this a part of the fontconfig library.
Comment 1 Simos Xenitellis 2006-07-15 05:28:07 UTC
Created attachment 6229 [details] [review] Patch to enhance fonts.conf and provide support to exclude glyphs from fonts This is the patch created by Jay Hobson and listed at http://lists.freedesktop.org/archives/fontconfig/2006-June/002332.html
Comment 2 Keith Packard 2006-07-15 10:19:31 UTC
I certainly agree with the sentiment of this change; there are glyphs in many 'combined' fonts which should never see the light of day. However, to reduce memory usage and take advantage of the mmap'd cache architecture in 2.4, I'd like to see the patterns edited as the fonts are scanned, rather than as they are used so that the patterns in the cache can be used unchanged. I was also thinking that we could actually edit the list of unicode code points provided by each font; that way you could put deja vu up front in the list and still skip over the arabic glyphs present in that family and reach more suitable glyphs in later fonts, independent of the language tag in use. However, that would actually remove the glyphs from ever being used, a good thing when you *do* have alternate fonts with reasonable glyphs, but less desirable when Deja Vu is all you have. I don't know how to fix that; we've got a font with a mixture of good and bad glyphs in a mixture of styles. Perhaps we can convince some of the free font authors to fix that by breaking the font into separate families so we can push the ugly stuff to the bottom of the list while still using the good stuff on the screen. Oh, and also letting people edit the list of supported languages makes a lot of sense; I can easily imagine language support being mis-computed as it is entirely based on unicode coverage (with hacks for Han languages). But, I think that's a separate issue than glyph coverage, which we should capture as unicode ranges (which might, in fact, be represented as languages, but should probably instead be represented as unicode pages).
Comment 3 Jay Hobson 2006-07-20 16:48:33 UTC
I think that dynamic modification of the language set will work for being able to lower the ranking of a font supporting a particular language. As I am familiar with the internals of both the code I wrote, and the areas of fontconfig that it interacts with, I believe that it could be altered to allow users to identify fonts with poor language support. In this way it would solve the secondary problem of allowing alternate fonts lower in the preference list to be chosen for particular languages over fonts higher in the list. It would not result in the case of the language being unsupported if no font further in the list supported the language in question. If I add support for this, and submit the patch, do you think that it would be accepted? I need to patch the pre-mmap versions, so the dynamic method I am using works best for me.
Comment 4 Keith Packard 2006-09-01 22:21:51 UTC
Do you guys want to update this patch for the fc-2_4-keithp branch? Also, does this execute while fonts are scanned or while fonts are loaded? I'd strongly prefer the former as it will be far faster and more memory efficient given the mmap'd caches.
Comment 5 Keith Packard 2006-09-02 17:56:04 UTC
Ok, I've added a 'scan' target to the match element which should make this process a whole lot easier; we just need a way to edit the language support and glyph coverage values from within an edit target and we'll be all set here. Does someone else want to take ownership of this bug?
Comment 6 Benjamin Close 2008-01-11 02:37:04 UTC
Bugzilla Upgrade Mass Bug Change NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO. - benjsc fd.o Wrangler
Comment 7 Behdad Esfahbod 2011-03-14 13:33:14 UTC
This is fixed in master with target=scan charset editing.