Re: [Fonts]syntax for disabling using embedded bitmaps for specific font size ranges
On Thu, Dec 05, 2002 at 05:38:24PM -0800, Keith Packard wrote: instead. You can add size tests inside the match element if you like to narrow the range to specific sizes. As an example, here is what I use for a traditional Chinese font: match target=font test name=family compare=eq stringMingLiU/string /test or test name=family compare=eq stringPMingLiU/string /test /or test name=size compare=more_eq double8/double /test test name=size compare=less_eq double12/double /test test target=pattern name=slant compare=eq constroman/const /test edit name=antialias mode=assign boolfalse/bool /edit /match -- Roger So Debian Developer Sun Wah Linux Limitedi18n/L10n Project Leader Tel: +852 2250 0230 [EMAIL PROTECTED] Fax: +852 2259 9112 http://www.sw-linux.com/ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]About Fcpackage and Li18nux2K.
On Sat, Sep 07, 2002 at 09:54:31AM +0800, Zenith Lau wrote: I have recently read the Li18nux2K. The globalization spec. from li18nux.org. but it seems that, there is no any relation between fontconfig/Xft and this spec. IMHO, Li18nux2K regulate and standardize the direction of i18n while, fontconfig/Xft is complete font management for fonts and the next trend in drawing in X. Why fontconfig/Xft doesn't appear in that spec. ? Because, at the time LI18NUX2000 was drafted, fontconfig/Xft2 didn't exist, and Xft was quite new (and immature). Also, LI18NUX2000 was mostly about documenting the (then) best practice. On the other hand, I remember this is some projects on fonts and type service from Li18nux.org. I afraid there will be two set of facility regard fonts handling in further, if there is no cooperation between fontconfig/Xft and li18nux. Perhaps you're talking about the STSF? http://stsf.sourceforge.net But personally, I think fontconfig/Xft is fast becoming the defacto standard anyway, at least on Linux. -- Roger So Debian Developer Sun Wah Linux Limitedi18n/L10n Project Leader Tel: +852 2250 0230 [EMAIL PROTECTED] Fax: +852 2259 9112 http://www.sw-linux.com/ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Fcpackage RC3
On Mon, Aug 26, 2002 at 01:38:52PM -0700, Keith Packard wrote: + Eliminate FC_PATTERN and FcTypePattern in favor of an extended api for FcConfigSubstitute which takes both the font and the pattern. Seems like the Xft1 in fcpackage.rc3 still uses FcTypePattern: ] gcc -c -O2 -fno-strength-reduce -g -I/usr/include/freetype2 ] -I/usr/X11R6/include-Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L ] -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE ] -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API ] -DFREETYPE2 -fPIC xftlist.c ] xftlist.c: In function `XftListFonts': ] xftlist.c:155: `FcTypePattern' undeclared (first use in this function) ] xftlist.c:155: (Each undeclared identifier is reported only once ] xftlist.c:155: for each function it appears in.) ] make: *** [xftlist.o] Error 1 Regards Roger -- Roger So Debian Developer Sun Wah Linux Limitedi18n/L10n Project Leader Tel: +852 2250 0230 [EMAIL PROTECTED] Fax: +852 2259 9112 http://www.sw-linux.com/ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Fcpackage RC3
On Tue, Aug 27, 2002 at 08:36:42AM -0700, Keith Packard wrote: Around 21 o'clock on Aug 27, Roger So wrote: Seems like the Xft1 in fcpackage.rc3 still uses FcTypePattern: Do you have an old fcprivate.h installed somewhere that xftlist.c is picking up? There could be a build or install bug which is not getting that file replaced. Yup, I have fontconfig RC2 installed a few days ago with --prefix= /usr/X11R6, and that installed fcprivate.h: $ ls -l /usr/X11R6/include/fontconfig/fcprivate.h -rw-r--r--1 root root 4153 2002-08-24 14:14 /usr/X11R6/include/fontconfig/fcprivate.h This timestamp is later than the one for fcprivate.h in RC3, and that's probably why the Makefile won't install it. 'install' doesn't preserve timestamps unless given '-p', so I think this is a bug in the current Makefile.in. Thanks Roger -- Roger So Debian Developer Sun Wah Linux Limitedi18n/L10n Project Leader Tel: +852 2250 0230 [EMAIL PROTECTED] Fax: +852 2259 9112 http://www.sw-linux.com/ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Re: [I18n]Unicode coverage for languages
On Sat, 2002-07-06 at 13:34, Keith Packard wrote: My plan is to have fonts advertise the complete set of languages that they cover, and then to allow them to further distinguish languages with country codes as needed (zh-TW vs zh-CN). Now matching can take place using the language tags; a font supporting the language for a different country will match less strongly than a font matching the language for the correct country. Both of these will match more strongly than a font not supporting the language at all. This has the benefit of making traditional Chinese fonts preferred over Japanese fonts for the display of simplified Chinese documents. I think this will work better than the current hack using OS/2 codePageRange bits. Certainly; but have you considered the case that zh-HK and zh-MO users prefer zh-TW fonts over zh-CN fonts, and vice versa for zh-SG? (What other Chinese-speaking regions are there... perhaps zh-MY?) To complicate matters, zh-HK uses traditional Chinese, but with more characters than usually is with zh-TW. (Big5 vs Big5 HKSCS) And of course, many fonts from China now cover most characters defined in GB18030, which means if using coverage tables, these fonts will appear to support both zh-CN and zh-TW... Otherwise, I think using RFC-3066 is a good idea. I've only considered Chinese here as I'm a native Chinese speaker; and I don't think these problems crop up in other languages. -- Roger So Debian Developer Sun Wah Linux Limitedi18n/L10n Project Leader Tel: +852 2250 0230 [EMAIL PROTECTED] Fax: +852 2259 9112 http://www.sw-linux.com/ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
