[Fonts]Fontconfig + patched qt-3.0.5 doesn't allow bitmap fixed font
Yesterday I installed the XFt-2 enabled QT. Now running konsole (the kde terminal application) It started out with very wide characters (from arial) This is caused by the fact that the font selection mechanism refuses to match the -misc-fixed-medium-r-* bitmapped font. I've tried out several configurations but none helped (except aliassing to a monospaced font, not arial). I'll attach a log from starting konsole, and my font.conf file. -- Paul de Vrieze Junior Researcher Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net XFT_DEBUG=4047 XftFontMatch pattern Pattern 6 of 16 encoding: iso10646-1 family: arial sans foundry: monotype size: 12 slant: 0 weight: 100 XftFontMatch after FcConfig substitutions Pattern 7 of 16 dpi: 75 encoding: iso10646-1 family: arial Verdana Arial Verdana Nimbus Sans L Luxi Sans Arial Helvetica Kochi Gothic AR PL KaitiM GB AR PL KaitiM Big5 Baekmuk Dotum SimSun sans-serif sans-serif foundry: monotype size: 12 slant: 0 weight: 100 XftDisplayInfoGet Default visual 0x23 format 0,16,8,0 XftDisplayInfoGet initialized, hasRender set to True global max cache memory 4194304 global max unref fonts 16 XftFontMatch after X resource substitutions Pattern 18 of 32 antialias: FcTrue autohint: FcFalse dpi: 75 encoding: iso10646-1 family: arial Verdana Arial Verdana Nimbus Sans L Luxi Sans Arial Helvetica Kochi Gothic AR PL KaitiM GB AR PL KaitiM Big5 Baekmuk Dotum SimSun sans-serif sans-serif foundry: monotype globaladvance: FcTrue hinting: FcTrue maxglyphmemory: 1048576 minspace: FcFalse pixelsize: 12.5 render: FcTrue rgba: 0 scale: 1 size: 12 slant: 0 verticallayout: FcFalse weight: 100 XftFontMatch result Pattern 25 of 32 antialias: FcFalse autohint: FcFalse charset: set dpi: 75 encoding: iso10646-1 family: Arial file: /usr/X11R6/lib/X11/fonts/truetype/arial.ttf foundry: monotype globaladvance: FcTrue hinting: FcTrue index: 0 lang: langset maxglyphmemory: 1048576 minspace: FcFalse outline: FcTrue pixelsize: 12.5 render: FcTrue rgba: 0 scalable: FcTrue scale: 1 size: 12 slant: 0 style: Regular verticallayout: FcFalse weight: 100 XftFontInfoFill: /usr/X11R6/lib/X11/fonts/truetype/arial.ttf: 0 (12.5 pixels) New font /usr/X11R6/lib/X11/fonts/truetype/arial.ttf/0 size 12x12 XftFontMatch pattern Pattern 5 of 16 encoding: iso10646-1 family: fixed sans size: 12 slant: 0 weight: 100 XftFontMatch after FcConfig substitutions Pattern 6 of 16 dpi: 75 encoding: iso10646-1 family: fixed Arial Verdana Nimbus Sans L Luxi Sans Arial Helvetica Kochi Gothic AR PL KaitiM GB AR PL KaitiM Big5 Baekmuk Dotum SimSun sans-serif size: 12 slant: 0 weight: 100 XftFontMatch after X resource substitutions Pattern 17 of 32 antialias: FcTrue autohint: FcFalse dpi: 75 encoding: iso10646-1 family: fixed Arial Verdana Nimbus Sans L Luxi Sans Arial Helvetica Kochi Gothic AR PL KaitiM GB AR PL KaitiM Big5 Baekmuk Dotum SimSun sans-serif globaladvance: FcTrue hinting: FcTrue maxglyphmemory: 1048576 minspace: FcFalse pixelsize: 12.5 render: FcTrue rgba: 0 scale: 1 size: 12 slant: 0 verticallayout: FcFalse weight: 100 XftFontMatch result Pattern 24 of 32 antialias: FcFalse autohint: FcFalse charset: set dpi: 75 encoding: iso10646-1 family: Arial file: /usr/X11R6/lib/X11/fonts/truetype/arial.ttf globaladvance: FcTrue hinting: FcTrue index: 0 lang: langset maxglyphmemory: 1048576 minspace: FcFalse outline: FcTrue pixelsize: 12.5 render: FcTrue rgba: 0 scalable: FcTrue scale: 1 size: 12 slant: 0 style: Regular verticallayout: FcFalse weight: 100 XftFontInfoFill: /usr/X11R6/lib/X11/fonts/truetype/arial.ttf: 0 (12.5 pixels) Caching glyph 0x3 size 20 Caching glyph 0x4 size 60 Caching glyph 0x5 size 32 Caching glyph 0x6 size 60 Caching glyph 0x7 size 64 Caching glyph 0x8 size 60 Caching glyph 0x9 size 60 Caching glyph 0xa size 32 Caching glyph 0xb size 72 Caching glyph 0xc size 72 Caching glyph 0xd size 36 Caching glyph 0xe size 48 Caching glyph 0xf size 32 Caching glyph 0x10 size 24 Caching glyph 0x11 size 24 Caching glyph 0x12 size 60 Caching glyph 0x13 size 60 Caching glyph 0x14 size 60 Caching glyph 0x15 size 60 Caching glyph 0x16 size 60 Caching glyph 0x17 size 60 Caching glyph 0x18 size 60 Caching glyph 0x19 size 60 Caching glyph 0x1a size 60 Caching glyph 0x1b size 60 Caching glyph 0x1c size 60 Caching glyph 0x1d size 48 Caching glyph 0x1e size 56 Caching glyph 0x1f size 48 Caching glyph 0x20 size 36 Caching glyph 0x21 size 48 Caching glyph 0x22 size 60 Caching glyph 0x23 size 72 Caching glyph 0x24 size 60 Caching glyph 0x25 size 60 Caching glyph 0x26 size 60 Caching glyph 0x27 size 60 Caching glyph 0x28 size 60 Caching glyph 0x29 size 60 Caching glyph 0x2a size 60 Caching glyph 0x2b size 60 Caching glyph 0x2c size 60 Caching glyph 0x2d size 60 Caching glyph 0x2e size 60 Caching glyph 0x2f size 60 Caching glyph 0x30 size 60 Caching glyph 0x31 size 60 Caching glyph 0x32 size 60 Caching glyph 0x33 size
Re: [Fonts]Fontconfig + patched qt-3.0.5 doesn't allow bitmap fixed font
I have the same problem and I think this is because fontconfig uses hinting for all fonts by default. I *think* ( provided not sure ) turning hinting off would solve the problem completely. But I dont know how to turn off hinting completely in fonts.conf. Maybe you know how? This happened to me with xft1 too , and I used David Chester's nohinting patch for Xft1 and it worked. Hope that Helps /ismail = Microsoft Windows: made for the internet The Internet: made for UNIX __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Fontconfig + patched qt-3.0.5 doesn't allow bitmap fixedfont
Paul de Vrieze wrote: Yesterday I installed the XFt-2 enabled QT. Now running konsole (the kde terminal application) It started out with very wide characters (from arial) This is caused by the fact that the font selection mechanism refuses to match the -misc-fixed-medium-r-* bitmapped font. I've tried out several configurations but none helped (except aliassing to a monospaced font, not arial). I can't tell from the log whether you have made any bitmap fonts available to fontconfig. On my Red Hat 8 system, I have found that I can use PCF fonts in konsole by putting un-gzipped copies of them in /usr/share/fonts/bitmap-fonts (or presumably any other directory listed in fonts.conf) and running fc-cache. As an aside, this doesn't work for the Courier fonts that ship with XFree86. I suspect that this is because a couple of them don't have a spacing value. -- Ian Pilcher [EMAIL PROTECTED] ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Fontconfig + patched qt-3.0.5 doesn't allow bitmap fixedfont
Paul de Vrieze wrote:
On Friday 18 October 2002 05:21, Ian Pilcher wrote:
As an aside, this doesn't work for the Courier fonts that ship with
XFree86. I suspect that this is because a couple of them don't have a
spacing value.
How can I check this?
Here is my very first fontconfig program. The usage is:
fcdump [-d] [pattern]
If '-d' is omitted, a single-line version of each pattern will be
printed (with FcNameUnparse); if '-d' is present, a multi-line version
will be printed (with FcPatternPrint). If no pattern is supplied, all
fonts will be printed.
--
Ian Pilcher [EMAIL PROTECTED]
#include stdlib.h
#include string.h
#include stdio.h
#include errno.h
#include fontconfig/fontconfig.h
int main(int argc, char *argv[])
{
FcFontSet *fonts;
int i, print_detail = 0;
FcChar8 *name;
FcPattern *pattern = NULL;
FcObjectSet *objects;
if (argc = 2 strcmp(argv[1], -d) == 0)
print_detail = 1;
if (FcInit() != FcTrue)
{
perror(FcInit);
exit(__LINE__);
}
if (argc = 2 + print_detail)
{
pattern = FcNameParse(argv[1 + print_detail]);
if (pattern == NULL)
{
perror(FcNameParse);
exit(__LINE__);
}
objects = FcObjectSetBuild(FC_FAMILY, FC_STYLE, FC_SLANT, FC_WEIGHT,
FC_SIZE, FC_ASPECT, FC_PIXEL_SIZE, FC_SPACING, FC_FOUNDRY,
FC_ANTIALIAS, FC_HINTING, FC_VERTICAL_LAYOUT, FC_AUTOHINT,
FC_GLOBAL_ADVANCE, FC_FILE, FC_INDEX, FC_FT_FACE, FC_RASTERIZER,
FC_OUTLINE, FC_SCALABLE, FC_SCALE, FC_DPI, FC_RGBA, FC_MINSPACE,
NULL);
fonts = FcFontList(NULL, pattern, objects);
if (fonts == NULL)
{
perror(FcFontList);
exit(__LINE__);
}
}
else
{
fonts = FcConfigGetFonts(NULL, FcSetSystem);
if (fonts == NULL)
{
perror(FcConfigGetFonts);
exit(__LINE__);
}
}
for (i = 0; i fonts-nfont; ++i)
{
if (print_detail)
{
FcPatternPrint(fonts-fonts[i]);
continue;
}
name = FcNameUnparse(fonts-fonts[i]);
if (name == NULL)
{
perror(FcNameUnparse);
exit(__LINE__);
}
pattern = FcNameParse(name);
if (pattern == NULL)
{
perror(FcNameParse);
exit(__LINE__);
}
free(name);
FcPatternDel(pattern, FC_CHARSET);
FcPatternDel(pattern, FC_LANG);
name = FcNameUnparse(pattern);
if (name == NULL)
{
perror(FcNameUnparse);
exit(__LINE__);
}
puts(name);
FcPatternDestroy(pattern);
free(name);
}
return 0;
}
Re: [Fonts]fontconfig peculiarity(??)
On Fri, 18 Oct 2002, Keith Packard wrote: Around 7 o'clock on Oct 18, Jungshik Shin wrote: For some unknown reason, 'New Gulim' is picked up by 'fontconfig' or 'Xft' for a certain characters when CODE2000 is explicitly requested by applications like Mozilla and gedit (via Pango) More specifically, those certain characters are U+115F(Hangul leading consonant filler) and U+1160(Hangul trailing consonant filler). Fontconfig has a kludge to weed out fonts with broken encoding tables; such fonts often have encoding table entries pointing at blank glyphs which aren't supposed to be blank. It checks each glyph in the encoding and ignores those which are inappropriately blank. which are expected to be blank, that list was derived from a similar table in Mozilla. Blank glyphs not in the table are assumed to represent broken Keith, we talked about this a month ago (Sep. 7th) on this very list :-) You came up with a much more extensive list of characters than Mozilla's blank glyph list. I also filed a bug for Mozilla-Windows (http://bugzilla.mozilla.org/show_bug.cgi?id=167136). You must have forgottent about it. :-) I added those two characters to the blank glyph list /etc/fonts/fonts.conf then. In addition, both Ngulim and Code2000 have blank glyphs for both characters. The only difference is that in Ngulim they're both *spacing*(width 0) while in Code2000 only U+115f is spacing and U+1160 is non-spacing(width=0). So, even if my blank glyph list doesn't have them, there's no reason I can think of Ngulim is preferred over Code2000 for those characters. If they're equal on this count, the explicit request seems to have to take precedence, doesn't it? One possible explanation is that Code2000 isn't marked as supporting 'ko' in font-cache for some reason while Ngulim is. However, both fonts have more or less similar coverage of Korean characters (the full set of precomposed syllables and Hangul Conjoining Jamos and other symbols in KS X 1001). So, this is a bit mytery, too. weren't included in the table. This means that no font will ever be listed as supporting these glyphs, so Mozilla will pick the first font in the match list to draw them with, expecting that this will produce a missing glyph indication. BTW, could it be possible to 'deceive' or 'force' fontconfig to believe that a certain font covers a certain range of Unicode even if it doesn't appear to? I guess it's not possible at the moment, but wouldn't it be nice to add it? What I'm thinking of is something like this: match target=font test qual=any name=familystringGulim Old Hangul Jamo/string/test edit name=coverage mode=assign binding=strong coderanges./coderanges/edit /match where coderanges are a comman-separated list of unicode code points (integer) or code ranges (sth. like [0x-0x]). I found in font cache file that charset property does exactly the thing I want to do with 'coderanges'. If so, would it be possible to use 'charset' to achieve what I described above? Well, I've gotta figure out how 'charset' represents Unicode ranges. Some fonts have a hack-encoding (although advertised as in Unicode) and their apparent Unicode coverage cannot be guessed at all by fontconfig based on Unicode cmap. An application or library aware of this hack-encoding can do some hack with them, though. However, fontconfig does not appear to return a requested font and come up with a fallback after 'intelligent guess' even if explicitly specified because what it thinks a font with hack-encoding can cover does not match at all the range of Unicode an application want to draw with the font. It'd be also nice to be able to do something similar with 'lang' tag. I thought the following line would *make* fontconfig *believe* (*ignoring* what it finds out with OS lang tag and orthography map) that 'Gulim Old Hangul Jamo' is suitable for Korean, but it doesn't seem to work. Did I do anything wrong? --- match target=font test qual=any name=familystringGulim Old Hangul Jamo/string/test edit name=lang mode=assign binding=strongstringko/string/edit /match --- Both of these certaily look like a hack, but some applications (perhaps mathml, Indic script handling, Korean alphabet handling...) need them until OTFs are widely available. Related problems are talked about at http://bugzilla.mozilla.org/show_bug.cgi?id=126919#c315 and comments references therein. http://bugzilla.mozilla.org/show_bug.cgi?id=95708 Jungshik ___ 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 + patched qt-3.0.5 doesn't allow bitmap fixed font
On Friday 18 October 2002 16:48, Owen Taylor wrote: Paul de Vrieze [EMAIL PROTECTED] writes: Yesterday I installed the XFt-2 enabled QT. Now running konsole (the kde terminal application) It started out with very wide characters (from arial) This is caused by the fact that the font selection mechanism refuses to match the -misc-fixed-medium-r-* bitmapped font. I've tried out several configurations but none helped (except aliassing to a monospaced font, not arial). I'll attach a log from starting konsole, and my font.conf file. Basically Konsole is looking for a font that isn't there so it falls back to the default. The only thing to do about this is to patch the hardcoded default fonts. The attached is a patch from the Red Hat 8 KDE packages to do this. (I'm not sure if it's the final version or not -- it's just what was sitting in my patches directory.) It uses 'monospace' - the standard fontconfig name for the default monospace font - instead of 'fixed' For your own use, you can also just select a different font with the font selector in Konsole, of course. I allready found the problem. The problem is the fact that the fixed font is not found. This is because all my pcf fonts are gzipped by default. For some reason fontconfig doesn't recognize them in this case. I will check whether I can come up with some patch for this. Paul -- Paul de Vrieze Junior Researcher Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Fontconfig + patched qt-3.0.5 doesn't allow bitmap fixed font
In article [EMAIL PROTECTED], Paul de Vrieze [EMAIL PROTECTED] writes: PdV I allready found the problem. The problem is the fact that the PdV fixed font is not found. This is because all my pcf fonts are PdV gzipped by default. For some reason fontconfig doesn't recognize PdV them in this case. I will check whether I can come up with some PdV patch for this. The problem is indeed at the FreeType level. When I have some time, I'll implement a decompressing filter for FreeType. It will use petabytes of memory, but will provide a short-term solution for people with petabytes of memory. The long-term solution is to dump the PCF format. This won't happen in time for 4.3.0. (Not to imply that the former will.) Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Fontconfig + patched qt-3.0.5 doesn't allow bitmap fixed font
The problem is indeed at the FreeType level. When I have some time, I'll implement a decompressing filter for FreeType. It will use petabytes of memory, but will provide a short-term solution for people with petabytes of memory. The long-term solution is to dump the PCF format. This won't happen in time for 4.3.0. (Not to imply that the former will.) I allready checked the freetype lists, and came to the conclusion that appart from a short discussion in february nothing is being done about pcf files for that memory reasons. At the moment I uncompressed the fonts, but a real solution should be better. Paul -- Paul de Vrieze Junior Researcher Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]fontconfig peculiarity(??)
On Fri, 18 Oct 2002, Keith Packard wrote: Around 12 o'clock on Oct 18, Jungshik Shin wrote: One possible explanation is that Code2000 isn't marked as supporting 'ko' in font-cache for some reason while Ngulim is. This explanation only makes sense when those two chars are NOT included in the blank glyph list, doesn't it? As I wrote, they've have been in the blank glyph list in my fonts.conf since early September. 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 :-) ? 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. 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. 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. Therefore, my original mystery still remains a mystery :-) 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 Sorry I didn't check Han glyphs only checking that it has the full set of precomposed Hangul syllables(11,172 of them.). 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? Jungshik ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]FreeType 2 and gzipped font files
A first draft of a patch to allow FreeType 2 (current CVS) to read gzipped font files is available from http://www.pps.jussieu.fr/~jch/software/files/freetype2-gzip-20021019.patch.gz This patch works by keeping in memory the part of the uncompressed font file that has already been seen. The weak point is that compressed files are detected by filename extension; a cleaner solution would be to have the stock stream implementations invoke it when they detect the signature of a gzipped file. I didn't try to make it optional. Feel free to include a suitably modified version of this patch in FreeType if you find it suitable. Regards, Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Fontconfig + patched qt-3.0.5 doesn't allow bitmap fixed font
PdV I allready checked the freetype lists, and came to the conclusion PdV that appart from a short discussion in february nothing is being PdV done about pcf files for that memory reasons. http://www.xfree86.org/pipermail/fonts/2002-August/002019.html Juliusz ___ 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
