[Fontconfig] Re: fontconfig support to exclude glyphs from fonts
Jay.Hobson at Sun.COM
Thu Jun 29 13:05:14 PDT 2006
Keith Packard wrote:
>On Thu, 2006-06-29 at 10:43 -0700, Jay Hobson wrote:
>>While I can see the need for a ban on unicode codepoint sets, I think
>>many end users will find that horribly difficult to use and set up. With
>>the patch that I am providing, you can accomplish the same basic goal
>>without nearly as much hardship. I suspect it is easier to look up what
>>languages a font supports, than what the unicode codepoint set is.
>That's a good point. Having the ability to *also* edit the language set
>offered by a font makes good sense.
>I think what I was focused on was the notion that we should (finally)
>look at editing the data about the available fonts instead of trying to
>work around broken data during the match phase.
>>Additionally, if you ban an entire language from a font, then the
>>language will be displayed with a different font and have a better
>>chance of looking consistent. If you ban a codepoint set, unless you get
>>the entire language coverage, you run the risk of having two fonts
>>display your text, which would likely look bad.
>Right. Let's work on a font pattern editing mechanism and then do both
>code point and language editing. That should fix both problems nicely.
>The main reason for a code point ban is to elide latin glyphs from
>non-latin fonts -- TrueType nearly insists that all fonts include latin
>glyphs, which makes no sense for many non-latin fonts, and which often
>results in really ugly latin glyphs being included.
One interesting twist to this, and the reason that I designed the patch
the way that I did, is that some of these same fonts that include Latin
glyphs can have latin characters that are matched nicely to the other
languages contained in the font (not often). IE: size, thickness, etc.
However, the latin only contains either Serif or Sans-Serif glyphs, and
the other language is often needed for both Sans and Serif coverage.
This leaves a latin that might be nice to have in one instance, and not
in the other. Hence the reason that you would want to dynamically enable
and disable languages from a font. For one alias it would be good, for
the other, it would be bad. Right now, there is no mechanism for
detailing language coverage by alias. The patch includes such a
mechanism which adds some additional value to fontconfig.
>The language ban will work better where multiple languages share the
>same code point range.
>Good ideas; let's see what we can manage.
More information about the Fontconfig