Xft and MathML [Was: [Fonts]Xft for OpenGL]
Keith Packard wrote: ... I'd like someone with a real understanding of how MathML is supposed to work Do you know Roger Sidje? Roger B. Sidje [EMAIL PROTECTED] Have you seen this page: http://www.mozilla.org/projects/mathml/ to lead me through how Xft and fontconfig could help Mozilla display MathML pages better. The current non-Xft MathML support is far from perfect; it knows the encoding of a select set of fonts and if you have different ones, you get incorrect glyphs on the screen. Displaying the wrong glyph is never reasonable, I'd like to figure out how to make it either display the right glyph or let the user know that no such glyph is available. Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: Saving memory in fontconfig
KP This shows sub-linear growth in memory vs the number of fonts; I KP need to try even larger sets to get a better sense of the actual KP function here. Should I take this as meaning that the bitmaps dominate over the bureaucratic overhead, right? If so, could you try with 128-codepoint pages? A significant part of Unicode is organised into 128-codepoint ranges. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Xft2 and pcf fonts
Yu Shao [EMAIL PROTECTED] writes:
Hi Keith,
I tested Xft2 with some Chinese pcf fonts, like gb16fs.pcf.gz come
with Xfree86 4.2, but seems Xft2 could only find the truetype fonts
from directories listed in fonts.conf. How should we handle those
non-truetype fonts?
I looked at this issue a bit and it appears that the problem is the
FC_ANTIALIAS parameter; bitmap fonts end up with FC_ANTIALIAS=FcFalse in
their pattern, but XftFontMatch/XftDefaultSubstitute add
FC_ANTIALIAS=FcTrue by default.
(The appended code snippet illustrates the lack of the match
if you have the LucidaTypewriter PCF fonts from XFree86 in a directory
in your fonts.conf)
I believe the correct solution is to simply remove the code in
fontconfig that adds FC_ANTIALIAS=FcFalse for non-scaleable fonts.
It seems to me that FC_ANTIALIAS should indicate the _desired_
antialiasing, not whether the font can actually be effectively
antialiased.
Regards,
Owen
#include fontconfig/fontconfig.h
#include stddef.h
int
main (int argc, char **argv)
{
FcConfig *config = FcInitLoadConfigAndFonts ();
FcFontSet *system_set = FcConfigGetFonts (config, FcSetSystem);
FcPattern *pattern;
FcPattern *pattern_result;
FcResult result;
pattern = FcPatternBuild (NULL,
FC_FAMILY, FcTypeString, LucidaTypewriter,
FC_STYLE, FcTypeString, Bold,
FC_ANTIALIAS, FcTypeBool, 1,
NULL);
FcConfigSubstitute (config, pattern, FcMatchPattern);
pattern_result = FcFontSetMatch (config, system_set, 1, pattern, result);
FcPatternPrint (pattern_result);
return 0;
}
___
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: - 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. Yes, GTK+ does this currently ... it always provides a default language tag for every Pango context based on the locale; the idea is that: - most documents a user views are in their own language. - user's will typically not be offended by seeing their own variants for characters with multiple display variants, even for other lanugages. - we then don't need a _separate_ mechanism for configuring the default fonts for different users. [...] 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. This seems similar to the idea of explicitely specified fonts I tried to develop in: http://mail.gnome.org/archives/gtk-i18n-list/2002-May/msg00053.html Though I was thinking of doing language-tag selection for both explicitely specified and not explicitely specified fonts, just not between the two. 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). That sounds reasonable to me; I was thinking of a slightly different mechanism which would effectively track a position in the family list where everything before that position was not fallback, and everything after that position was fallback: Basically, we want family names that were explicitely given by the user, or family names where the expansion only involved prefer elements. But that's probably even more complicated to implement, magical, and confusing. Regards, Owen ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: Saving memory in fontconfig
Around 7 o'clock on Jun 4, Brian Stell wrote: Keith: have you considered sharing whole maps? I have not formally measured this but my impression is that related fonts, Arial/Arial-Italic/Arial-Bold/Arial-Bold-Italic, often map the same chars. I believe the windows mozilla code does check for and share whole maps. Yes, the sharing is recursive so that fonts which are sharing every page end up sharing the top level as well. That's why the number of CharSets is (significantly) less than the number of fonts. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: UTF-16 [was: Re: Xft and MathML [Was: [Fonts]Xft for OpenGL]]
Around 23 o'clock on Jun 4, Roozbeh Pournader wrote: Sorry, but there is nothing named a UCS-2 surrogate. UCS-2 with surrogates is named UTF-16. UCS-2 explicitly tells that it has no mechanism for encoding characters outside BMP. I was under a misapprehension that UCS-2 + surrogates was somehow different from UTF-16. Thanks for the clarification. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: Adobe Glyph Names - Unicode 3.2 (was: Xft and MathML)
Around 21 o'clock on Jun 4, Markus Kuhn wrote: and (from what I heared) about to revise the entire thing to add the Unicode 3.2 mappings for many of the glyphs that were so far mapped into the Adobe Corporate Use Area. In case he has already a draft of that, it might save both you and the Mozilla MathML people some (guess)work. Thanks very much. I'm more interested in discovering whether the existing fonts used for MathML include these glyph names so that I can at least depend on the names. Ensuring that I use standard Unicode codepoints at the Xft API level is a bonus feature that will be hidden to from the bulk of Mozilla's current PUA codepoint adventure. I'm currently busy getting pango and fontconfig talking sweetly, so I won't be able to explore MathML right now. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: Adobe Glyph Names - Unicode 3.2 (was: Xft and MathML)
Keith == Keith Packard [EMAIL PROTECTED] writes: Keith I'm more interested in discovering whether the existing fonts Keith used for MathML include these [adobe recomended] glyph names so Probably not. The (postscript versions of the) interesting math fonts I beleive all predate adobe's glyph naming recomendations. (At least for the TeX-related ones; I cannot speak definitively on mozilla's other set of recomended math fonts (by bitstream for corel, yes?).) If you have a full tetex install, check out eg: /usr/share/texmf/fonts/type1/bluesky/cm/cmmi10.pfb /usr/share/texmf/fonts/type1/bluesky/cm/cmsy10.pfb with t1disasm to get the glyph names. Another interesting example are the lucida math fonts. The afms are included in tetex in: /usr/share/texmf/fonts/afm/yandy/lumath/ None of the glyphs in these fonts which are in unicode but not in adobe's glyphlist.txt follow the uni or uXX name format. Even some of the glyphs which are in glyphlist.txt may not have the same name as adobe recommends. For the (type1) math fonts you will need font-specific glyphname to unicode codepoint tables. Even the ttf versions of these fonts will probably need such a table. It would presumably be useful were these tables in text files a la the enc files used by X for server-side fonts or by TeX-related utilities such as dvips, et al. -JimC ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: Adobe Glyph Names - Unicode 3.2 (was: Xft and MathML)
Around 20 o'clock on Jun 4, James H. Cloos Jr. wrote: Probably not. The (postscript versions of the) interesting math fonts I beleive all predate adobe's glyph naming recomendations. (At least for the TeX-related ones; I cannot speak definitively on mozilla's other set of recomended math fonts (by bitstream for corel, yes?).) Of the 231 unique glyph names in the blue sky math fonts, 66 are not represented in glyphnames.txt. THat's better than I feared. I think what I can do is allow multiple glyphname-Unicode mapping files in the format of the glyphlist.txt and manually build a separate transcoding file for the glyph names not present in the standard file. fontconfig already unifies multiple encoding tables into a single unicode mapping function -- many fonts have incomplete Unicode maps which must be suplemented from the apple roman map. Adding character names just extends that function. That allows me to get from Unicode 3.2 codepoints to glyphs; now I need to get from the mozilla PUA codepoints to Unicode 3.2 codepoints. A definitive list of the PUA codepoints that are used would be very useful here. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
