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: | |
Severity: | enhancement | ||
Priority: | high | CC: | bl.bugs, dr.khaled.hosny, freedesktop, jay.hobson, nicolas.mailhot |
Version: | 2_1 | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Bug Depends on: | |||
Bug Blocks: | 8100 | ||
Attachments: | Patch to enhance fonts.conf and provide support to exclude glyphs from fonts |
Description
Simos Xenitellis
2006-07-15 05:24:18 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 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). 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. 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. 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? Bugzilla Upgrade Mass Bug Change NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO. - benjsc fd.o Wrangler This is fixed in master with target=scan charset editing. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.