Re: font substitution

[Fred Kiefer]

Yen-Ju Chen wrote:
> On 8/7/07, Fred Kiefer <fredkiefer@gmx.de> wrote:
>> Yen-Ju Chen wrote:
>>> On 8/7/07, Yen-Ju Chen <yjchenx@gmail.com> wrote:
>>>> On 8/7/07, Fred Kiefer <fredkiefer@gmx.de> wrote:
>>>>> OK, so here is a reworked version of this patch. I had to fix the
>>>>> coveredCharacterSet method of ftfont to get this working. So it may not
>>>>> be possible for you to actually check this code. What I would like to
>>>>> get from the mailing list is a short review, if you agree that this code
>>>>> is fast enough to be included.
>>>>> There are a few noteworthy changes to Alexander's patch. I set the
>>>>> substitution font directly as the new font for the character. I am not
>>>>> sure, if this is compatible with what Apple does. This patch also tries
>>>>> to find a substitution by looking at all available fonts. This may be
>>>>> really slow, when it fails. It will also result in the character sets
>>>>> for all fonts being cached. I am not sure, if we really want this,
>>>>> perhaps we should do this caching only for the fonts in 
>>>>> preferredFontNames?
>>>>>
>>>>> As you can see, I am still not that sure about this patch.
>>>>   If speed is the concern,
>>>>   I would say caching only preferredFontNames is enough.
>> This surely would save space. But most likely it will be slower, when we
>> have a miss for the preferred fonts.
> 
>   Actually if preferred fonts is not defined,
>   it can just not do the substitution,
>   In that case, it will have the least impact on current users.
>   The more preferred fonts, the slower the system will be.
>   Missing glyph in all preferred fonts costs less
>   than searching all available fonts for that glyph.
> 

Yes, you should only have a few preferred fonts, one for every odd
script that you are going to use.


>>>>   Because OS X ship their own fonts for each language,
>>>>   I believe they can cache such information in advance for each language
>>>>   and only fallback when all the defaults font fails, which hardly happens.
>>>>   I also wonder whether fonts have language information inside.
>>>>   If so, we can actually have a table of glyph range of each language
>>>>   and only match language instead of each glyph.
>>>>   That would be much faster.
>>>>   And I believe that there is hardly a font supporting
>>>>   only half of the glyphs for a language.
>>>>   In another word, if a font has 'A', it must have [A-Z][a-z][0-9].
>>>>   In that case, we only need to look at the unicode table
>>>>   and pick probably 2 glyphs for each language
>>>>   and use them to check the font.
>> What you are talking about is what to AppKit documentation calls
>> scripts. Fonts normally support scripts and it would help to know, which
>> script is supported by which font. As far as I can see there is no
>> official interface to query this information. It could be established in
>> the way you suggest, but this could be risky. I am not to familiar with
>> other scripts, but just for the standard European languages it would be
>> hard to define which characters should be checked. Is it enough to check
>> for "ö" and "Ü" to know that German is supported? Or do we need to check
>> "ß" as well (if we aren't writing is Swiss German). (Not sure, what you
>> will see here, but I used a few Umlaute and a replacement for "ss")
> 
>   I see your point, but I would be surprised that
>   a font will contain o-umlaut, but not 'ss'.
>   But there may be exception in some other lauguages
>   to make this methods fail.
>   Another thing I am thinking is to save the coveredCharacterSet on disk.
>   Font does not change frequently,
>   and it does take time to generate coveredCharacterSet for each font,
>   especially for CJK.
>   If the cached coveredCharacterSet can be saved on disk and loaded later,
>   it can reduce the overhead of starting an application.
>   For art backend, it can even pack the saved coveredCharacterSet in nfont.
>   So for small font, it is fine to check the covered character each time.
>   For big font, saved character set is better.
> 

Great idea! Would you like to work on that?

>>>   I forgot to ask, is there a user default to set the preferredFontNames ?
>>>   Otherwise, preferredFontNames will always return nil
>>>   unless applications explicitly set it in NSFont.
>>>
>> Good point. Currently we rely on the application to set this variable.
>> It surely would be better to have a user default for it.
>>
> 

I just added code to read the user default for preferred fonts from
NSPreferredFonts.