Re: [Fonts]Fcpackage release candidate 1
KP eliminate per-file syscalls when the cache file is up-to-date. Could you explain what exactly you're trying to avoid and how you achieve that? Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Question on xft font library.
1. It seems that XFT is so good, so what's about the conventional fonts module inside X, like the xtt, freetype, type1, etc... The X server can still provide fonts for applications not yet ported to Xft. These modules will be useful as long as you have some older applications left around. Do you mean that, these two module is stable enough, and no active development works is carried on these? I am the maintainer of the freetype module, and I try to encourage people to move over to using Xft for new applications, and port existing applications to Xft whenever reasonable. Now that Xft doesn't have particular server-side requirements, there is no reason whatsoever to avoid using it. The freetype module is being actively maintained, and there is a new version that will hopefully get into XFree86 4.3.0. However, I shall not add any new features to it; in particular, the ``freetype'' module will never support TTCap. If you feel that you need the features of TTCap, then I believe that you should be using Xft rather than the core fonts system. Regards, Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Fcpackage release candidate 1
Around 16 o'clock on Aug 12, Juliusz Chroboczek wrote: KP eliminate per-file syscalls when the cache file is up-to-date. Could you explain what exactly you're trying to avoid and how you achieve that? Fontconfig computes information about each font. Instead of requiring that the user manually ensure that the information is up-to-date, fontconfig verifies it each time it starts. The original (slow) design in Xft simply recomputed the information each time the library started; this was fine when the user had few fonts and the information was relatively inexpensive (family name, style, etc). This involved opening each directory in the configuration and opening each font file in the directory. The second incarantion had two separate mechanisms. It had a shared cache file in each directory and a separate per-user cache file in $HOME. If the shared cache file was newer than the directory, the contents of that cache file were used without further verification. Directories not containing a valid cache file were manually scanned for files, and those filenames were looked up in the per-user cache file. Each file in the per-user cache was marked with a timestamp; if that timestamp matched the file change time, the font information in the cache was used. Otherwise, the file would be opened, and the computed font information would get written back to the per-user cache file. So, this second mechanism required opening each directory and stat'ing each file in the directory. With a really large number of directories containing a large number of files, even this mechanism was too expensive. In addition, the two mechanisms now made different assumptions about the state of the system -- the per-directory cache assumed that any changes to font files within the directory would be signalled by a change to the directory itself while the per-user cache checked each file and ignored the directory timestamp. By applying the assumptions made by the per-directory cache to the per-user cache, the poor performance of the per-user cache could be fixed without significantly impacting the overall correctness of the mechanism. So, now the per-user cache keeps timestamps for the directories as well as directories. When the cache timestamp for the directory matches, the cached information for each file within that directory is added without further verification. Otherwise, the directory is scanned and each file checked against the cache. Again, the per-user cache is automatically updated when this information changes, so the rescanning affects only the first application to run after the filesystem has changed. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Using current locale in font selection
BS Any thoughts on what would be a good fallback if the document does BS not specify a language group and the document encoding does not BS give a hint (eg: Unicode)? At the application level, using the user's locale is reasonable IMHO. What I object to is doing that at the library level, where the application developer might not be aware of what's happening. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Using current locale in font selection
Around 17 o'clock on Aug 12, Juliusz Chroboczek wrote: Please do not do that. It will make the life of developers miserable (would *you* think of asking about the user's locale upon receiving a bug report you cannot reproduce?). But the alternative is to require custom configuration for every user -- consider a system supporting both Japanese and Korean users, there cannot be a single default 'sans' font which can optimally display both of these languages. Using LC_CTYPE gives the system a chance to select the right font without requiring customization. Even in western environments, it's easy to believe that the best font for German users will be different from that for Czech users; the coverage of preferred font for German might well be missing Z WITH CARON. I don't think I can discard this useful hint even though it will probably present interesting problems in some debugging situations. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Using current locale in font selection
Please do not do that. It will make the life of developers miserable (would *you* think of asking about the user's locale upon receiving a bug report you cannot reproduce?). KP But the alternative is to require custom configuration for every user -- KP consider a system supporting both Japanese and Korean users, there cannot KP be a single default 'sans' font which can optimally display both of these KP languages. Using LC_CTYPE gives the system a chance to select the right KP font without requiring customization. No; the alternative is to require every application developer to perform what you do at the library level at the application level. This way, a developer who hits the issue is already aware of internationalisation issues, and has a chance to work out what the problem is. I don't feel particularly strongly about this, though. KP Even in western environments, it's easy to believe that the best font for KP German users will be different from that for Czech users; the coverage of KP preferred font for German might well be missing Z WITH CARON. You already know my opinion on the issue: applications should be able to fall back to different fonts upon encountering a glyph they cannot display. Heck, I actually wrote Cedilla just to demonstrate how that can be done! (Offtopic rant: but of course nobody is interested in such a low-tech solution, preferring instead to discuss the gasworks known as OpenType.) Juliusz P.S. http://www.pps.jussieu.fr/~jch/software/cedilla/ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Using current locale in font selection
Around 9 o'clock on Aug 12, Brian Stell wrote: You have hit a very important issue here: how to tell what is happening on a user's system when the bug-fixer/developer cannot reproduce the problem. Yeah, that's why I left all of the diagnostic tracing messages in fontconfig and Xft. None of it is documented, but with source in hand, you can trace what a particular request goes through in rather fine detail. One of the pieces that can be displayed is the pattern after the default substitutions have been applied; that includes the language as provide by the application or extracted from the environment. Any thoughts on what would be a good fallback if the document does not specify a language group and the document encoding does not give a hint (eg: Unicode)? I always fall back to the first available font from the generic alias. Because the aliases aren't per-language in fontconfig, there's only one place to set this. Essentially, the algorithm is: Prefer a strong family match Prefer a language match Prefer a weak family match Strong/weak is the binding as specified by the application or configuration, the default for application bindings is strong while the default for configuration bindings is weak. Two fonts both matching language get sorted according to the order of the family names provided by the application and edited by the configuration. The idea is to permit one lengthy generic alias and have the first element with matching language used for each request. This gives greater consistency to the selection when using multiple languages; each fonts in the list will be used across their supported languages automatically, except where fonts earlier in the list have support. Place 'Arial Unicode MS' first in the generic alias and you'll have a uniform (if displeasing) appearance across almost all text. One explicit goal is to permit a global configuration which is generally usable by everyone without change; any local customizations neeed to the global configuration file should be considered bugs. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Using current locale in font selection
Around 17 o'clock on Aug 12, Juliusz Chroboczek wrote: At the application level, using the user's locale is reasonable IMHO. What I object to is doing that at the library level, where the application developer might not be aware of what's happening. Applications are free to supply lang information in each font pattern; if so, fontconfig won't look further afield. If we consider applications failing to provide lang information in font patterns as broken, then the only question is whether we recover by extracting what information we can from the environment or whether we just display garbage on the screen. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Using current locale in font selection
Around 18 o'clock on Aug 12, Juliusz Chroboczek wrote: You already know my opinion on the issue: applications should be able to fall back to different fonts upon encountering a glyph they cannot display. Heck, I actually wrote Cedilla just to demonstrate how that can be done! Of course they should, but it's best to locate a font which can display all of the desired language to avoid the poor appearance generated by mixing fonts. That's why $LANG (et al.) is just a hint about which fonts might be preferred; applications are still (encouraged? required?) to recover from codepoints not supported by generating a list of suitable fonts to choose from. Fontconfig has a nice API to make this efficient and convenient; new applications are encouraged to use this mechanism. I'm interested in hearing how applications take advantage of this so that we can build some support into Xft and fontconfig to make it even easier. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
