[Fonts]Disable font scaling and make Keith happy too [patch]
Hello,
Following the objections to my previous patch, here's a version that
sports three build-time and two runtime mechanisms for configuring the
bitmap scaling code in or out. Say wow.
By default, bitmap scaling is compiled in; naked FPEs do not scale
bitmaps, the ``:scaled'' attribute can be used to enable bitmap
scaling. I understand this is the behaviour that Keith and Mike
condone.
The bitmap scaler can be compiled out with -DNO_BITMAP_SCALER; in
order to remove the ``:foo'' parsing code, don't -DFONTDIRATTRIB.
Both flags are controlled by the NoBitmapScaler Imake flag.
At runtime, the default for naked FPEs is controlled by the global
variable ``defaultScaleBitmaps''. This variable is initialised to
DEFAULT_SCALE_BITMAPS, which defaults to false. There is currently no
way to change its value at runtime other than by using a debugger. If
defaultScaleBitmaps is true, it can be overridden by using
``:unscaled''.
(Somebody could write an extension to control the value of
defaultScaleBitmaps at runtime. After all, that's no more ridiculous
than the FontCache extension.)
Juliusz
? xc/lib/font/fontfile/DONE
? xc/lib/font/fontfile/Makefile
Index: xc/lib/font/fontfile/Imakefile
===
RCS file: /cvs/xc/lib/font/fontfile/Imakefile,v
retrieving revision 3.21
diff -c -r3.21 Imakefile
*** xc/lib/font/fontfile/Imakefile 2002/02/13 21:32:48 3.21
--- xc/lib/font/fontfile/Imakefile 2002/06/03 06:32:02
***
*** 49,58
GZIP_DEFS = -DX_GZIP_FONT_COMPRESSION
#endif
ATTRIBDEFS = -DFONTDIRATTRIB
FONTENCDEFS = -DFONT_ENCODINGS_DIRECTORY=\$(FONTDIR)/encodings/encodings.dir\
! DEFINES = StrcasecmpDefines $(ATTRIBDEFS) \
$(SPEEDO_DEFINES) $(TYPE1_DEFINES) $(CID_DEFINES) \
$(FREETYPE_DEFINES) $(XTRUETYPE_DEFINES) $(FONTENCDEFS) \
$(GZIP_DEFS)
--- 49,69
GZIP_DEFS = -DX_GZIP_FONT_COMPRESSION
#endif
+ #if NoBitmapScaler
+ #if ForceFontDirAttrib
ATTRIBDEFS = -DFONTDIRATTRIB
+ #endif
+ #else
+ ATTRIBDEFS = -DFONTDIRATTRIB
+ #endif
+
+ #if NoBitmapScaler
+ BITSCALE_DEFS = -DNO_BITMAP_SCALER
+ #endif
+
FONTENCDEFS = -DFONT_ENCODINGS_DIRECTORY=\$(FONTDIR)/encodings/encodings.dir\
! DEFINES = StrcasecmpDefines $(ATTRIBDEFS) $(BITSCALE_DEFS)\
$(SPEEDO_DEFINES) $(TYPE1_DEFINES) $(CID_DEFINES) \
$(FREETYPE_DEFINES) $(XTRUETYPE_DEFINES) $(FONTENCDEFS) \
$(GZIP_DEFS)
Index: xc/lib/font/fontfile/fontdir.c
===
RCS file: /cvs/xc/lib/font/fontfile/fontdir.c,v
retrieving revision 3.18
diff -c -r3.18 fontdir.c
*** xc/lib/font/fontfile/fontdir.c 2001/12/14 19:56:51 3.18
--- xc/lib/font/fontfile/fontdir.c 2002/06/03 06:32:02
***
*** 34,39
--- 34,49
#includefntfilst.h
#includeX11/keysym.h
+ /* Whether to scale bitmap fonts when neither :unscaled nor :scaled
+ * are present. If a different default is desired, the command-line
+ * parsing code should set this. */
+
+ #ifndef DEFAULT_SCALE_BITMAPS
+ #define DEFAULT_SCALE_BITMAPS 0
+ #endif
+
+ int defaultScaleBitmaps = DEFAULT_SCALE_BITMAPS;
+
Bool
FontFileInitTable (FontTablePtr table, int size)
{
***
*** 654,681
(vals.values_supplied PIXELSIZE_MASK) != PIXELSIZE_ARRAY
(vals.values_supplied POINTSIZE_MASK) != POINTSIZE_ARRAY
!(vals.values_supplied ENHANCEMENT_SPECIFY_MASK);
#ifdef FONTDIRATTRIB
#define UNSCALED_ATTRIB unscaled
! /* For scalable fonts, check if the unscaled attribute is present */
! if (isscale dir-attributes dir-attributes[0] == ':') {
! char *ptr1 = dir-attributes + 1;
! char *ptr2;
! int length;
! int uslength = strlen(UNSCALED_ATTRIB);
!
! do {
! ptr2 = strchr(ptr1, ':');
! if (ptr2)
! length = ptr2 - ptr1;
! else
! length = dir-attributes + strlen(dir-attributes) - ptr1;
! if (length == uslength !strncmp(ptr1, UNSCALED_ATTRIB, uslength))
! isscale = FALSE;
! if (ptr2)
! ptr1 = ptr2 + 1;
! } while (ptr2);
! }
#endif
if (!isscale || (vals.values_supplied SIZE_SPECIFY_MASK))
{
/* If the fontname says it is nonScalable, make sure that the
--- 664,710
(vals.values_supplied PIXELSIZE_MASK) != PIXELSIZE_ARRAY
(vals.values_supplied POINTSIZE_MASK) != POINTSIZE_ARRAY
!(vals.values_supplied ENHANCEMENT_SPECIFY_MASK);
+
+ if (isscale) {
+ int surelyScale = FALSE;
+
#ifdef FONTDIRATTRIB
#define UNSCALED_ATTRIB unscaled
! #define SCALED_ATTRIB scaled
! /* For scalable fonts, check if the unscaled or scaled attribute
! * is present */
!
!
Re: [Fonts]Re: Font lookup ranges [was Re: Notes on Pango Xft backend]
Brian Stell [EMAIL PROTECTED] writes: Owen Taylor wrote: ... Pango already has the language tagging mechanism; the question is how to use this to influence character lookup. a) Call FcFontSetSort() once, get a list, and then when finding a (language-tag, codepoint) pair, look first for a font with the language tag and the codepoint, then if that fails, look for a font without the language tag with the codepoint. Problems: - ... - I don't think we should ever fall back to a font that wasn't explicitely specified (*), just for a want of a language tag. Please forgive me if I'm being slow but due to the triple negative I am not clear what the last statement means (I did read the footnote). What I mean is if I'm trying to look up a traditional chinese font for codepoint X, codepoint X also is present in japanese fonts, and their are two choices: a) japanese font, explicitely specified b) traditional chinese, not explicitely specified it seems to me that we should prefer a). Reasons: - Non-explicitely-specified fonts might differ in major ways (we might get a bold-italic font...) - There should be a way for users to override what we are doing, especially if we are doing guesses for font language based on codepoint coverage. Regards, Owen ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Re: Font lookup ranges [was Re: Notes on Pango Xft backend]
Yao Zhang [EMAIL PROTECTED] writes: From your coverage map, it is easy to tell which category the font is in. But in my opinion, combining different Chinese fonts together to get a bigger coverage is generally not a good idea. I see this kind of thing happens in Mozilla, GTK+ 2. When I see it, the only effect is that it tells me I should change my font settings, the same as I see undisplayable, square substitute showing on my screen. So why go through all the trouble to implement something no one will like. The question being discussed here is not combining multiple fonts ... Pango already does this; it's pretty much a requirement if you want to be able display multilingual text. (The alternative is that the document creator knows exactly what fonts the user has on their system and specifies those fonts.) The question is how to combine multiple fonts in a way that avoids the mixed appearance that you are seeing. Frequently, we do know the language of the text, either because the text is tagged with the language, or because we can assume that it matches the user's settings. In these cases we should prefer fonts that include all the characters of the language, so we don't have to use additional fonts that don't match the style of the original text. Regards, Owen ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]xterm, ncurses, fonts
Hi, I develop an application, which uses ncurses. I want to use the vga-Font under xterm. Allmost all Chars are shown correct, but for example the char 132 is shown as an special char. How can I introduce Xterm, to show this char as an รค ? The char 132 is only an example. Thanks in advance Markus Wenke ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Re: Font lookup ranges [was Re: Notes on Pango Xft backend]
Yao Zhang [EMAIL PROTECTED] writes: From [EMAIL PROTECTED] Thu May 30 13:28:11 2002 Around 12 o'clock on May 30, Yao Zhang wrote: From your coverage map, it is easy to tell which category the font is in. But in my opinion, combining different Chinese fonts together to get a bigger coverage is generally not a good idea. It's good to know we can intuit the language tag from the Unicode coverage, that will make using Type1 fonts (and others without OS/2 tables) easier. I am still trying to understand what a language tag is. If for a font, it means the font is designed for one region, then we can say category #1 and 2 is for zh_CN (mainland China) and probably zh_SG (Singapore), #3 is for zh_TW (Taiwan), zh_HK (Hong Kong) and zh_MO (Macau). I am not sure about #4 and 5. A font in category 4 or 5 could be for any of the above, and even ja_JP or ko_KR? I think Keith's use of the term language tag to refer to how fonts are tagged is a little bit confused.; a language tag identifies the language for the _text_. This is then used to choose a font. The language support identifiers for fonts don't have to be the same thing; you can easily have: zh-tw = FC_LANG_SIMPLIFIED_CHINESE zh-hk = FC_LANG_SIMPLIFIED_CHINESE zh-cn = FC_LANG_SIMPLIFIED_CHINESE zh-sg = FC_LANG_SIMPLIFIED_CHINESE Unfortunately, the common form of 'language-country' of a language tag doesn't work perfectly for traditional vs. simplified Chinese, since there isn't a one-to-one correspondence. Pango doesn't enforce the language-country form on language tags; so if some other identifiers become common for representing this distinction, support for them can be easily added. The question being discussed here is not combining multiple fonts ... Pango already does this; it's pretty much a requirement if you want to be able display multilingual text. (The alternative is that the document creator knows exactly what fonts the user has on their system and specifies those fonts.) The question is how to combine multiple fonts in a way that avoids the mixed appearance that you are seeing. z What I am trying to say is that the current implementation goes to far to combine different Chinese fonts together or even different CJK fonts together. In my opinion, that is bad. They could be in different combined font, not in one combined font. I don't understand this distinction; the idea is that you specify a single alias (say Sans-serif) to be used for an entire document; and you want the system to do the right thing. Being able to do the right thing without user intervention. - The user may be viewing text in a mix of languages. - The software doesn't expose a font configuration mechanism. What happens when the user specifies a particular font, say a Japanese font Mincho Gothic, and the text contains non-supported characters is indeed not all that important; it's a pathalogical case, and the results aren't expected to be pretty. Regards, Owen ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Re: Font lookup ranges [was Re: Notes on Pango Xft backend]
Keith Packard [EMAIL PROTECTED] writes: b) Call FcFontSetSort() separately for each language, and somehow influence the sort order; what we'd like to do is make including the specified language tag have an weight: Language tags are currently given greater weight than family names, but given two families which both support the requested language tag, they will be ordered by family name. This algorithm is used by Mozilla and works reasonably well, as you say there are still some significant issues. One important detail -- language tags are only used when attempting to disambiguate fonts with Han glyphs; in all other cases, language tags are not passed to the matching routine at all. Hmmm, limiting font tag usage to CJK definitely would reduce the possible harm that could result; and probably makes sense. (At least initially.) Pango would simply contain a small table mapping language tags onto FC_LANG attributes to add. c) Pango adds the language tag to the pattern it feeds to FcConfigSubstitute, and fonts.conf does pattern matching magic to provide a different Sans-serif alias for every language. Can't say I like this too much: - Requires lots of careful configuration (more than just slapping extra fonts into Sans-serif.) Configuration is bad. I don't think it requires careful configuration; the config file just needs to list all of the fonts that are 'sans-serif' in the definition of the 'sans-serif' alias. Once placed in the pattern, the language tag will force the appropriate one to be selected in preference to the others, and the preference order in the sans-serif alias definition will refine the selection. Do you think this would work: if (language_tag == Han language) PatternAddInteger (FC_LANG, language_tag) FcConfigSubstitute FcFontSetSort This is fine; I thought you were suggesting something that would involve conditionalizing on language in fonts.conf. with the config file containing: alias familysans-serif/family prefer familyMS Gothic/family familyAR PL KaitiM Big5/family familyNorasi/family familyGaruda/family familyArial Unicode MS/family /prefer /alias Ask for sans\-serif:lang=traditionalchinese and this will pick AR PL KaitiM Big5 instead of Arial Unicode MS. I'm worried that with this same configuration file We have: - User is running in ja_JP locale so the default language tag for Pango is 'ja-jp' - They pull up a Traditional Chinese document (not itself tagged) in their word processor and see that it is a mix of MS Gothic and AR PL KaitiM Big5. - They select AR PL KaitiM Big5 from the font menu. - The display doesn't change because Xft is still finding MS Gothic which matches the language tag. If the user has explicitely chosen a font, and it has the characters, I think there is an obligation to use it. Regards, Owen ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Re: Font lookup ranges [was Re: Notes on Pango Xft backend]
Around 18 o'clock on Jun 3, Owen Taylor wrote: Hmmm, limiting font tag usage to CJK definitely would reduce the possible harm that could result; and probably makes sense. (At least initially.) I'm hoping that CJKV will remain the only broken part of Unicode in the future; it appears that the Unicode group has become a bit more sensitive to local objections over unification. The expansion from 16 to 24 bits has given them a lot more flexibility. If we could come up with a mechanism that left this bit of policy down in fontconfig, that would centralize any future extensions. That isn't what we're doing here though. This is fine; I thought you were suggesting something that would involve conditionalizing on language in fonts.conf. Hmm. We could do something like: if (language_tag not member (japanese, traditional, simplified, korean, vietnamese)) delete language_tag in the fonts.conf file -- this would place the policy over how language tags affect font selection down inside fontconfig which would reduce the number of places fixes would need to be applied if the set of necessary language tags ever increases. - They pull up a Traditional Chinese document (not itself tagged) in their word processor and see that it is a mix of MS Gothic and AR PL KaitiM Big5. - They select AR PL KaitiM Big5 from the font menu. - The display doesn't change because Xft is still finding MS Gothic which matches the language tag. It matches the locale language tag, but the document doesn't have a language tag. Are you suggesting that the locale language tag be used for documents which have no language tag? Hmm. This is getting complicated. Let's look at what happens down inside fontconfig and see if we can't make some sense. - They pull up a Traditional Chinese document (not itself tagged) in their word processor and see that it is a mix of MS Gothic and AR PL KaitiM Big5. With an unspecified family, fontconfig will build the pattern: family: sans-serif alias familysans-serif/family prefer familyMS Gothic/family familyAR PL KaitiM Big5/family familyNorasi/family familyGaruda/family familyArial Unicode MS/family /prefer /alias This alias will edit the pattern to: family: MS Gothic, AR PL KaitiM Big5, Norasi, Garuda, Arial Unicode MS, sans-serif In the absense of language tags, this will prefer MS Gothic and fall back to AR PL KaitiM Big5 for glyphs missing from that. This depends on the correct ordering of fonts within this alias; something which seems a bit fragile. - They select AR PL KaitiM Big5 from the font menu. Now the pattern changes: family: AR PL KaitiM Big5, sans-serif The edit converts this to: family: AR PL KaitiM Big5, MS Gothic, AR PL KaitiM Big5, Norasi, Garuda, Arial Unicode MS, sans-serif In the absense of language tags, this will match the Big5 font. If we apply the locale language tag when it represents a Han language, then we'll *always* pick MS Gothic; the language tag has higher precedence than the font family in the selection process. This is clearly wrong; the users font specification should always be more important than a language-tag driven fallback. Somehow, we need to use the language tag when selection which fallback font to pick, but not when choosing between real family names provided by the application. Hmm. It feels like there is a cut-over in the list of families; the first part of the list is language tag independent -- family names provided by the application should normally be preferred to families selected by language tag, family names used as fallbacks should be ordered by language tag fit. Here's a suggestion (please feel free to knock holes in it): Tag entries in the family list as to whether they're language-tag selected or not language-tag selected (or perhaps just whether they're fallback or non-fallback entries). Edits relative to those entries are contaminated and the resulting entries inherit that state. Now the config file tags the 'sans-serif' alias as a 'fallback' entry; now those entries are matched based on the distance from the language tag (as well as the order within the list). I am still planning on adopting pure CSS2 matching for fontconfig -- I have a sense that CSS2 matching would solve this problem; I'll go and read that spec again and try to make sense of this. If it does, it may be that we should always supply the language tag to fontconfig and expect that the matching rules will generate a reasonable match. Keith PackardXFree86 Core TeamHP Cambridge Research Lab
[Fonts]Xft for OpenGL
Does Xft build/work under OpenGL? -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Xft for OpenGL
Around 18 o'clock on Jun 3, Brian Stell wrote: Does Xft build/work under OpenGL? Xft isn't a GL library, it's an X library. However, it certainly would be possible to hook fontconfig and freetype together for 3D apps. Xft is a pretty small chunk of code now that it doesn't do anything except plug X, fontconfig and FreeType together; a GL-specific library should be of similar (if not smaller) size. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Xft for OpenGL
Around 20 o'clock on Jun 3, Jon Smirl wrote: It would be really nice for embedded systems to have Freetype, fontconfig and Pango packaged into a standalone library without any dependencies on the rest of X or glib. All three have no necessary dependencies on X. Of course Pango relies on glib, but it doesn't rely on X either -- only the Xft output render does. GTK and Xlib versions of Mozilla are already basically using all three. Freetype is being used as is but with a horribly messy kludge to look for missing glyphs. The 1.0 Mozilla code for using FreeType does not use fontconfig; it uses FreeType directly. Chris Blizzard and I have a separate patch that uses Xft and fontconfig which we hope to get integrated into Mozilla when it's ready for production use. Fontconfig provides for missing glyph identification, implicitly through the loca table by using the regular FreeType API to find blank glyphs which aren't supposed to be blank. Direct use of the loca table might make the process somewhat faster, but still not fast enough to avoid needing to cache the results. And Sun has just built in a de-glib'd version of Pango to get shaping support for Thai. I'll bet they just integrated the handful of glib functions needed by pango -- glib really isn't a gtk-specific library, it's just a bunch of C utility routines. I'm hoping to see a concensus build around a reasonable shaping library in the next year or so; we've got several implementations and I'm hoping application developers get enough experience to guide the selection of an appropriate toolkit/windowsystem/font independent text layout library. Couple a layout engine with a font configuration engine and a glyph rendering engine and you've got a complete text system; it would be nice if these three pieces could be plugged together at will; the only piece I question not sharing is the font configuration piece -- standarizing on one provides for a shared font database among all applications. Of course, I haven't demonstrated that fontconfig is up to the task in all cases yet, but I'm willing to try. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Xft for OpenGL
--- Keith Packard [EMAIL PROTECTED] wrote: The 1.0 Mozilla code for using FreeType does not use fontconfig; it uses I meant that Mozilla has implemented code similar to fontconfig, not that it used fontconfig. Another case of this is the MiniXFT driver in Pango. ..missing glyph, loca... make the process somewhat faster, but still not fast enough to avoid needing to cache the results. The Linux code is detecting the missing glyphs in all fonts and caching to disk. I have a lot of fonts installed and this processes takes over 2 minutes on a 1.1Ghz Athlon. But it only happens once. The Windows code uses the loca table to compute the data when the font file is first opened. It is then cached in memory. It is fast enough that I can only even notice it when I load Unicode Arial. I'll bet they just integrated the handful of glib functions needed by pango -- glib really isn't a gtk-specific library, it's just a bunch of C utility routines. I didn't dig into the Sun code yet. Here's a pointer. http://lxr.mozilla.org/seamonkey/source/extensions/ctl/ one provides for a shared font database among all applications. Of course, I haven't demonstrated that fontconfig is up to the task in all cases yet, but I'm willing to try. How does fontconfig interact with CSS rules for font selection? How close is the fontconfig patch to being ready? After Mozilla 1.0 is out it should be easier to add code that isn't 100% stable. = Jon Smirl [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
