Re: [Fonts]Storing the cached font (fonts.cache) information
Around 22 o'clock on Sep 6, Ken Deeter wrote: I am concerned that without doing something like this, adding a font directory would require modifying two files instead of one (the fonts.conf to add the dir and the font mapping table file) Adding a font directory almost never involves modifying any files at all -- you just stick the directory underneath one of the existing directory entries in the config file. Fontconfig automatically discovers the new fonts and makes them available to applications. You can stick fonts in ~/.fonts and they are automatically available as fontconfig includes that path in the default set of heirarchies. To add a new directory heirarchy to the set of available fonts, all you have to do is edit the font configuration file and add a dir element. Of course, in both cases, you're encouraged to run 'fc-cache' before using the fonts so that the shared font cache file can be built. Certainly any relocation of that cache file would be automatically mananged by the library, insisting that adminstrators and users keep two disparate files synchronized is a really bad idea. I think a better solution would be to think of some kind of automatic mapping generation, that requires nothing from a user except to specify an extra directory in the fonts.conf Only permitting a single extra directory makes it difficult for different users to have different sets of font heirarchies, in particular, caches for per-user fonts cannot live in /var/cache/fonts as that's probably not writable by each user. Hence the idea of multiple mappings which match the directory prefix and replace that with a different prefix. If no mapping prefix matches the font directory, the cache file would be placed within the directory itself just as is done today, so it's really only necessary to add these entries for system-wide read-only font directories. Adding a property to the dir element would be very easy to understand, and I don't think that would tremendously burden users with too much configuration; most systems have only two or three font heirarchies present. I'm not sure what happens when the cache needs to be rebuilt, (i.e. how fontconfig knows when whats in the directory doesn't match whats in the cache, but i'm assuming this is already dealt with since it is a problem regardless of where the cache files are put) Fontconfig keeps track of directory and file modification times in the cache and invalidates entries which are outdated. It stat's every directory in the heirarchy at startup to detect changes, so it's somewhat important that the heirarchies be focused on fonts and not just '/'. ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Storing the cached font (fonts.cache) information
On Sat, 7 Sep 2002, Zenith Lau wrote: Date: Sat, 7 Sep 2002 09:42:47 +0800 From: Zenith Lau [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII List-Id: XFree86 Font List fonts.XFree86.Org Subject: Re: [Fonts]Storing the cached font (fonts.cache) information Hi, I think I've some opinion on this ~ However, storing cached information in what is ostensibly a read-only directory is unfriendly and violates the FSH guidelines. This data is just cached versions of data available from the font files themselves and so the FSH says it should live (somehow) in /var/cache. Good move! Any directories not matching a configured prefix would map to themselves; this makes the existing configuration and cache files compatible. How do you resolve any fonts which doesn't located under /usr/share/fonts ? Some one like to put fonts under different mount points and for me, I put most of my TTF under /usr/X11R6/lib/X11/fonts/local . Is it possible to for this way : 1. Let's assume the caching directory is called FontCachePrefix/ 2. Add one additional mapping table under the FontCachePrefix/ 3. Such that, we lookup the cache for a specific directory by keeping the relation of each cache file and its' corresponding font directory. 4. So that, we don't need a complicated sub-dir. tree under our FontCachePrefix/ 5. The listing can be in binary to minmize the extrax cost for this additional table (file). 6. Finally, for each font directory, we can put the cache as something like path-to.cache or simply 1.cache, 2.cache etc. Does this seem like a good plan? Can anyone come up with a better way of moving the storage of fonts.cache into /var/cache? Yes, personally, I don't like cache placed around my fonts directory : ) Also, this will make reonly /usr partition for practical. But, /var/cache/fonts is already specified in the FHS, that, this directory is for dynamically generated fonts, I quote it here : 5.5.3 /var/cache/fonts : Locally-generated fonts (optional) 5.5.3.1 Purpose The directory /var/cache/fonts should be used to store any dynamically-created fonts. In particular, all of the fonts which are automatically generated by mktexpk must be located in appropriately-named subdirectories of /var/cache/fonts.[footnote 31] 5.5.3.2 Specific Options Other dynamically created fonts may also be placed in this tree, under appropriately-named subdirectories of /var/cache/fonts. Hence, I think, cooperation with FHS is needed or, we simply use another prefix. Though, I think /var/cache/fonts should be the better, as I like the style what fontconfig do. I hope that, the combination ft + fc can be adopted more widely. Right, /var/cache/fonts is taken use /var/cache/fontconfig instead. Much more explicit what owns it. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer XFree86 maintainer Red Hat Inc. ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]blank glyph list in fonts.config
Since the release of a new CODE2000 font(by James Kass at http://home.att.net/~jameskass) with glyphs for Hangul Jamos, I've been trying to test how it works with various browsers. Mozilla with direct access to truetype fonts works fine, but Mozilla with Xft patch has a problem with U+115F(Hangul leading consonant filler) and U+1160(Hangul vowel filler). In CODE2000, the former is a spacing(non-zero width) _blank_ glyph while the latter is a non-spacing(zero-width/combining) _blank_ glyph. When Mozilla with Xft patch is used to render http://jshin.net/i18n/korean/fillers.html (or http://jshin.net/i18n/korean/hunmin.html), U+115F and U+1160 are rendered with hollow boxes instead of spacing and non-spacing(combining) blanks seemingly because they're not listed among characters allowed to have blank glyphs. It's 'seemingly' because Mozilla with Xft patch has this problem while 'gedit' doesn't have this problem. Anyway, adding U+115F and U+1160 to the list in fonts.config solved the problem. Two screenshots are put up at http://linux.mizi.com/~ganadist/filler1.png (with U+115F/U+1160 added to blank glyph list) http://linux.mizi.com/~ganadist/filler2.png (without ) Mozilla for MS-Windows has a similar problem and I came up with a similar fix that works. See http://bugzilla.mozilla.org/show_bug.cgi?id=167136. I'm not sure adding U+115F/U+1160 to the blank glyph list is the best way, but it works. Keith, could you consider this? Thank you, Jungshik ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]blank glyph list in fonts.config
On Sat, 7 Sep 2002, Keith Packard wrote: Around 9 o'clock on Sep 7, Jungshik Shin wrote: I'm not sure adding U+115F/U+1160 to the blank glyph list is the best way, but it works. Keith, could you consider this? The blank glyph list is supposed to be filled with all of the Unicode values which have an empty visual representation. It's a hack to work ... I adapted the data I found in Mozilla for this purpose, hence the similar issues you found in the two programs. Thank you for going through the Unicode tables to come up with a more extensive list. I've just posted your list to bugzilla bug 167136 mentioned previously. I'm reading through the Unicode tables looking for other blank values, so far I've found: Unicode range added? comments U+180B - U+180E no (but I don't have a Mongolian font to check against) U+200C - U+200F yes (the Unicode description isn't clear) U+2028 - U+2029 no (these seem like they're supposed to be drawn) U+202A - U+202F yes (these also appear blank from the description) U+3164 yes (HANGUL FILLER, similar to U+1160) U+FEFF yes (byte order detector (ZERO WIDTH NO-BREAK SPACE)) U+FFA0 yes HALFWIDTH HANGUL FILLER (similar to U+3164) U+FFF9 - U+FFFByes INTERLINEAR ANNOTATION marks for furigana Rules for inclusion -- if a font could reasonably draw these as blank, they should be included in the list. The idea is to ignore empty glyphs which should always have some visual representation. I think that U+200C/U+200D(ZWNJ, ZWJ) are meant to be used mainly( though not exclusively. Latin ligature formation may also be controlled by them.) with Indic scripts and fonts for Indic scripts are supposed to have some OT tables built-in to map a sequence of characters including ZWNJ/ZWJ to appropriate glyph(s). As for U+200E/U+200F and U+202A - U+202F, I guess a lower-level layer like fontconfig is never supposed to see them because they have to be taken care of at a higher level(layout. e.g. Pango?). Nonetheless, it seems like it's harmless(except for a little performance hit, if any) to include them in the blank glyph list. The same appears true of U+FFF9 - U+FFFB. BTW, although depcecated, U+206A - U+206D seem to have to be included as well. U+206E and U+206F may or may not have to be added. I'm not sure what they're for. Jungshik ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]blank glyph list in fonts.config
Keith == Keith Packard [EMAIL PROTECTED] writes: Keith int0x1680/int !-- OGHAM SPACE MARK -- AIUI, and I do not read Ogham, U+1680 is only blank in some fonts, and is a horizontal line in others. -JimC ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Much worse rendering with latest fontconfig package
Jeffrey == Jeffrey Baker [EMAIL PROTECTED] writes: Jeffrey It is indeed the same version and build of freetype used in Jeffrey both of my previous examples. In the png you posted, if they are the same font, the diference is definitely hinting. There are options in ft to control whether hinting is used, and if so whether to use the byte code or ft's own autohinting algorithm. I don't see anything in the Xft1 src (either version) that references those flags, and am getting instructed glyphs. (I can read them as small as 3 pt at 133 dpi.) Did you use lsof to confirm that the app was using the same version of ft and the same font file under both examples? I, eg, ended up getting a different font for 'mono' from my font.conf config than I was getting from my XftConfig config. lsof will show exactly what font file is being used, as will /proc/$pid/maps. -JimC ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
