On Tue, 22 Oct 2002, Keith Packard wrote:
Thank you for your explanation.
> Around 12 o'clock on Oct 22, Jungshik Shin wrote:
>
> > 1. get a pattern from an application(fontconfig client)
> > 2. apply configuration-specified editing rules to the pattern.
> > For each font:
> > 3. read in font properties from fc-cache or (directly from font if
> > fc-cache is not present)
> > 4. measure the distance between the pattern and each font
>
> Fontconfig reads the font properties at startup time, and thereafter only
> when they change (it checks file mod times when fonts are listed).
I see. So, step 3 should be at the top.
> What we could do is add a set of rules executed when the patterns are
> loaded although I'm not sure that's precisely what you want,
More specifically, you meant 'the patterns holding font properties
are loaded from font-cache files', didn't you? If so, that's what I want.
<match target="font">
<test qual="any" name="family"><string>FAMILY</string></test>
<edit name="charset" mode="MODE">
<charset>.....</charset></edit>
</match>
where 'MODE' can be 'add'('append/prepend' just do), 'subtract' or
'assign' (or something similar to that effect). Because 'charset'
is already taken for Base85 representation of the coverage, a new
property (that has to be translated to charset internally) name
(e.g. coderange) might be used or 'charset' can be overloaded to mean
a more human-readable representation of the coverage in fonts.conf.
(sth. like [0xuuuu-0xuuuu]). For instance, I want the following to be
applied to font properties of 'Gulim Old Hangul Jamo' (a hack-encoded font
of which character/glyph assignment has NOTHING to do with actual Unicode
character assignment) read off from fc-cache BEFORE matching against
an application-provided pattern (by measuring the distance) begins.
<match target="font">
<test qual="any" name="family">
<string>Gulim Old Hangul Jamo</string>
</test>
<edit name="charset" mode="subtract">
<charset>0x4e00-0x5400</charset> // remove hack-encoding code points
</edit>
<edit name="charset" mode="add">
<charset>0x1100-0x11ff</charset> // Hangul Jamos
</edit>
<edit name="charset" mode="add">
<charset>0x302e-0x302f</charset> // Hangul Tone marks
</edit>
<edit name="charset" mode="add">
<charset>0xac00-0xd7a4</charset> // Hangul syllables
</edit>
<edit name="lang" mode="assign">
<string>ko</string>
</edit>
</match>
Another example is for Baekmuk Batang which doesn't have glyphs
for U+1100-U+11FF, but can be used to render them nonetheless.
<match target="font">
<test name="family">
<string>Baekmuk Batang</string>
</test>
<edit name="charset" mode="add">
<charset>0x1100-0x11ff</charset> // Hangul Jamos
</edit>
<edit name="charset" mode="add">
<charset>0x302e-0x302f</charset> // Hangul Tone marks
</edit>
</match>
> it would significantly impact application startup performance.
Would just adding the feature to fontconfig have this significant
negative impact even in absence of editing rules for this feature in
fonts.conf? Or, would that negative impact manifest itself ONLY when
fonts.conf actually has editing rules for this feature? If the latter
is the case, the decision/choice would fall on end-users, wouldn't it?
If they think they can exchange a performance hit at application start-up
for a feature they desperately need, they would go for it. Otherwise,
they wouldn't put any editing rule to be applied at font-properties
loading stage.
> It seems like you want to select fonts based on Unicode coverage of the
> desired Hangul representation.
Actually, that's related but not exactly what I want. I may have get
you confused because last week I mentioned multiple ways of representing
Hangul along with what I'm talking about here. Or, am I
misunderstanding you?
I'd like to override 'charset' property(Unicode coverage) of some
fonts detected by fontconfig and stored in font-cache because the
detected value of 'charset' property doesn't represent their 'true' ability
due to hack-encodings used in them. In the example above, 'Old Gulim
Hangul Jamo' is detected to cover [U+4E00-U+52xx] and [U+0000-U+007F],
but I like that detected Unicode coverage to be modified by rules
specified in fonts.conf to reflect its 'true' ability ( [U+1100,U+11FF],
[U+AC00-U+D7A4], etc)
Arguably, this could be useful for more general cases than I made
it sound. Some fonts have precomposed Latin/Cyrillic/Greek letters
with diacritics, but they may not have combining diacritics themselves.
When a client of fontconfig like Pango tries to render a sequence of
a base character and a diacritic mark with such a font, Pango *seems*
to end up having two separate fonts, one for the base character(the font
specified in an application ) and the other for the diacritic mark even
though the first font (spec. in an application) has a glyph for the
precomposed charater made up of the base character and the diacritic
mark. Although this kind of problem can be solved at a level different
from fontcofing fontconfig could well help here.
> You could easily add a way to represent
> Unicode coverage in the config file; that would make adding coverage
> information possible with existing apps.
Yes, I need to do this (not just adding, but also subtracting) as
my example editing rules show. And, this 'editing' has to be done to
charset properties *before* the matching begins because for some fonts
(which would NOT be selected without this modification in charset
property), it's too late if it's done after the matching(font selection).
On the other hand, if I can edit charset property
of 'pattern' (requested by an application) based on family-name (as
you suggested), it might do the job nonetheless although it's not
as intutive as directly modifying font properties before measuring
the distance. To make this work, I guess 'contained in'(or 'SubsetOf'
operator (as opposed to 'contain') is necessary. In any case, I'm afraid
this way is not as 'robust' as editing 'font properties' of a particular
font before measuring the distance (matching).
<match target="pattern">
<test qual="all" name="family">
<string>Gulim Old Hangul Jamo</string>
</test>
<test name="charset" compare="ContainedIn">
<charset>0x1100-0x11ff,0xac00-0xd7a4</charset>
</test>
<edit name="charset" mode="subtract">
<charset>0x1100-0x11ff,0xac00-0xd7a4</charset>
</edit>
<edit name="charset" mode="add">
<charset>0x4e00-0x5400</charset>
</edit>
</match>
Jungshik
_______________________________________________
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
