[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
On Thu, 2005-12-08 at 09:26 -0700, Mark Leisher wrote: Being lazy, I'm asking here before actually looking around. Can anyone recommend programs that create [OT]TF fonts from BDF fonts? Juliusz wrote fonttosfnt which combines multiple BDF sizes into a single SFNT. It's in CVS at freedesktop.org in the xapps module $ cvs -d :pserver:[EMAIL PROTECTED]:/cvs/xapps co fonttosfnt should do the trick. It's reasonably functional, the plan was to use it to eliminate BDF/PCF fonts from the X distribution and ship only TTF files. That's been stalled for a couple of years as we need to preserve all of the mystic BDF properties, and be able to regenerate BDF fonts as needed (BDF being the only X standard for font distribution). -keith signature.asc Description: This is a digitally signed message part
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
On Fri, 2005-12-09 at 01:07 +0100, Werner LEMBERG wrote: Hmm, why not simply adding a special `BDF ' table which holds all properties? This should be straightforward, and you get lossless conversion. Yes, this was my plan. I got side-tracked before I managed to implement it though. I need this + a utility to regenerate BDF files from the TTF so I can validate a lossless round-trip for the existing BDF files. If anyone wants to pick up this little project, I can assure them that once working, I'll delete all of the BDF files from the X.org CVS repository and never ship them again, and we'll also deprecate all of the horrid BDF-based font tools. Note that the X server already happily loads these .TTF fonts, and will even automatically transcode them to generate any of the supported encodings, so we actually gain functionality, reduce disk space usage, reduce code size and eliminate build-time font compilation. There aren't many projects offering this kind of win-win-win-win proposition... -keith signature.asc Description: This is a digitally signed message part
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
On Wed, 2005-12-14 at 22:16 +0100, David Turner wrote: I'd like to know the following: - is this feature useful for fontconfig / libXft ? Or should we yank it from FreeType ? It's not terribly useful for fontconfig or libXft, where it is useful is in converting sfnt back into BDF files in case you want to take a font and use it with old non-TTF supporting X servers. - I don't understand completely the difference between atoms and non-property strings. Aren't these the same things ? Why distinguish them then ? All I care about is regenerating a matching BDF file; I'd like to see whatever it takes to preserve every aspect of the original font files. -keith signature.asc Description: This is a digitally signed message part
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
On Wed, 2005-12-21 at 15:18 +0100, Juliusz Chroboczek wrote: It's not terribly useful for fontconfig or libXft, where it is useful is in converting sfnt back into BDF files in case you want to take a font and use it with old non-TTF supporting X servers. Well, that you already can do, using fstobdf (it's still in the tree, right?). Now, if there are clients that still make use of ad hoc font properties, they should be shot. Right, we can easily generate a BDF file, but without some place to store the properties that only BDF exposes in the TTF file, we'll lose some data. It's probably not terribly important data, but I think saving all of it is a prerequisite for switching from BDF to SFNT files as the canonical delivery and archival mechanism. -keith signature.asc Description: This is a digitally signed message part
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
On Wed, 2005-12-21 at 09:36 -0800, George Williams wrote: On Thu, 2005-12-08 at 10:50, Keith Packard wrote: should do the trick. It's reasonably functional, the plan was to use it to eliminate BDF/PCF fonts from the X distribution and ship only TTF files. That's been stalled for a couple of years as we need to preserve all of the mystic BDF properties, and be able to regenerate BDF fonts as needed (BDF being the only X standard for font distribution). I can now convert the bdf properties with fonttosfnt but I neglected to note that fonttosfnt fails to preserve the bdf SWIDTH values (the unscaled PostScript widths of each glyph). Hmm. We want the same effect as FT_LOAD_NO_SCALE; is there some way to make this work here? Obviously you wouldn't get a bitmap, but you should be able to see the values in font units. So I shall give up on my attempts to produce a round-trip bdf-sfnt-bdf path based on fonttosfont. So this is the only limitation? For purposes of X font distribution, this might be tolerable as X provides no mechanism to expose SWIDTH in any case. FontForge can provide a round-trip path. That's certainly an acceptable alternative; as I said, I'm only interested in verifying the accuracy of the round-trip so we can discard the BDF files and distribute only the TTF versions. Those are already usable by any recent X.Org or XFree86 X server, so it's purely a matter of ensuring that people running legacy X servers can get at the font contents through some known mechanism. -keith signature.asc Description: This is a digitally signed message part
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
On Tue, 2006-01-17 at 15:12 -0800, George Williams wrote: I was told so when I implemented them in fontforge. But I wasn't in the initial discussions so I'm not the best source. I also recall discussions which discovered that the .otb extension was otherwise unused in most of the world. It doesn't matter at all to me; I ask FreeType to try and open the font, completely ignoring the extension has proven a valuable property, although it does sometimes challenge the FreeType font file handling code with 'unusual' file data. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
[Fonts] Re: Choosing an extension for bitmap-only SFNTs
Around 1 o'clock on Jul 10, Juliusz Chroboczek wrote: I suggest they should have the extension ``.sfnt'', with ``.sfn'' being recognised for compatibility with 8+3 systems. While using four letter extensions would be nice, I'm afraid there remain file system formats which provide for only three letters that are commonly used in systems which run X. Floppies, flash cards and other devices continue to use FAT file systems, and while there are kludges around to provide long file names, those aren't always well supported nor compatible. So, if we accept only a four letter extension we will have issues distributing fonts on floppies, flash cards and USB keychain drives. Juliusz suggests accepting either .sfnt or .sfn to work around this problem. That's how the world deals with the .html extension -- software all knows that .html and .htm are equivalent. I'd rather avoid this complexity in every new piece of software that deals with fonts (not that fontconfig or FreeType really care, but other pieces of software do). Instead, I think we can probably come up with a single three letter extension to use; perhaps something like: .ttb- true type 'bitmap' font .otb- open type 'bitmap' font .tts- true type 'sfnt' font .ots- open type 'sfnt' font .otb appears to be used for Nokia Phone Graphics files of some kind and .ots appears used by the OtsJuke application for sound files, but neither .ttb nor .tts appear used at the current time. This is certainly not intended to be an exhaustive list of possibilities, but I would like to limit discussion to viable three letter extensions. I agree with Andrew C Aitchison that the .sfn extension is probably a bad idea, both because it may be easily confused with .snf and also because SPX Fonts already use the .sfn extension. -keith ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Re: [Fontconfig] May these patches go into next release?
Around 16 o'clock on Feb 28, Yun-Ta Tsai wrote: I found some patches that will fix several truetype fonts problems with asian characters both on printing to printer and showing on screen, also support asian font name. Unfortunatelly, I can't patch by myself because qt keep releasing , so I require for help. Three packages are needed to be patched: xft2, fontconfig, and libqt3c102 which will be a little bit nasty. Please open suitable bug reports for fontconfig issues at http://fontconfig.org/bugzilla and supply patches relative to current CVS instead of version 2.1. Each problem will need a separate bugzilla entry that includes enough information about what is wrong to evaluate whether the supplied patch is the right way to fix the issue. From looking at the patch as supplied, I believe many of the issues are likely resolved in current fontconfig CVS versions. -keith ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] Problem with XRenderCompositeText16 in Render extension
Around 6 o'clock on Feb 19, ITO Tsuyoshi wrote: According to the code of the Render extension on X server side, XRenderCompositeText16 should send a glyphset-switch sign (a glyph element with len = 0xff) to the X server when it encounters a glyph element whose glyphset is different from the one of the previous glyph element. However, it actually sends the glyphset-switch sign when it encounters a glyph element whose glyphset is different from the one of the _first_ glyph element. Your analysis is quite correct. A fix solving this issue was placed in XFree86 CVS on 2002-8-31. -keith ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] Re: where to include ~/.fonts.conf
Around 22 o'clock on Feb 8, Mike FABIAN wrote: To make it possible to override as much as possible of the global settings in /etc/fonts/fonts.conf with user preferences in ~/.fonts.conf, it seems to be better to put the line The subtleties of the contents of /etc/fonts/fonts.conf appear to be lost here. The placement of the include of ~/.fonts.conf is intended to carefully allow overriding of all of the values in /etc/fonts/fonts.conf. In particular, because prefer aliases insert names directly ahead of the matching family, the sequence: !-- in ~/.fonts.conf -- alias familysans-serif/family prefer familyArial/family /prefer /alias ... !-- in /etc/fonts/fonts.conf -- alias familysans-serif/family prefer familyNimbus Sans/family /prefer /alias results in the family list Arial,Nimbus Sans,sans-serif As you see, in this case the users preferred font (arial) takes precedence over the system default. That's the bulk of the configuration below the include of ~/.fonts.conf. The only other rules below ~/.fonts.conf are to map PostScript families to TrueType equivalents. Perhaps those should be moved above the include, I don't have a strong opinion. -keith ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Re: Question on xft font library.
Around 16 o'clock on Jan 17, Mike FABIAN wrote: There seems to be code to artificially embolden glyphs in freetype-2 now, in freetype-2.1.3/src/base/ftsynth.c there is a function FT_GlyphSlot_Embolden( FT_GlyphSlot slot ) Xft doesn't yet use this function; I'll see about giving it a whirl in a while. It shouldn't be hard -- add another pattern element requesting artificial emboldening that routes code through this function and then add pattern matching stuff to the font configuration which turns that on when a pattern requests bold but the matched face is not. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Wrong CJK bitmap font size selected by fontconfig/Xft 2.1?
Around 11 o'clock on Jan 2, Anthony Fok wrote: I couldn't figure out why disproportionally large 24px zh-CN font was selected in place of the closest 16px when lang=en. I have tried switching to all other languages, and it appears that only lang=en exhibits the problem. lang=en may force the 24px font because of coverage issues; it's possible the 16px font is missing some glyphs needed for English but not needed for German. You can check the language encoding supported by each font using fc-list, I don't have a 24 pixel font with support for zh-CN, but you should be able to see it with: $ fc-list :lang=zh-cn:pixelsize=24 family lang pixelsize Is this issue the domain of fontconfig or Xft? Or Pango? Or something else altogether? I apologize for my ignorance, as I am not yet sure of the exact division of work among the three libraries. :-) Font matching and selection is entirely within the province of fontconfig, although the generation of matching patterns is done by applications and libraries like Pango. You can watch the match process by enabling a couple of debugging levels within fontconfig: $ export FC_DEBUG=3 $ some random pango app This will generate quite a bit of output, but should provide sufficient information to see why one font is preferred to another, although you're likely to need to look a the fontconfig source to make much sense of the output. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Will 4.3.0 get rid of 8bit bitmap fonts?
Around 5 o'clock on Dec 19, Mike A. Harris wrote: The last discussion I recall on this was that ttf font file format would be used with embedded bitmaps. Is this still planned for 4.3.0? No, not for 4.3, that would have needed to be ready before the feature freeze date. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Dealing with standard bitmap fonts in Xft
Around 13 o'clock on Dec 17, Juliusz Chroboczek wrote: Not for me. For many applications I prefer bitmap fonts to scalable fonts, and I wouldn't be willing to switch to Xft throughout my desktop if Xft prevented me from using the fonts I'm used to. My desire is not to make this mandatory or even the default, but rather to make it possible to configure the system to prefer outlines unless no outline contains the needed glyphs. Hmm. I can do this without changing the library: !-- in ~/.fonts.conf -- match target=pattern edit name=prefer_outline booltrue/bool /edit /match !-- in /etc/fonts/fonts.conf -- match target=pattern test name=prefer_outline booltrue/bool /test test name=family stringHelvetica/string /test edit name=family mode=prepend binding=strong stringArial/string /edit /match match target=pattern test name=prefer_outline booltrue/bool /test test name=family stringTimes/string /test edit name=family mode=prepend binding=strong stringTimes New Roman/string /edit /match This has the added benefit of mapping the ugly bitmap fonts to (ugly, but outline) replacement fonts of similar style and metric. Does this look better? Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Dealing with standard bitmap fonts in Xft
Around 13 o'clock on Dec 17, James Su wrote: For CJK languages, bitmap fonts usually provide better render result than ttf fonts, especally for GUI display. Maybe font size should be accounted when choosing font, for example for screen display which font size is smaller than 16 pixels, bitmap fonts is better than ttf. The Han fonts that I use are all TTF with embedded bitmaps, so this particular configuration wouldn't have any effect. However, for people interested in using bitmap-only Han fonts, they'd want to configure things differently, perhaps based on the desired language. The goal here is to make sure the user has some way to configure whether to permit bitmap fonts to appear on the screen even when an application specifically requests a bitmap only family. As the mixture of bitmap and AA fonts is visually jarring, I know I want to avoid any bitmap fonts appear on the screen at all when an AA font is available that supports the desired language. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Dealing with standard bitmap fonts in Xft
Around 1 o'clock on Dec 17, Owen Taylor wrote: What I'd basically suggest is that fontconfig should not be pointed at complete set of bitmap fonts in /usr/X11R6/lib/fonts; even if they don't get chosen automatically, they will cause much confusion to users when they look at a font selection dialog. I'm not sure we should do that; with the default set of fonts included in XFree86, we have support for many more languages in bitmap fonts than in outline fonts. We may want to avoid listing bitmap-only fonts in font dialogs, but that should probably be a configurable option. Until there area freely distributable outline fonts with coverage equivalent to the core XFree86 bitmap fonts, I fear we will need to expose bitmap fonts to ensure reasonable display of as many languages as possible. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]syntax for disabling using embedded bitmaps for specific font size ranges
Around 17 o'clock on Dec 5, Ken Deeter (Kentarou Shinohara) wrote: I'm trying to figure out how to disable anti-aliasing and use embedded bitmaps for japanese fonts and for font sizes 8-14. Once you disable anti-aliasing, you'll automatically get the embedded bitmaps. I also find that mixing aa and non-aa glyphs from the same font at different sizes is somewhat distracting (but, ymmv). Here's how I disable anti-aliasing on chinese fonts: match target=font test name=lang target=pattern compare=contains stringzh/string /test test name=lang target=font compare=contains stringzh/string /test edit name=hinting mode=assign boolfalse/bool /edit edit name=antialias mode=assign boolfalse/bool /edit /match This says that any font or pattern specified for chinese has hinting and antialiasing disabled. To hit a specific family, you can use: !-- Disable anti-aliasing for simsun so that the embedded bitmaps can be used -- match target=font test name=family compare=eq stringsimsun/string /test edit name=antialias mode=assign boolfalse/bool /edit /match instead. You can add size tests inside the match element if you like to narrow the range to specific sizes. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]syntax for disabling using embedded bitmaps for specific font size ranges
Around 18 o'clock on Dec 5, Ken Deeter (Kentarou Shinohara) wrote: Thanks for the quick reply. I've gotten it to work for MS UI Gothic but I can't seem to make it match non-ascii font names. I still haven't figured out a good plan for multi-lingual font names. For non-user visible names, I think it's best to use a single canonical name selected in a consistent locale-independent way from the available names. For that, I use a priority scheme to select one of the encoded font names, the current mechanism prefers an english name to those encoded using only Latin glyphs (pages 0, 1, 2, 0x1e, 0x20, 0x21, 0x22, 0x23, 0xfb or 0xff) and both of those to names using other glyphs. Then it prefers names encoded in Unicode to those encoded in AppleRoman or Latin1. Finally, it prefers family names to postscript names, and either of those to other names it digs out of the font. Once we can identify a family by name, we need to provide some mechanism for displaying localized names in menus; that's a separate problem and will result in a new font pattern element for the localized names each tagged with an RFC-3066 style language identifier. All of this means that your font configuration file should always use the canonical name as described above. Once we have localized names available to applications, those can be displayed by a locale-sensitive font configuration tool when editing the configuration file. If the only name a font offers is in Japanese, then placing the UTF-8 encoded name in the configuration file should work. I worked pretty hard to avoid that by searching all over the font for an ascii name though; on my system, I see only MS Gothic and not ゴシック. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]syntax for disabling using embedded bitmaps for specific font size ranges
Around 22 o'clock on Dec 5, Ken Deeter (Kentarou Shinohara) wrote: So for example, [ken@cool ~]$ fc-list | grep Gothic Hershey\-Gothic\-English:style=Regular WadaLab Gothic:style=Regular URW Gothic L:style=Demi URW Gothic L:style=Book ＭＳ Ｐゴシック,MS PGothic:style=Regular URW Gothic L:style=Demi Oblique Hershey\-Gothic\-Italian:style=Regular URW Gothic L:style=Book Oblique ＭＳ ゴシック,MS Gothic:style=Regular 東風ゴシック,Kochi Gothic:style=Regular Hershey\-Gothic\-German:style=Regular MS UI Gothic:style=Regular I hop you're using an older version of fontconfig; the current CVS (and 2.1 fcpackage) versions should not advertise multiple family names for the same font. Reading the code, it doesn't seem possible, but... This is the verbatim contents of my .fonts.conf file: Your file is missing the enclosing elements which define a complete XML file. The parser is obviously a bit lax in enforcing the syntax. Please add: ?xml version=1.0? !DOCTYPE fontconfig SYSTEM fonts.dtd fontconfig at the top of the file and /fontconfig at the bottom. /me is hoping for real font configuration tools soon. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]zh-hk font support/priority in Xft
Around 2 o'clock on Dec 5, Anthony Fok wrote: The PUA mapping is a distinguishing feature of a HKSCS font. Hmm. I removed these hoping that the remaining standard codepoints would serve to correctly identify HKSCS fonts. I'm not entirely sanguine about using PUA codepoints in this way, but it appears we don't have a better option. $ fc-list :lang=zh-hk # It doesn't show all the fonts. Strange. That's a bug. Fontconfig uses the OS/2 code page range bits to detect Han style preferences. Fonts supporting only a single Han code page range bit (there are bits for Japanese, traditional Chinese, Korean and simplified Chinese) are not allowed to advertise support for other Han languages, even if they have sufficient support. This ensures that GB18030 fonts aren't marked as supporting zh-TW, zh-HK and ja. The DynaComware MingLiU_HKSCS is marked with the traditional Chinese bit which was mapped only to zh-TW, so it was not even checked for zh-HK support. I've composed a patch that maps traditional Chinese to zh-HK, zh-MO and zh-TW and maps simplified Chinese to zh-CN and zh-SG. By creating a new language hk, you bypassed this extra check. I'll submit this patch along with the orthography update. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]zh-hk font support/priority in Xft/Pango
Around 0 o'clock on Dec 3, Anthony Fok wrote: Under zh_HK locale, however, since no zh_HK fonts were found on the system, the zh_CN font appears to have a higher priority over the zh_TW one, resulting in a funny-looking mosaic of text rendered with about 1/3 zh_CN and 2/3 zh_TW. This is my first problem. We can solve this with a configuration change: match target=pattern test qual=any name=lang stringzh-hk/string /test edit name=lang mode=append stringzh-tw/string /edit /match This says that when asking for a font which supports 'zh-hk', accept as a reasonable substitute a font which supports 'zh-tw'. The second problem is that fontconfig 2.0 does not seem to recognize a zh_HK (HKSCS-2001) font as such. It's quite possible that the hk orthography is too selective; the HKSCS includes a lot of codepoints which may not be in the fonts you're interested in. You can check which codepoints are supported in that font using 'xfd'. If you can, send as many HKSCS fonts as you can along to me and I'll modify the orthography to fit them. The trick is to make sure that only fonts with reasonable HKSCS support are matched. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]fontconfig and generic family names
Around 18 o'clock on Nov 24, Owen Taylor wrote: The reason that we didn't try to make them follow the user's font configuration is that it was problematic to have the font a particular name referred to change while a program was running, while the fonts in the font preferences dialog should take affect immediately. Then you should have changed the file and broadcast a message to get the apps to re-read the configuration files. That's easy enough to do. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Xft2 without Xrender
Around 20 o'clock on Nov 15, Fred RISS wrote: When you say 'now', do you mean on current CVS ? I checked, and with my version (fcpackage.2_0) it complains every time I launch an app. Yes, current XFree86 CVS has the fix. I haven't repackaged fcpackage since 2.0 as there have been only a few minor changes like this one. Perhaps I'll get around to a 2.1 release in the next couple of weeks. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]ttf files
Around 10 o'clock on Nov 14, Gene C. wrote: Looking at the source code for fc-list, it appears that the file name should print but it never does. Current fc-list sources will print the file name when requested. The filename has to be printed separately as the regular font name printing code explicitly excludes it as that code is generally used to write out cache files which don't want the file name in that format. $ fc-list 'Nimbus Mono L' family style file /usr/share/fonts/type1/gsfonts/n022003l.pfb: Nimbus Mono L:style=Regular /usr/share/fonts/type1/gsfonts/n022023l.pfb: Nimbus Mono L:style=Regular Oblique /usr/X11R6/lib/X11/fonts/Type1/n022004l.pfb: Nimbus Mono L:style=Bold /usr/X11R6/lib/X11/fonts/Type1/n022023l.pfb: Nimbus Mono L:style=Regular Oblique /usr/X11R6/lib/X11/fonts/Type1/n022024l.pfb: Nimbus Mono L:style=Bold Oblique /usr/X11R6/lib/X11/fonts/Type1/n022003l.pfb: Nimbus Mono L:style=Regular /usr/share/fonts/type1/gsfonts/n022004l.pfb: Nimbus Mono L:style=Bold /usr/share/fonts/type1/gsfonts/n022024l.pfb: Nimbus Mono L:style=Bold Oblique Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]xft and pcf font
Around 22 o'clock on Nov 4, Olivier Chapuis wrote: But, I recently try this with a pcf font and Xft2 (fontconfig, freetype and Xft from XFree CVS) and this does not work. Text is displayed in the following way: X T e r m and so is not rotated (verticallayout=FcFalse). FreeType doesn't transform bitmap glyphs at all; not even for this trivial case. I don't think it would be hard to detect this and flip the bits around inside FreeType. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: making editable charset/lang in fonts.conf
Around 12 o'clock on Oct 22, Jungshik Shin wrote: 1. get a pattern from an application(fontconfig client) 2. apply configuration-specified editing rules to the pattern. For each font: 3. read in font properties from fc-cache or (directly from font if fc-cache is not present) 4. measure the distance between the pattern and each font Fontconfig reads the font properties at startup time, and thereafter only when they change (it checks file mod times when fonts are listed). What we could do is add a set of rules executed when the patterns are loaded, although I'm not sure that's precisely what you want, and it would significantly impact application startup performance. It seems like you want to select fonts based on Unicode coverage of the desired Hangul representation. You could easily add a way to represent Unicode coverage in the config file; that would make adding coverage information possible with existing apps. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]fontconfig peculiarity(??)
Around 12 o'clock on Oct 18, Jungshik Shin wrote: Keith, we talked about this a month ago (Sep. 7th) on this very list :-) Sorry, I didn't look at the email address from your previous message. One possible explanation is that Code2000 isn't marked as supporting 'ko' in font-cache for some reason while Ngulim is. If your font specification includes language, this would cause Ngulim to be preferred over Code2000 if both are added to the pattern in the config file. If the application explicitly names 'Code2000' as a family name, then the language shouldn't matter. Code2000 isn't marked as supporting Korean as it is missing a large number of Han glyphs, totalling some 3136 characters from the KSC 5601-1992 encoding. Many Korean documents will not be completely covered by this font. It also isn't marked as supporting Japanese or any of the Chinese languages. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]fontconfig peculiarity(??)
Around 16 o'clock on Oct 18, Jungshik Shin wrote: Hmm, things are getting more interesting. After I removed Ngulim.ttf from my font path and then put it back (I ran fc-cache before testing), suddenly Mozilla picks up U+1160 glyph from Code2000. The same is true of 'gedit' when Code2000 is specified as a font to use. Is it at the whim of electrons whirling around inside my computer :-) ? fc-cache ignores directories which are older than the associated cache file; you have to use the '-f' option to force it to rescan the files. The cache holds the list of available characters in each font, so a failure to update the cache could easily have been the source of this problem. Note that fc-cache doesn't rescan directories when the configuration changes; the only configuration option which affects the resulting cache file is the blank glyph list, which isn't expected to (ever) change aside from bug fixes. The page in question (http://jshin.net/i18n/korean/hunmin.html and http://jshin.net/i18n/korean/hunmin_comp.html) specifies font-family to be CODE2000 explicitly with CSS. I assume this will make Mozilla with Xft enabled ask fontconfig for that font explicitly. Yes it does. As for Pango(gedit), I'm less certain because I don't know whether Pango specifies language when sending fonts request down(or up) the road. I don't know either, but fontconfig will pick up the current locale and convert that to a language if Pango doesn't explicitly set one. As I suggested before, a kind of multi-level orthography check may be necessary to cope with situations like this. Or, would it be possible for users to override manually what fontconfig *detects* (both code range coverage and lang) in fonts.conf as suggested in my prev. email? I believe Korean may be unique in this reguard; I don't know of other languages with multiple common character sets which are essentially independently usable. Japanese has kana and kanji, but there are strong conventions on which words are spelled in each set. As per my comment above, I strongly prefer to make the contents of the cache files independent of the configuration so that multiple configurations can share the same cache files without difficulty. Remember that the language name is just a shorthand notation for a unicode coverage table; if you want to identify fonts with Hangul syllables, you can easily build a charset encompassing those and ask for the font covering the greatest number. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]libXft 1.2 prevents xftcache from scanning Speedo fonts
Around 11 o'clock on Oct 7, Jeffrey Baker wrote: and I finally tracked it back to the latest version of libXft.so.1.2. When this library was installed (from fontconfig.org sources), xftcache would fail with the message: Running xftcache in Speedo font directory...Can't scan directory /usr/X11R6/lib/X11/fonts/Speedo xftcache is obsolete; use fc-cache instead. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Thyromanes fonts not working with xft2
Around 1 o'clock on Sep 30, David Starner wrote: (Package ttf-thryomanes.) Unfortunately, they don't seem to display correctly in XFT2 programs don't seem to display correctly isn't very descriptive; can you provide a sample problem? Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]fontconfig core dump
Around 14 o'clock on Sep 25, David F. Newman wrote:
I was building fontconfig for Solaris because KDE now looks for it.
However, I ran it again and it core dumped with a bus error.
Can you try this patch please?
Index: fcpat.c
===
RCS file: /home/x-cvs/xc/lib/fontconfig/src/fcpat.c,v
retrieving revision 1.16
diff -u -r1.16 fcpat.c
--- fcpat.c 31 Aug 2002 22:17:32 - 1.16
+++ fcpat.c 25 Sep 2002 19:00:46 -
-1,5 +1,5
/*
- * $XFree86: xc/lib/fontconfig/src/fcpat.c,v 1.15 2002/08/22 07:36:45 keithp Exp $
+ * $XFree86: xc/lib/fontconfig/src/fcpat.c,v 1.16 2002/08/31 22:17:32 keithp Exp $
*
* Copyright © 2000 Keith Packard, member of The XFree86 Project, Inc.
*
-280,6 +280,11
FcValueList*list;
};
+typedef union _FcValueListAlign {
+FcValueListEnt ent;
+FcValueListlist;
+} FcValueListAlign;
+
static int FcValueListFrozenCount[FcTypeLangSet + 1];
static int FcValueListFrozenBytes[FcTypeLangSet + 1];
static char*FcValueListFrozenName[] = {
-312,6 +317,7
static FcValueListEnt *
FcValueListEntCreate (FcValueList *h)
{
+FcValueListAlign *ea;
FcValueListEnt *e;
FcValueList*l, *new;
intn;
-326,14 +332,15
string_size += strlen ((char *) l-value.u.s) + 1;
n++;
}
-size = sizeof (FcValueListEnt) + n * sizeof (FcValueList) + string_size;
+size = sizeof (FcValueListAlign) + n * sizeof (FcValueList) + string_size;
FcValueListFrozenCount[h-value.type]++;
FcValueListFrozenBytes[h-value.type] += size;
-e = malloc (size);
-if (!e)
+ea = malloc (size);
+if (!ea)
return 0;
FcMemAlloc (FC_MEM_VALLIST, size);
-e-list = (FcValueList *) (e + 1);
+e = ea-ent;
+e-list = (FcValueList *) (ea + 1);
strs = (FcChar8 *) (e-list + n);
new = e-list;
for (l = h; l; l = l-next)
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
[Fonts]Storing the cached font (fonts.cache) information
Fontconfig currently stores cached information about fonts in per-directory files called 'fonts.cache-version'. These are stored right in the font directories which means they'll get copied and managed automatically as people move fonts around. 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. I'm open to suggestions, but here's one simplistic possibility: Create a shadow heirarchy in /var/cache/fonts which mirrors the various font directory heirarchies and populate that at appropriate points with fonts.cache files. I'd do this by creating a new table of cache prefix mappings: /usr/share/fonts - /var/cache/fonts/share This mapping would direct any fonts.cache files related to directories under /usr/share/fonts to be stored in /var/cache/fonts/share by simply replacing the /usr/share/fonts prefix with /var/cache/fonts/share: /usr/share/fonts/truetype/arphic/fonts-cache-1 - /var/cache/fonts/share/truetype/arphic/fonts-cache-1 Any directories not matching a configured prefix would map to themselves; this makes the existing configuration and cache files compatible. 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? Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Storing the cached font (fonts.cache) information
Around 9 o'clock on Sep 7, Zenith Lau wrote: 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 ? The prefix mapping would be configurable; add a map from /usr/X11R6/lib/X11/fonts to /var/cache/fontconfig/x11-fonts and you'll get your cache files for fonts in the standard X directories stored in /var/cache/fontconfig/x11-fonts. 2. Add one additional mapping table under the FontCachePrefix/ I can either store the mapping table in a file or directly in the file system; I don't have a strong preference, but using the file system is likely to involve fewer but more complicated system calls during application startup. It might also involve a slight bit of overhead. The advantage is that there aren't any synchronization issues; each cache file is accessable without reference to a separate file. It seems like that should be more robust in many ways. But, /var/cache/fonts is already specified in the FHS, that, this directory is for dynamically generated fonts, I quote it here : Sigh. We'll use /var/cache/fontconfig then. I don't really care. Though, I think /var/cache/fonts should be the better, as I like the style what fontconfig do. To some extent, we can ask if a slight reinterpretation of the FSH can be permitted in this case. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Compilation fail in fcpackage-2.0-Xrender
Around 12 o'clock on Sep 7, Zenith Lau wrote: Cursor.c: In function `XRenderCreateCursor': Cursor.c:39: `X_RenderCreateCursor' undeclared (first use in this Hmm. This is a new request, but it should be defined in the 'render.h' file included with fcpackage. You may have to replace the render.h found in /usr/X11R6/include/X11/extensions to get things to build. If so, let me know and I'll see how I can fix the package. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Storing the cached font (fonts.cache) information
Around 13 o'clock on Sep 7, Zenith Lau wrote: Sorry, do you mean that, store the mapping table in the file system, you are talking about the first idea? I can either use a sequence of directories to encode the source font path, or I can create a file which maps path names to file names. In the first method, with the mapping: /usr/share/fonts - /var/cache/fontconfig/share the cache file: /usr/share/fonts/truetype/kochi/fonts.cache-1 would live in: /var/cache/fontconfig/share/truetype/kochi/fonts.cache-1 This is done by simply replacing the prefix of the path matching the left hand of the mapping with the right hand of the mapping. The library would automatically take care of creating any necessary directories to create the matching directory heirarchy. In the second method, with the mapping: /usr/share/fonts - /var/cache/fontconfig/share I'd create a cache mapping file (cache.map?), that file would live in /var/cache/fontconfig/share/cache.map It would contain an entry like: truetype/kochi/fonts.cache-1 1.cache-1 and the cache file /usr/share/fonts/truetype/kochi/fonts.cache-1 would like in: /var/cache/fontconfig/share/1.cache-1 I would keep the cache.map file synchronized with the cache file contents somehow; programs would be required to open the mapping file to locate cache files for each directory. For the configurable prefix mapping, how do it exists? Also it is permissable that, there are many dir in the fonts.conf. Is it possible to store the mapping as properties of the dir elements? That's a good idea -- I hadn't thought of that. I'd thought, instead, of creating new configuration data which mapped names. I like the directory property better. Thanks. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: Segfault at startup with openoffice fonts and fontconfig2
Around 17 o'clock on Sep 5, Jeffrey Baker wrote: This is the offending stack: #0 0x409b7b92 in ps3_hints_apply () from /usr/lib/libfreetype.so.6 #1 0x40994a64 in FT_Get_Next_Char () from /usr/lib/libfreetype.so.6 Looks like you're hitting bugs in FreeType. Version 2.1.2 is known to have some issues of this nature; I'm continuing to use the XFree86 copy of 2.1.1 for now and have moved the debian versions out of the way. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]edit antialias=false equivalent in fonts.conf
Around 17 o'clock on Aug 27, Ken Deeter wrote: Is it possible to replicate the behavior of: match any size 14 any size 8 edit antialias=false; Yes. See the example fonts.conf file and the manual page for the new XML-based syntax. Also, if I do do this, then will Xft now use the embedded bitmaps for the non-antialiased sizes or will it try to use the outlines like before? Xft1 still has the old (broken) behaviour. The current version of Xft uses bitmaps when antialiasing is disabled. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Is hinting worth the effort?
Around 17 o'clock on Aug 21, Markus Kuhn wrote: Is hinting really worth the effort? If you separate hinting into the two pieces supported by TrueType (instructions and deltas), then I would agree that the instruction portion is irrelevant. Good TrueType output is almost always generated by delta hints which are size-specific. - For DTP applications, it is important that the on-screen representation approximates as closely as possible the printed result in a device-independent way, and hinting severely interferes with that goal as it changes glyph spacings and sizes. When reading or editing a document on screen, the glyphs should be hinted to make the letters sharp and easy to read. How applications adjust to the differences between screen and printer metrics is a separate issue. The Windows problem is exacerbated by the lack of printer metrics through the GDI interface. Using FreeType, applications would have access to the underlying glyph sizes and be able to adjust the display to make it more closely approximate what would appear should the document be presented at higher resolution. a) edit the resulting bi-level bitmap (switch some pixels on or off to improve the looks) Obviously uninteresting as it eliminates anti-aliasing and sub-pixel rendering. b) manually snap control points to a nearby pixel boundary Unless you're careful, this is covered by the TrueType delta-hint patent which covers any relative motion of control points(!) for the purpose of adjusting glyph shapes on the display. TrueType uses the combination of size-independent instructions and delta-hints to reduce the total size of the font; delta hints are only needed for important glyphs where the instructions don't get the right results. - I understand that the area of scale-independent hinting instructions in font file formats has some patent problems. (?) One of the techniques used in the instructed hinting is patented. This involves the separation of the basis of measurement from the basis for adjustment. One obvious application of this is in hinting diagonal stems -- the hint measures the width of the diagonal element while adjusting the control points along a horizontal line to keep the corners of the glyph at the same elevation. - In spite of the sophisticated hinting mechanisms available in TrueType fonts, it seems that places like Microsoft Typography do not make very significant use of it and embeds handedited bitmaps instead. Very few western TrueType fonts include bitmaps; they rely instead on delta hints. Embedded bitmaps are relegated to Han fonts and are provided at only a very few sizes. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]fonts.conf problem combining gylphs from different fonts
Around 17 o'clock on Aug 14, Zenith Lau wrote: This is a problem, as most probably, I can't get two fonts with exactly same face but for two charset. Though, I know that, I can reorder the yenti and fangsong in the fonts.conf to archieve my desire result, but this will be same problem, if I am in hkscs locale. Fontconfig has been recently changed to try and solve this problem. It looks at LANG, LC_ALL and LC_CTYPE to try and figure out the right language to look for in the fonts. If you set one of the environment variables to zh-cn, fontconfig will prefer the GB18030 font, using zh-hk will prefer a HKSCS font. Fontconfig bases the language support of fonts on two things; languages are supported by a font if their orthography is completely covered by the font. In the case of Han fonts, I used the following orthographies: zh-cn: GB2312 zh-hk: HKSCS-2001 zh-tw: Big5 ja: JIS X 0208 (1990) ko: KSC 5601-1992 The second piece of information that I use for Han fonts is the OS/2 codePageRange bits. These are used to elide Han languages which are explicitly *not* supported but whose orthographies happen to be covered by the font. This is quite common with GB18030 fonts which covers GB2312, Big5 and JIS X 0208. A GB18030 font which includes only bit 18 in the codePageRange bits will only be listed as supporting zh-cn and not zh-tw, even though it nominally covers Big5. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Korean orthography for fontconfig
Around 17 o'clock on Aug 14, Jungshik Shin wrote: On Wed, 14 Aug 2002, Owen Taylor wrote: I think the right thing to do is probably just to use only the KSC-5607.1987 syllables in the Korean orthography; Despite what I wrote in my previous message, I agree that this is the right thing to do. This may not be an issue any more once most fonts are populated with the full set of 11,172 syllables (just like Baekmuk). Ok, I can do that. When you've both fonts with the older and newer sets, you'll get ransom notes for documents that use codepoints not present in the older font, but the right fix is to go and get reasonable fonts; the alternate fix is to place the complete font first in the list. I'll go dig up a unicode table for KSC-5607.1987 and replace the existing ko map with that. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]enquiry about pcf/bdf font support
Around 17 o'clock on Aug 13, Zenith Lau wrote: I suppose it should be work, but, I can't see my bitmap fonts in fc-list output. FreeType doesn't (yet) support compressed PCF fonts. I've since had a revelation that we should discard PCF font files and replace them with TTF files containing an embedded bitmap. This would eliminate miles of senseless code in X while providing the automatic transcoding features we have for TrueType fonts. Font files would be dramatically smaller as they would use a TrueType encoding instead of the single array present in PCF files. If anyone has experience writing TrueType font files, help would be greatly appreciated in building something that can create these new files. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Unicode coverage for Syriac
Around 12 o'clock on Aug 6, Emil Soleyman-Zomalan wrote: The following unicode codepoints are the minimum needed to display the Syriac alphabet (without punctuation and diacritics): 0710-072C My current orthography includes the points (0730-073f). Are these ever used in typesetting text? Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]enquiry about pcf/bdf font support
Around 14 o'clock on Aug 13, James H. Cloos Jr. wrote: I'd like to see this designed to combine all of the dpi-pt_size variations of a given face into a single ttf. (It may even be a good idea to also collect the WIEGHT, SLANT, SETWIDTH and ADD_STYLE variations into a ttc; this should be discussed.) That's a nice addition as well. I don't really care if we combine multiple faces into a single .ttc file; it's not all that common yet, but it would reduce the number of files we distribute. The resultant ttfs should also, IMO, include sufficient hints so that mkfontdir can generate fonts.dir entries from them exactly as it now can from the bdf files. In fact, all of the properties from the bdf files' STARTPROPERTIES section should be encoded into the ttf. I plan on eliminating the fonts.dir files at some point and having the X server use fontconfig. Placing sufficient information in the fonts and thence into fontconfig would eliminate the need for almost all of the current font architecture. Exactly how the properties should be encoded is another topic in need of discussion. A new table could be added (perhaps named something like XF86, XFLD, XBDF or BDFP) to encode all of the props with pointers to which bitmap they refer. That was my plan as well; I believe all of the properties can be tagged to the pixel size they refer to. P.S. As a related sidenote, has anyone tried writing an xfs on top of fontconfig/xft2/ft2? Once we port the current Xserver/fontserver 'font' library to fontconfig, we'll have done this for both applications. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]enquiry about pcf/bdf font support
Around 22 o'clock on Aug 13, Juliusz Chroboczek wrote: Keith, the subtleness of your hints is not improving ;-) My family complains that my attention is best captured with a piece of dimensional lumber. I actually have started working on such a beast (a couple of months ago) That's great news. There's no particular hurry for this, but it would be nice to get things tested in Xft and fontconfig before XFree86 4.3 goes out the door. Switching the main fonts in the release can wait until a later day. We eagerly await future developments in this area :-) Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]enquiry about pcf/bdf font support
Around 22 o'clock on Aug 13, Juliusz Chroboczek wrote: KP That's a nice addition as well. I don't really care if we combine KP multiple faces into a single .ttc file; I think he meant combining multiple sizes into a single TTF. Recall that TTF/OTF is a scalable format, and may contain sbits for multiple sizes (``strokes'' in OTF parlance). He suggested both -- combining multiple sizes in a single font and combining multiple styles into a single .ttc file. I've seen a few fonts distributed in this fashion; in particular, the GB2312 version of SimSun has two fonts in one file, a proportional and monospaced version of the same face. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]enquiry about pcf/bdf font support
Around 19 o'clock on Aug 13, James H. Cloos Jr. wrote: The 18pt and 24pt 75dpi bdfs could not be imported w/o overwriting 100dpi versions because they had the same PIXEL_SIZE. I think this is a limitation of pfaedit rather than the ttf/otf format. That's actually probably a good idea. The original outlines for most of the fonts were rasterized at both 75 and 100 dpi which results in quite a few duplicate pixel sizes. Merging those into one file will let us ship only the unique sizes and let Juliusz's magic FreeType2 library convert from point/dpi to pixel sizes. The font listing code can advertise whatever DPI it likes. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ 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
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
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
[Fonts]fcpackage RC2
I've built and tagged RC2 for fontconfig. The bits are available at: http://keithp.com/fonts/pub/fcpackage.rc2.tar.gz Keith PackardXFree86 Core TeamHP Cambridge Research Lab Major changes: fontconfig: The weird first/not-first hack for checking the font vs the pattern is gone. 'test' elements can now include a 'target' which can specify 'pattern' in the 'font'. An example of this is in the default configuration for artificial slanting of fonts which don't provide an italic or oblique varient. BSD install requires target filename fontconfig should be clean when run under valgrind. Edit elements can now specify 'strong' binding to permit family names which override a language specification in the pattern. FcPatternEqual short circuits tests when given matching pointers fontconfig.man updated to match current API. It should be complete and accurate. fonts.conf and fonts.dtd are always installed now; local changes belong in /etc/fonts/local.conf which fonts.conf loads. Should fonts.conf load fonts from /usr/local/share/fonts? New orthographies for many languages built. Still missing 17 of the 139 languages named in ISO 639-1: AS Assamese Assam (India) Indo-European F., Indo-Iranian Br. 23 JW Javanese Java, Malaysia, Surinam Austric F., Malayo-Polynesian Br. 64 JW from Bahasa Jawa LN Lingala, liNgala Zaire, Congo Niger-Kordofanian F., Non-Mande Br. 7 MS Malay Malaysia, Indonesia Austric F., Malayo-Polynesian Br. 155 MS from Bahasa Malaysia NA Nauru, Nauruan Nauru Austric F., Malayo-Polynesian Br. PA Punjabi Punjab (India), Pakistan Indo-European F., Indo-Iranian Br. 93 PA from Panjabi PS Pashto, Pushto, Pushtu Afghanistan, Pakistan Indo-European F., Indo-Iranian Br. 21 QU Quechua Peru, Ecuador, Bolivia Andean-Equatorial F., Andean Br. 8 RN Kirundi, kiRundi Niger-Kordofanian F., Non-Mande Br. RW Kinyarwanda, kinyaRuanda Rwanda, Burundi, Uganda, Zaire, Tanzani a Niger-Kordofanian F., Non-Mande Br. RW from Rwanda SD Sindhi Pakistan, Sind (India) Indo-European F., Indo-Iranian Br. 18 SG Sangho, Sango-Ngbandi Central African Republic, Zaire Niger- Kordofanian F., Non-Mande Br. 4 SN Shona, chiShona Rhodesia, Mozambique Niger-Kordofanian F., Non- Mande Br. 8 SS Siswati, siSwati South Africa, Rhodesia, Swaziland Niger- Kordofanian F., Non-Mande Br. ST Sesotho, siSuthu South Africa, Lesotho, Botswana Niger- Kordofanian F., Non-Mande Br. SU Sundanese West Java Austric F., Malayo-Polynesian Br. 26 ZA Zhuang, Chwang, Chuang China 15 See Note 5. Any help here would be greatly appreciated; we're very close to a complete set. The most pressing here are probably Malay, Punjabi, Pashto and Zhuang. Xft Owen found that _XftCloseDisplay was corrupting the global list Compute the charset at open time for patterns which don't provide one. This may be slow for large fonts, but the alternative is that Unicode mapping is completely disabled. Xft1, Xrender No changes since RC1 ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Fcpackage release candidate 1
Around 8 o'clock on Aug 1, Bradley T Hughes wrote: First, the /usr/bin/install included with FreeBSD doesn't like the install rules for fontconfig. Second, the default fonts.conf files is installed into the chosen prefix, but /etc/fonts/fonts.conf is hard coded into the sources, Thanks for finding these. They're fixed in CVS. I'm also currently working on getting Xft2 support into QT for our 3.1.0 release this fall, and I was under the impression that the qt3.diff that's been floating around was working. It was nearly working except for some minor clipping update problems that affect konsole. I haven't taken time to get KDE3 running here and so haven't been able to reproduce or fix this issue. I have found lots of problems with it, one of them being that with Xft1, RENDER support is completely disabled. The patch doesn't build against Xft1 either, due to missing XftDrawPicture and XftDrawCreateAlpha functions in Xft1 I intended to remove any presumption that the patch could compile against Xft1; with the release of Xft2 and fontconfig, there's no urgent need to support the older library and attempting to make the code cross compatible between two versions of Xft is probably only asking for trouble. I've also not updated Qt3 in a few weeks making the patch somewhat stale at this point. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Fcpackage release candidate 1
Around 18 o'clock on Aug 1, Bradley T Hughes wrote: I have kept the code in qpainter_x11.cpp as is, using XRender* calls directly. Clipping and such things are working now, so why break them, right? :) Please don't use XRender calls directly -- that means Xft2 won't be usable on servers which don't support Render. I can export an XftDrawSetClipRectangles call if you like; the alternative is to simply construct an X region from your list of X rectangles and use the existing XftDrawSetClip call. The huge advantage of Xft2 is this ability to work with legacy servers; applications gain the benefit of client-side fonts without this unnecessary dependency. Please don't eliminate this by careless mixing of abstractions. Unfortunately for us, this is not an option. Some people simply do not upgrade their XFree86 installation if they can avoid it. I have managed to make both Xft1 and Xft2 work though, with a bit of fudgery :) Xft2 and fontconfig are being released separately; if necessary, you can distribute those libraries with Qt. Alternatively, you can make Qt build only in the presense of Xft2 and ignore systems with Xft. System vendors should not have a problem with that. Xft2/fontconfig are on a separate release schedule from XFree86 making it possible to update them independently. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Fcpackage release candidate 1
Under pressure from actual users, I'm trying to get the combination of fontconfig and both versions of Xft ready for a release. I've backed out some tentative changes aimed at providing localized font names for applications; that will have to wait for a future release. I'm confident we can add this without breaking any existing interfaces, although it will require applications make a special call to locate the local names; I suspect far too many assume ASCII font names and aren't ready for UTF-8 yet. However, I did manage to completely rewrite the ~/.fonts.cache logic to eliminate per-file syscalls when the cache file is up-to-date. Really, it's much better now, and the API didn't change at all. Release candidate 1 has been tagged in the XFree86 CVS repository and packaged for your pleasure, please find it at: http://keithp.com/fonts/pub/fcpackage.rc1.tar.gz I intend to stabilize and ship this version in short order; I'm interested in hearing about problems and concerns, but functional enhancements will await a new version. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]fontconfig, Xft2, pango-head, gtk2 - play together?
Around 12 o'clock on Jul 25, Owen Taylor wrote: If you are using Qt with Xft, there are a couple of fixes on top of qt3.diff you'll need; the attached are what we have in Rawhide in a quick check. Thanks for the update; I'll cut a new patch after I test this fix. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Around 8 o'clock on Jul 22, Brian Stell wrote: Yes, this is important. I can well imagine an app that that saves a user's preference. If the user changes locale then the saved preferences should still find the user's previously set prefered fonts. I expect this to mean that the app will save the preferences in ascii and then get the localized list for display. Hmm. I think I see the way through here. See below. Will there be a way to get the localized name using the ascii only name? Yes. The representation of the names internally includes all of the localized names along with the postscript name (which is always ASCII), any match or list result will include all of these names. I would sort the names so that any English or Latin names would come first in the list. Ok, so applications want a notion of 'canonical' family names which can be mapped to localized names for display to the user at runtime. I plan on storing all of these names together in the same FC_FAMILY entry for each known font, tagged (somehow) with the associated language. The entries would be sorted with English names first, followed by names containing only Latin characters and then the remaining names following sorted by language tag. A naïve application using the existing FcPatternGetString API will get an English name for each font. A separate API (FcPatternGetLangString?) would walk the list of names and select the one best matching the specified language (or current locale). An application wishing to store font preferences in a locale-insensitive fashion can either: a) Store just the English name. Converting to a local name would require a call to FcFontList and then a call to FcPatternGetLangString. b) Store all of the names along with their languages. This can be done with FcNameUnparse/FcNameParse which generate UTF-8 encoded strings for the font name. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Around 9 o'clock on Jul 22, Brian Stell wrote: Wouldn't it make more sense for a naive app to get the localized name? Thus apps users of simple apps would get names they could read; eg: Japanese users by default get Japanese names, Greek users would get Greek names, and so forth. Yes, I agree that would be nicer, except that truely naïve applications are likely to incorrectly display UTF-8 strings. The FcPatternGetLangString API would return the appropriate UTF-8 string so that slightly-less naïve applications could trivially extract the localized name. To make the code regular for all languages I would really prefer to store the ascii only name and then always get the localized names for display. In the suggested API I presented, that's quite possible. The only cost is in converting the ascii name into a local name which requires searching through the set of available fonts to match the ascii name. This would have the (questionable) property where the application would find out that configured fonts were missing. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Around 13 o'clock on Jul 18, Pablo Saratxaga wrote: In other terms, the localized names are used to display in the lists shown to the user, when when one of those is choosen, what is returned is not the localized name but the ascii-only one. And inversly, when an ascii-only name is gotten, it should be possible to retrieve its associated localized name if needed. Why do you believe the internal interface should only use ASCII names? The underlying infrastructure supports fonts with multiple names, it seems obvious to me that it will be easier to get application support if they need deal with only one name, and that name should be the localized name. Note that *all* of these names are locale independent; applications can use any of the names to access the font, the only question is what name should be returned when the application requests it, the mapping from the set of names to a name appropriate for the user is the only locale -dependent step. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Around 2 o'clock on Jul 14, Pablo Saratxaga wrote: Yes, both localized names and ascii-only names are usefull. Maybe the same api could be used for both cases, trough a paremeter telling which localized language is requested (if C, then ascii-only names are given). Ok, I'm adding localized names to fontconfig. To allow applications to continue working with a single name, I'm actually listing the localized names in the FC_FAMILY value using a new datatype (FcTypeLangString). Ask for a string, and you'll get back just the family name, but ask for a LangString and you'll get both. A couple of questions: 1) Macintosh names are encoded in weird Macintosh text encodings, is it OK to ignore the non-Apple Roman names here? I can't see embedding conversion tables for all of the weird encodings. 2) Should I use the current locale to select a family from those listed when an application requests a string for FC_FAMILY? That would mean returning different values depending on the locale. All of the return values would map to the same font. The reason for this is so that simple apps continue to work in a simple fashion. The alternative is to force apps to use a new API which includes an explicit lang; when that is NULL, I could use the current locale. You'll get localized names for family and style; there aren't any other obviously useful string values in the current set of font name elements. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: Unicode coverage for languages
Around 9 o'clock on Jul 12, Brian Stell wrote: I think Yao makes an interesting point: it might be good to have some additional information besides what is in the fonts themselves. Yes, it might. The existing file formats are designed to be extensible enough so that when we find a case where it would be useful, we can add the information without affecting forward or backward compatibility. The basic idea would be to take incoming patterns for available fonts and run them through the pattern editing mechanism using a new target. My hope is that it won't every be necessary; I'd rather automatically extract all of the necessary information as this will be less prone to user error. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Around 16 o'clock on Jul 12, Yao Zhang wrote: These may not be fontconfig's problem but since FreeType 2 has APIs to access any naming table in the font, it is not FreeType 2's problem either. The way I solve this problem is to change FreeType 2's convertion: Instead convert non-ASCII Unicode name to '?', convert it to UTF-8. At least it works for me. I'd like to use UTF-8 if possible; is there a way to get the UTF-8 value from FreeType without changing that library? I'm sure they have a good reason for hiding the non-ASCII characters. 2. I cann't find a way to list aliases. FcFontList() lists physical font only. That is by design. The essential problem is that many family names are registered trademarks, presenting these to the user when they are used only as alias names would be a trademark violation -- essentially we'd be advertising the presense of a trademarked font name which would then go and match some other font. We were allowed to make fontconfig aliases between the Lucidux and Luxi families because of this. If you can think of a way to reconcile these two requirements, please suggest it. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Around 17 o'clock on Jul 12, Owen Taylor wrote: This is what face-family_name is meant to be and face-family_name is defined to be ASCII traditionally so it can't really be changed. (Plus, things are just going to work better generally if this is Roman/ASCII) I can accept that face-family_name is supposed to be ASCII, but fontconfig is entirely tolerant of UTF-8 and I'd really rather use those names; I can't see how things are just going to work better in this case; we're ending up presenting '?' instead of valid characters, that doesn't seem useful. B) The localized name for a particular locale that should be shown to the user; FT_Get_Sfnt_Name() can be used to get this from a font, but it isn't exposed in fontconfig currently. In the mail above, I said: FT_Get_Sfnt_Name works only with TrueType and OpenType fonts. Do all other formats support only ASCII names? Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Devel] Re: [Fonts]RE: Font family name problem
Around 20 o'clock on Jul 12, Owen Taylor wrote: Where the Macintosh/Roman/English entry was not English; I don't know if that was the reason for the current code or whether its unintentional. The reason may well be that all of the Microsoft names are in Unicode while the Macintosh names are in Apple Roman. It's a lot easier to translate UTF-16 into Latin-1 than Apple Roman... Still, it seems to me that if we don't have a Microsoft/English entry, we might as well take the Macintosh/Roman/English entry - it doesn't seem likely to be *worse* than using a known non-English Microsoft/Unicode entry. I've started putting code together that ignores the FreeType family/style values and walks the name table if available. I have an apple roman transcoding table available and I'm not afraid to use it. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Around 18 o'clock on Jul 12, Keith Packard wrote: I'll add transcoding for apple-roman names. My intent is to prefer english names, and failing that, to choose the first entry in a known encoding. Well, *that* was entertaining. It almost works. Except for MS Mincho. For both FONT_FAMILY and FONT_PS_NAME, it advertises a Macintosh platform name, Apple Roman encoding and language id 0x411, which is Microsoft's language tag for Japanese(!). At least Microsoft didn't re-use Apples language tags... In the FONT_FAMILY string, I find a combined full-width latin and Han string while in the FONT_PS_NAME string, I find an ASCII string. I think I'll add a check on the non-English names to see if they're at least Latin and prefer those over the non-Latin names. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Around 17 o'clock on Jul 12, Owen Taylor wrote: B) The localized name for a particular locale that should be shown to the user; FT_Get_Sfnt_Name() can be used to get this from a font, but it isn't exposed in fontconfig currently. In the mail above, I said: fontconfig only needs to expose an API if you need to extract the information before opening the font, in which case fontconfig would actually need to store this information in the font information files (*/fonts.cache). Carrying this architecture to it's logical conclusion, we could tag FC_FAMILY and FC_STYLE components with their language; matching could be done using the language provided in the pattern (or extracted from the locale). Match/edit patterns in the config file could be tagged with a language to restrict them to a single language, or left untagged in which case they'd apply to any language. Matching value and language would be better than matching just value for purposes of font selection. I would like to point out that the font file tables are rather restricted in their choice of language. The Microsoft format tables support only 67 languages. Apple (oddly) does a bit better with a list of 150 languages. This leaves us wondering how to display localized names for users of other languages. I guess we'll assume they speak the modern lingua franca. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: Unicode coverage for languages
Around 10 o'clock on Jul 11, Yao Zhang wrote:
In fonts.conf, we can already do something like
if zh_CN then
serif: {.., SimSun18030.ttc, ..}
if zh_HW/zh_TW then
serif: {.., MING_UNI.TTF, ..}
This particular case would use the general match/edit elements:
match target=pattern
test qual=any name=lang
stringzh-cn/string
/test
test qual=any name=family
stringsans-serif/string
/test
edit name=family mode=prepend
stringSimSun/string
stringMing/string
/edit
/match
match target=pattern
test qual=any name=lang
stringzh-tw/string
/test
test qual=any name=family
stringsans-serif/string
/test
edit name=family mode=prepend
stringMing/string
stringSimSun/string
/edit
/match
Another way to do it is to make a font list with the right information in
it. For example, if we can not always get the language-country property
reliablely, we can have a way to supply it manually.
That leads in a problematic direction -- currently, the font database is
computed solely from the fonts themselves, adding configuration into this
mix would either require changes to the font database caching mechanism or
would require editing each font database entry at startup by running it
through some configuration.
Note that the format shown above nicely parallels the per-language font
configuration mechanism already used by Mozilla.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Re: [I18n]Unicode coverage for languages
Around 13 o'clock on Jul 10, Anthony Fok wrote: I have been wondering: would OpenType technology be able to help solve this issue, since OpenType allows multiple glyphs (for different target language) for each character? Not any better than the OS/2 codePageRange bits that we already have; all this would do is permit the application to use one font instead of several different fonts. That's not particularily interesting as we're unlikely to ever see good fonts that include glyphs for all of the worlds languages. And, if the language you mention doesn't include some locality, then it couldn't even distinguish between Ming and Sung forms. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font matching with generic family names and language groups
Around 20 o'clock on Jul 10, Roozbeh Pournader wrote: BTW, how much is this ASCII support important? We're working on a set of Persian fonts, and we are not including Latin letters for example. Should we avoid this? Unicode seems to encourage any subset to include the basic ASCII glyphs, but applications using this font shouldn't care; they already need to load multiple fonts if they want to display Georgian and Chinese at the same time, that support obviously can handle adding another font for ASCII. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: [I18n]Using current locale in font selection
Around 4 o'clock on Jul 10, Owen Taylor wrote: As far as the question at hand; I think that giving up and using a default value or no value is fine if setlocale() hasn't been called. But I don't see any problems with checking LC_ALL/LC_CTYPE/LANG... it might be a nice touch. Given that POSIX specifies the order in which these are used, and given that all of my test programs don't call setlocale, I've added the trivial code to fetch from the environment. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: [I18n]Using current locale in font selection
Around 13 o'clock on Jul 9, Erik van der Poel wrote: Not that you need any more input to make this decision, but there is some precedent to go with LC_CTYPE too: the X Consortium went with that for both text output and keyboard input in their i18n work circa X11R5. Ok, so now what do I do with applications which haven't called setlocale (LC_ALL, )? Do I: a) call setlocal (LC_ALL, ) myself? b) use $LANG or $LC_CTYPE? c) Ignore the locale information and leave the font language preference unset? Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Re: [I18n]Using current locale in font selection
Around 14 o'clock on Jul 8, Owen Taylor wrote: +locale = (FcChar8 *)setlocale (LC_CTYPE, NULL); Don't you mean LC_MESSAGES? If so, I think we should be able to use this return value almost raw; stripping out the language and territory codes and passing them in as FC_LANG, right? (no case conversion is necessary, FC_LANG comparisons are already case insensitive). Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Adding language information for TrueType fonts
Many TrueType fonts include an OS/2 table which holds codePageRange bits. These bits indicate the old OS/2 code pages supported by the font, and hence indirectly indicate which languages the font is intended to support. These tables, however, are quite primitive, indicating support for only a very few languages as they hold only 64 bits total. My question is whether I should take these TrueType fonts and test them against my new coverage tables, at least for languages which aren't covered by the codePageRange bits. I now have coverage information for 76 of the 139 ISO 639-1 language names; I used the Unicode code charts to mark coverage for the Indic languages and a few other scripts: Bengali (BN) Tibetan (BO) Gujarati (GU) Khmer (KM) Kannada (KN) Lao (LO) Malayalam (ML) Mongolian (MN) Oriya (OR) Sinhala (Sinhalese) (SI) Tamil (TA) Telugu (GE) Tagalog (TL) Given that these languages have unique alphabets, this method seems relatively sound. I'm still missing several Indic languages and all of the non-arabic African languages. I did remove the @ and ` marks from the latin scripts; that should leave all of them including only the alphabet. I've also committed this whole mess to XFree86 CVS; the coverage files can be found in xc/lib/fontconfig/fc-lang/*.orth Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]fcfreetype.c
Around 22 o'clock on Jul 7, Yu Shao wrote: It seems a typo and I think using FcCodePageSet is always safer? Good catch, there was a typo, but that code has since been deleted in favor of the new RFC 3066-based language detection. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Re: [I18n]Unicode coverage for languages
Around 23 o'clock on Jul 7, Roger So wrote: 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?) Yes, each language-country pair may specify it's own orthography. zh-HK and zh-MO could use the zh-TW set. To complicate matters, zh-HK uses traditional Chinese, but with more characters than usually is with zh-TW. (Big5 vs Big5 HKSCS) That's fine; zh-HK would use a separate orthography that included the additional glyphs. 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... Yes, GB18030 makes this harder -- my GB18030 fonts cover all of Big5 making it essentially impossible to distinguish by code coverage. Fortunately, all of the GB18030 fonts that I've seen are in TrueType format and include the appropriate OS/2 codePageRange bits which indicate design intent. 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. Han unification produces it's own issues here which can best be resolved by having fonts specify their target languages. I suspect the best plan may well be to use Unicode coverage for language inclusion and then exclude certain Han languages based on the codePageRange bits. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] [I18n] language tags in fontconfig
Around 10 o'clock on Jul 7, Dr Andrew C Aitchison wrote: I'm curious because I can't understand the differences between xc/lib/fontconfig/fc-lang/en.orth and xc/lib/fontconfig/fc-lang/fr.orth In particular I remember 00e1 (a acute/Ã)¡ but not00f1 (n tilda/Ã) from my French lessons. (Are you sending text in UTF-8?) The orthographies I built were taken from a source which attempted to include every letter needed to write a particular language, even those which might be only infrequently used. For english, we have words like: rôle, à la king, naïve While the ascii-ification of english is pervasive, my Websters New World Dictionary (not known for it's inclusiveness in general) still lists these spellings as native. While I've never seen ñ in my limited exposure to French, I don't find it impossible to believe that it occurs in some limited contexts, perhaps for place names along the border with Spain? The only questionable thing I believe I've done is to eliminate the OE ligatures and Y with diaeresis from the French list -- those aren't in Latin 1, and I wanted to permit Latin-1 fonts to be marked as supporting French. Note that none of this prohibits applications and users from explicitly selecting a font which is inappropriate for their current locale or document language -- explicit family names are now given greater weight than language matching when selecting fonts. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Using current locale in font selection
Much as I hate the C locale model, I'm wondering if I shouldn't use the current locale as a language hint where applications don't provide explicit language information when selecting fonts. This would make the generic aliases (like sans-serif) pick a font appropriate for the locale instead of some random font most likely suitable for Latin languages. Or would this only lead to confusion and chaos? Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Automatic 'lang' determination
Around 9 o'clock on Jun 29, Jungshik Shin wrote: IMHO, most problems with Han Unification arise not from using a _single_ font targeted at one of zh_TW/zh_CN/ja/ko to render a run of text in another but from mixing _multiple_ fonts (with _drastically different_ design principle and other differences like baseline) to render a single run of text (say, 65% of characters drawn from one font, 25% from a second font, 7% from a third font, etc). Yes, I agree -- this is true in Western languages as well where the application selects a font covering only Latin-1 and attempts to display text requiring glyphs from Latin-2; a smart application will locate an additional font to fill-in the missing glyphs, the result looks like a ransom note. The hope is that proper language tags in the document can avoid this at the start by making the first font contain the proper coverage for the entire block of text. This goal is reflected in the design I outlined -- fonts are deemed suitable for a particular language when they cover a significant fraction of the codepoints commonly associated with that language. Suppose there's a document tagged as zh_TW that explains how PRC government simplified Chinese characters to boost the literacy rate after WW II. If a Big5 font (that doesn't cover all characters in the doc) is selected instead of a GBK/GB18030 font (with the full coverage), simplified Han characters(not used in Taiwan but only used in PRC) in the doc have to be rendered with another font (most likely GB2312/GBK/GB18030 font). A correct version of this document would tag individual sections of the document with appropriate tags. This way, the zh_TW sections could be presented in a traditional Chinese font while the mainland portions are displayed with simplified Chinese glyphs. I don't know how prevalent language tagging is in office document formats, but it's certainly available in HTML. It's the HTML case that started my journey into language tags. I'm not sure what you meant by 'glyph forms are more likely simplified'. You might have misunderstood some aspects of Han Unification in Unicode/10646. In Unicode, simplified forms of Chinese characters are NOT unified with corresponding traditional forms of Chinese characters. You're right -- I didn't believe this to be the case. I had heard that the unified portion within the BMP do co-mingle simplified and traditional forms, but that the non-BMP Han extension provide separate codepoints for each. If even BMP codepoints are separate, then it should be possible to create a large set of codepoints which could mark fonts as suitable for the display of simplified Chinese which are distinct from the set of codepoitns suitable for the display of traditional Chinese. That would be nicer than my current kludge of marking any font suitable for traditional chinese as unsuitable for simplified Chinese. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Automatic 'lang' determination
Around 13 o'clock on Jun 29, Yao Zhang wrote: if (covers_much_of (gb18030)) font supports simplified Chinese if (covers_almost_all_of (Big5)) font supports traditional Chinese font does not support simplified Chinese For a GB18030 font, since it covers much of GB18030 set, it suports simplified Chinese. And is also covers almost all of BIG5, so it supports traditional Chinese too. But now the algorithm excludes it from simplified Chinese support. The last line is wrong. Yes, I think the problem is that I'm using GBK for the test instead of GB2312 -- I got the simplified coverage information from codepage 936 which is based on GBK. The fonts I have don't cover most of GBK, but do cover nearly all of GB2312. if (covers_almost_all_of (GB2312)) font supports SIMPLIFIED Chinese if (covers_almost_all_of (Big5)) font supports traditional Chinese Thanks, this works just fine. I'm much happier with this solution. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Automatic 'lang' determination
Around 20 o'clock on Jun 29, Pablo Saratxaga wrote: A font is suited for a given language when it covers *ALL* of the codepoints needed for that language. Yes, that's obviously true, but the problem is that I don't have tables for each language indicating the required codepoints, all I have are tables listing Unicode values in encodings traditionally used for each language. These tables almost always include a few (1-5) glyphs which many fonts are missing. So, the test is to require that the number of missing glyphs for non-Han languages is very small (8) to allow fonts which happen to be missing only a few unimportant glyphs to be used. Discovering which glyphs in each encoding are problematic in many fonts would allow this fudge factor to be reduced further. So, the tests for CJK languages and for other languages are clearly different, only CJK languages can go with testing only a signifiant fraction, for all other languages all chars must be tested. Yes, the tolerance value given for the Han languages is 500 codepoints while the value for non-Han languages is two orders of magnitude smaller. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Automatic 'lang' determination
Around 14 o'clock on Jun 29, Yao Zhang wrote: Sure, I will install as many Chinese fonts as possible and get the fonts.cache for you. But before that, I will show you serveral lines in my fonts.cache: I'm afraid the mailers corrupted the rather long lines in those files, but given that I've discovered that GB2312 is a relatively strong test for suitability for simplified chinese, perhaps we can avoid sending this data at all. Now for lang, ZYSong18030 is labelled as lang=simplifiedchinese while SimSun-18030 is labelled as lang=latin1,arabic,simplifiedchinese,koreanwansung,traditionalchinese,koreanjohab,arabic864,arabicasmo708,us These language tags come from the OS/2 table and are set by the font designer. If, as our friend Jungshik Shin says, simplified forms were not unified with traditional forms in the BMP, then it's quite reasonable to build a font that can cover both languages. With the new improved GB2312-based simplified test, I suspect the correct languages would be generated automatically from this font as well. I've gone ahead and committed the changes necessary for automatic lang determination to XFree86 CVS; those interested in verifying it's sensitivity and specificity are welcome to check it out and run: $ FC_DEBUG=256 fc-cache -f This will display the number of missing glyphs in each language for each font and also display errors in the lang value relative to that specified in the TrueType file. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts][OpenType] Hinting question
Around 11 o'clock on Jun 10, Erik van der Poel wrote: It shouldn't be that hard to change the X-specific parts of Mozilla to pass down the DPI and point size, since the machine-independent parts of Mozilla do pass down this info. The place where point size is converted to pixel size isn't that far from X-specific calls. The Mozilla code follows the X core-font version which always uses pixel sizes; the UI exposes pixel sizes in the configuration UI. I did't like this, but followed along in the Mozilla patches. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts][OpenType] Hinting question
Around 19 o'clock on Jun 7, James H. Cloos Jr. wrote:
Are there any implementation details in freetype of xft{1,2} that
would prevent this from working?
Yes. Xft currently passes only pixel sizes down to FreeType, and some
applications (Mozilla) don't pass down DPI or point size. When the
information was available, I could pass it down.
(As you might guess, I'm a big fan of optically scaled fonts.)
I was unaware that any foundrys were spending the time and money to build
fonts in this fashion any more. It would be nice...
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
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)
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
[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
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]Updated prerelease for Xft and fontconfig
Around 0 o'clock on May 31, Keith Packard wrote: I've updated the tarballs containing Xft and fontconfig bits and have included Xrender and Xft1 sources as well. Those haven't been 'autoconf'ized yet, so they only build with xmkmf. I forgot to include the path to the files; it's the same as before: http://keithp.com/fonts I repackaged stuff in a single tarball 'fcpackage.timestamp.tar.gz' and will put new versions in the same directory (with a different timestamp). As usual, all of this stuff is also in XFree86 CVS, the only difference is that this tarball includes a couple of files from outside the library directories that have changed since XFree86 4.1 shipped -- notably the render extension header files, and a couple of files that don't get installed but which are necessary to build an extension library (extutil.h and region.h). Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Ciach bitscale! [2nd attempt]
Around 18 o'clock on May 31, Juliusz Chroboczek wrote: I'd be glad to get some feedback before submitting it. If people object, I can always make a patch that makes the bitmap scaling optional but doesn't actually remove any code. Mike Harris has built a similar patch and my comments to him were essentially that there are probably applications out there that depend on the existance of scalable names for all fonts, so I suspect we need to make the bitmap scaler optional; allow either :scaled or :unscaled options on the font path elements and make the default :unscaled. I'd like to have a build-time option to get rid of the code for kdrive servers, but the main XFree86 server should probably be built with the code in place, but disabled by default. An alternative that could work is to (optionally) advertise scalable names but do nearest-size matching instead of bitmap scaling; that keeps broken applications working while avoiding horrors on the screen, and eliminating the scaling code from the server. Perhaps ':nearest'? Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]typo in xft-config.in
Around 22 o'clock on May 30, =?ISO-8859-1?Q?Joaqu=EDn?= Cuenca Abela wrote: is it only me, or xft-config.in (line 92) should be: libs=-lXft ... Yes, that's correct -- someone else noted this a couple of days ago. The fix is in CVS, but I haven't rebuilt the tarballs since then. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]What's language tag??
Around 9 o'clock on May 31, Zenith Lau wrote: I have seem many times in this mailing list, on the term 'language tag'. But I don't know what is it. Would anyone mind explain a little bit for me?? This comes from the OS/2 tables which (I presume) come from the IBM OS/2 internationalization stuff. There are 64 bits in this table which were originally designed to indicate which CodePages the font supported, now we use them strictly to identify the target language where Unicode ranges aren't sufficient. They are independent from the Unicode ranges as Unicode overlaps codepoints from different languages, while the old CodePages had separate entries for each language. The most prominent example of Unicode overlays is for the Han glyphs used in chinese, japanese and korean writing. It is important to pick a font designed for the document language to ensure that the glyphs are readily understandable by the target user; when the document doesn't specify an available face, we use language tags to automatically select ones appropriate instead of just finding some face that can present the specified Unicode codepoints. Here's what the fontconfig header has to say about them: /* language groups from the OS/2 CodePageRange bits */ #define FC_LANG_LATIN_1 latin1/* 0 */ #define FC_LANG_LATIN_2_EASTERN_EUROPE latin2easterneurope /* 1 */ #define FC_LANG_CYRILLICcyrillic /* 2 */ #define FC_LANG_GREEK greek /* 3 */ #define FC_LANG_TURKISH turkish /* 4 */ #define FC_LANG_HEBREW hebrew/* 5 */ #define FC_LANG_ARABIC arabic/* 6 */ #define FC_LANG_WINDOWS_BALTIC windowsbaltic /* 7 */ #define FC_LANG_VIETNAMESE vietnamese/* 8 */ /* 9-15 reserved for Alternate ANSI */ #define FC_LANG_THAIthai /* 16 */ #define FC_LANG_JAPANESEjapanese /* 17 */ #define FC_LANG_SIMPLIFIED_CHINESE simplifiedchinese /* 18 */ #define FC_LANG_KOREAN_WANSUNG koreanwansung /* 19 */ #define FC_LANG_TRADITIONAL_CHINESE traditionalchinese/* 20 */ #define FC_LANG_KOREAN_JOHABkoreanjohab /* 21 */ /* 22-28 reserved for Alternate ANSI OEM */ #define FC_LANG_MACINTOSH macintosh /* 29 */ #define FC_LANG_OEM oem /* 30 */ #define FC_LANG_SYMBOL symbol/* 31 */ /* 32-47 reserved for OEM */ #define FC_LANG_IBM_GREEK ibmgreek /* 48 */ #define FC_LANG_MSDOS_RUSSIAN msdosrussian /* 49 */ #define FC_LANG_MSDOS_NORDICmsdosnordic /* 50 */ #define FC_LANG_ARABIC_864 arabic864 /* 51 */ #define FC_LANG_MSDOS_CANADIAN_FRENCH msdoscanadianfrench /* 52 */ #define FC_LANG_HEBREW_862 hebrew862 /* 53 */ #define FC_LANG_MSDOS_ICELANDIC msdosicelandic/* 54 */ #define FC_LANG_MSDOS_PORTUGUESEmsdosportuguese /* 55 */ #define FC_LANG_IBM_TURKISH ibmturkish/* 56 */ #define FC_LANG_IBM_CYRILLICibmcyrillic /* 57 */ #define FC_LANG_LATIN_2 latin2/* 58 */ #define FC_LANG_MSDOS_BALTICmsdosbaltic /* 59 */ #define FC_LANG_GREEK_437_G greek437g /* 60 */ #define FC_LANG_ARABIC_ASMO_708 arabicasmo708 /* 61 */ #define FC_LANG_WE_LATIN_1 welatin1 /* 62 */ #define FC_LANG_US us/* 63 */ Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Releasing Xft2 and Fontconfig
Around 2 o'clock on May 29, James H. Cloos Jr. wrote: Fontconfig-1.0.1's fc-cache dies when it hits a directory containing code2001.ttf. I presume it is due to the non-bmp characters in the font. ftview displays the font. pfaedit says: If you send that font along, I can fix FreeType so it doesn't crash. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Releasing Xft2 and Fontconfig
Around 12 o'clock on May 29, Roozbeh Pournader wrote: Fontconfig-1.0.1's fc-cache dies when it hits a directory containing code2001.ttf. I presume it is due to the non-bmp characters in the font. ftview displays the font. pfaedit says: Well, it doesn't crash for me. But, my version of FreeType (2.0.9) doesn't seem to find any non-BMP encodings in the type-4 table, it finds 30 type 4 segments in code2001.ttf, the last of which encodes glyph 65535. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Re: Notes on Pango Xft backend
run fast enough to be left uncached. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Re: Xft2 and pcf fonts
Around 17 o'clock on May 28, Yu Shao wrote: I tested Xft2 with some Chinese pcf fonts, like gb16fs.pcf.gz come with Xfree86 4.2, FreeType can't yet read PCF fonts that are compressed; it should be able to read them if you uncompress them first. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Re: Font lookup ranges [was Re: Notes on Pango Xft backend]
Around 14 o'clock on May 28, Owen Taylor wrote: The one place where a fix is urgently needed is for Japanese vs. Traditional Chinese vs. Simplified Chinese; things look pretty awful there at the moment; but what I want to do first in that area is make font selection locale/language-tag sensitive. That means tagging sections of text with the language and exposing the font language tags in the list of fonts I hand back. Alternatively, you can create separate lists, one for each language tag found for each logical font. That might be best as I expect font pattern editing to be used to select preferred faces for each language tag. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
