Yen-Ju Chen wrote: > On 8/7/07, Fred Kiefer <[EMAIL PROTECTED]> wrote: >> Yen-Ju Chen wrote: >>> On 8/7/07, Yen-Ju Chen <[EMAIL PROTECTED]> wrote: >>>> On 8/7/07, Fred Kiefer <[EMAIL PROTECTED]> 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. _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
