Re: font substitution

[Yen-Ju Chen]

On 8/8/07, Fred Kiefer <fredkiefer@gmx.de> wrote:
> 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.

  Yes. Most people probably don't even need this user defaults,
  or at most with a font for symbol.
  But it is quite useful for people who are studying languages
  and need to show both languages side by side,
  say French and Janapese.
  In that case, they need to specific the preferred fonts.

>
>
> >>>>   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?

  If the patch you have goes into the -trunk,
  I can play with it and see how much it effects the speed
  and decide what's the best way to do the cache if needed.

  Yen-Ju

>
> >>>   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.
>
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep
>