Mike FABIAN
2006-Jan-30 11:41 UTC
[Fontconfig] patch: destroy ~/.fonts.cache-2 if it doesn''t start with FC_GLOBAL_MAGIC_COOKIE or no string can be read at all from that file.
A colleague again had a problem with a apparently broken
~/.fonts.cache-2 file. The file is here:
http://lisa.goe.net/~mfabian/.fonts.cache-2-T42p-JP
The file is huge (78 Megabytes) and apparently broken, as it doesn''t
start with FC_GLOBAL_MAGIC_COOKIE.
When calling
fc-match sans
this took a lot of time *always* the broken file was never fixed.
Actually it grew bigger and bigger all the time.
I believe if FcGlobalCacheLoad () cannot read any string at all from
~/.fonts.cache-2 or if the file does not start with
FC_GLOBAL_MAGIC_COOKIE it should exit with "goto bail_and_destroy;" to
delete the broken file instead of just "return;".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: destroy-completely-broken-cache-files-in-home-directory.patch
Type: text/x-patch
Size: 632 bytes
Desc: not available
Url :
http://lists.freedesktop.org/archives/fontconfig/attachments/20060130/6ca4f7fe/destroy-completely-broken-cache-files-in-home-directory.bin
-------------- next part --------------
--
Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian
?????????????
Mike FABIAN
2006-Jan-30 12:42 UTC
[Fontconfig] patch: fc-cache should not stop at the first non existing directory.
Currently fc-cache stops at the first directory listed in /etc/fonts/fonts.conf which doesn''t exist and does not continue to created caches for the other directories which may exist. If for example "/usr/share/fonts" is the first directory in /etc/fonts/fonts.conf and this directory doesn''t exist (move it out of the way for testing), fc-cache immediately returns and says "succeeded" although it didn''t create any caches. Patch attched. -------------- next part -------------- A non-text attachment was scrubbed... Name: fc-cache-should-not-stop-at-the-first-non-existing-directory.patch Type: text/x-patch Size: 1124 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20060130/caa2eb75/fc-cache-should-not-stop-at-the-first-non-existing-directory.bin -------------- next part -------------- -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
Mike FABIAN
2006-Jan-30 13:10 UTC
[Fontconfig] most fonts don''t support English anymore???
Why is suddenly "en" missing in the "lang" output for fonts like "Arial" and "FreeSans" which certainly support English?: mfabian@magellan:~$ fc-list "Arial:style=Regular" family file style lang /usr/X11R6/lib/X11/fonts/truetype/arial.ttf: Arial:style=Regular,Normal,oby?ejn?,Standard,????????,Normaali,Norm?l,Normale,Standaard,Normalny,???????,Norm?lne,Navadno,th???ng,Arrunta:lang=aa|af|ar|ast|ava|ay|az|az-ir|be|bg|bi|bin|br|bua|ca|ce|ch|co|cs|cy|da|et|eu|fa|fj|fo|fr|fur|fy|gd|gl|gn|gv|he|ho|hu|ia|id|ie|ik|io|is|kaa|kk|kl|kum|ky|lb|lez|mg|mt|nb|nds|nn|no|oc|om|os|pl|rm|ru|se|sel|sh|sk|sma|smj|smn|so|sq|sr|sv|sw|tk|tn|tr|ts|tt|tyv|ug|uk|vo|wa|wen|wo|xh|yap|yi|zu mfabian@magellan:~$ fc-list "FreeSans:style=Medium" family file style lang /usr/X11R6/lib/X11/fonts/truetype/FreeSans.ttf: FreeSans:style=Medium,navadno:lang=aa|ab|af|ast|ava|ay|az|ba|bam|be|bg|bi|bin|bn|br|bs|bua|ca|ce|ch|chm|co|cs|cv|cy|da|eo|et|eu|fj|fo|fr|ful|fur|fy|ga|gd|gl|gn|gv|ha|haw|he|ho|hr|hu|hy|ia|id|ie|ik|io|is|kaa|ki|kk|kl|ku|kum|kv|kw|ky|la|lb|lez|lt|lv|mg|mh|mi|mk|mt|nb|nds|nn|no|ny|oc|om|os|pl|rm|ru|sah|sco|se|sel|sh|sk|sl|sma|smj|smn|so|sq|sr|sv|sw|syr|tg|tk|tn|tr|ts|tt|tyv|uk|uz|vo|wa|wen|wo|xh|yap|yi|yo|zu mfabian@magellan:~$ The only font left on my system supporting English is Code2000: mfabian@magellan:~$ fc-list :lang=en Code2000:style=Regular,Normal,oby?ejn?,Standard,????????,Normaali,Norm?l,Normale,Standaard,Normalny,???????,Normalan,Norm?lne,Navadno,th??ng,Arrunta mfabian@magellan:~$ mfabian@magellan:~$ fc-list code2000 file family lang /usr/X11R6/lib/X11/fonts/truetype/CODE2000.TTF: Code2000:lang=aa|ab|af|am|ar|ast|ava|ay|az|az-ir|ba|bam|be|bg|bh|bho|bi|bin|bn|br|bs|bua|ca|ce|ch|chm|chr|co|cs|cu|cv|cy|da|en|eo|et|eu|fa|fj|fo|fr|ful|fur|fy|ga|gd|gez|gl|gn|gu|gv|ha|haw|he|hi|ho|hr|hu|hy|ia|id|ie|ik|io|is|iu|ja|ka|kaa|ki|kk|kl|km|kn|ko|kok|ks|ku|ku-ir|kum|kv|kw|ky|la|lb|lez|lo|lt|lv|mg|mh|mi|mk|ml|mn|mr|mt|my|nb|nds|ne|nn|no|ny|oc|om|or|os|pa|pl|ps-af|ps-pk|rm|ru|sa|sah|sco|se|sel|sh|sk|sl|sma|smj|smn|sms|so|sq|sr|sv|sw|ta|te|tg|th|tk|tn|tr|ts|tt|tw|tyv|ug|uk|uz|vi|vo|vot|wa|wen|wo|xh|yap|yi|yo|zh-cn|zh-mo|zh-sg|zh-tw|zu mfabian@magellan:~$ That cannot be correct! -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
Patrick Lam
2006-Jan-30 20:11 UTC
[Fontconfig] Re: patch: fc-cache should not stop at the first non existing directory.
Mike FABIAN wrote:> Currently fc-cache stops at the first directory listed > in /etc/fonts/fonts.conf which doesn''t exist and does not > continue to created caches for the other directories which may exist. > > If for example "/usr/share/fonts" is the first directory in > /etc/fonts/fonts.conf and this directory doesn''t exist (move it out of > the way for testing), fc-cache immediately returns and says > "succeeded" although it didn''t create any caches. > > Patch attched.Looks good. I''ve committed it. pat
Patrick Lam
2006-Jan-30 23:17 UTC
[Fontconfig] Re: patch: destroy ~/.fonts.cache-2 if it doesn''t start with FC_GLOBAL_MAGIC_COOKIE or no string can be read at all from that file.
Mike FABIAN wrote:> I believe if FcGlobalCacheLoad () cannot read any string at all from > ~/.fonts.cache-2 or if the file does not start with > FC_GLOBAL_MAGIC_COOKIE it should exit with "goto bail_and_destroy;" to > delete the broken file instead of just "return;".Sounds good to me. fontconfig now toasts broken cache files. pat
Patrick Lam
2006-Jan-30 23:36 UTC
[Fontconfig] most fonts don''t support English anymore???
Mike FABIAN wrote:> Why is suddenly "en" missing in the "lang" output for fonts > like "Arial" and "FreeSans" which certainly support English?: > > mfabian@magellan:~$ fc-list "Arial:style=Regular" family file style lang > /usr/X11R6/lib/X11/fonts/truetype/arial.ttf: Arial:style=Regular,Normal,oby?ejn?,Standard,????????,Normaali,Norm?l,Normale,Standaard,Normalny,???????,Norm?lne,Navadno,th???ng,Arrunta:lang=aa|af|ar|ast|ava|ay|az|az-ir|be|bg|bi|bin|br|bua|ca|ce|ch|co|cs|cy|da|et|eu|fa|fj|fo|fr|fur|fy|gd|gl|gn|gv|he|ho|hu|ia|id|ie|ik|io|is|kaa|kk|kl|kum|ky|lb|lez|mg|mt|nb|nds|nn|no|oc|om|os|pl|rm|ru|se|sel|sh|sk|sma|smj|smn|so|sq|sr|sv|sw|tk|tn|tr|ts|tt|tyv|ug|uk|vo|wa|wen|wo|xh|yap|yi|zu > mfabian@magellan:~$ fc-list "FreeSans:style=Medium" family file style lang > /usr/X11R6/lib/X11/fonts/truetype/FreeSans.ttf: FreeSans:style=Medium,navadno:lang=aa|ab|af|ast|ava|ay|az|ba|bam|be|bg|bi|bin|bn|br|bs|bua|ca|ce|ch|chm|co|cs|cv|cy|da|eo|et|eu|fj|fo|fr|ful|fur|fy|ga|gd|gl|gn|gv|ha|haw|he|ho|hr|hu|hy|ia|id|ie|ik|io|is|kaa|ki|kk|kl|ku|kum|kv|kw|ky|la|lb|lez|lt|lv|mg|mh|mi|mk|mt|nb|nds|nn|no|ny|oc|om|os|pl|rm|ru|sah|sco|se|sel|sh|sk|sl|sma|smj|smn|so|sq|sr|sv|sw|syr|tg|tk|tn|tr|ts|tt|tyv|uk|uz|vo|wa|wen|wo|xh|yap|yi|yo|zu > mfabian@magellan:~$I can''t reproduce this. There might have been corrupted caches at some point? plam@plam:~/hacks/fontconfig$ fc-list "FreeSans:style=Medium" family file style lang /usr/share/fonts/truetype/freefont/FreeSans.ttf: FreeSans:style=Medium,navadno:lang=aa|af|ast|ava|ay|az|ba|bam|be|bg|bi|bin|bn|br|bs|bua|ca|ce|ch|chm|co|cs|cv|cy|da|de|el|en|eo|es|et|eu|fi|fj|fo|fr|ful|fur|fy|ga|gd|gl|gn|gv|ha|haw|he|ho|hr|hu|hy|ia|id|ie|ik|io|is|it|kaa|ki|kk|kl|ku|kum|kv|kw|ky|la|lb|lez|lt|lv|mg|mh|mi|mk|mt|nb|nds|nl|nn|no|ny|oc|om|os|pl|pt|rm|ru|sah|sco|se|sel|sh|sk|sl|sma|smj|smn|sms|so|sq|sr|sv|sw|syr|tg|tk|tn|tr|ts|tt|tw|tyv|uk|uz|vi|vo|vot|wa|wen|wo|xh|yap|yi|yo|zu pat
Mike FABIAN
2006-Jan-31 03:26 UTC
[Fontconfig] Re: most fonts don''t support English anymore???
Patrick Lam <plam@MIT.EDU> ????????:> Mike FABIAN wrote: >> Why is suddenly "en" missing in the "lang" output for fonts >> like "Arial" and "FreeSans" which certainly support English?: > > I can''t reproduce this. There might have been corrupted caches at > some point?I don''t think so because I can always reproduce it even after deleting all caches in /var/cache/fontconfig and ~/.fonts.cache-2. (CVS checkout from today). -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
Patrick Lam
2006-Jan-31 07:37 UTC
[Fontconfig] Re: most fonts don''t support English anymore???
Mike FABIAN wrote:> Patrick Lam <plam@MIT.EDU> ????????: > > >>Mike FABIAN wrote: >> >>>Why is suddenly "en" missing in the "lang" output for fonts >>>like "Arial" and "FreeSans" which certainly support English?: >> >>I can''t reproduce this. There might have been corrupted caches at >>some point? > > > I don''t think so because I can always reproduce it even > after deleting all caches in /var/cache/fontconfig and > ~/.fonts.cache-2. > > (CVS checkout from today).That''s strange. There aren''t fonts.cache-2 files lying around too? My fonts definitely still contain lang=en (among other things), and I haven''t touched any code that should affect lang at all. pat
Frederic Crozat
2006-Jan-31 08:17 UTC
[Fontconfig] Re: most fonts don''t support English anymore???
Le mardi 31 janvier 2006 ? 10:38 -0500, Patrick Lam a ?crit :> Mike FABIAN wrote: > > Patrick Lam <plam@MIT.EDU> ????????: > > > > > >>Mike FABIAN wrote: > >> > >>>Why is suddenly "en" missing in the "lang" output for fonts > >>>like "Arial" and "FreeSans" which certainly support English?: > >> > >>I can''t reproduce this. There might have been corrupted caches at > >>some point? > > > > > > I don''t think so because I can always reproduce it even > > after deleting all caches in /var/cache/fontconfig and > > ~/.fonts.cache-2. > > > > (CVS checkout from today). > > That''s strange. There aren''t fonts.cache-2 files lying around too? My > fonts definitely still contain lang=en (among other things), and I > haven''t touched any code that should affect lang at all.Hmm, I''ve just discovered current CVS is no longer removing fonts.cache-2 which were created outside /var/cache/fontconfig (ie old layout were files were created in the same directory where font are stored). It might be causing the cache oscillation.. -- Frederic Crozat <fcrozat@mandriva.com> Mandriva
Patrick Lam
2006-Feb-09 07:44 UTC
[Fontconfig] Re: most fonts don''t support English anymore???
Mike FABIAN wrote:> I found that this problem is a side effect of the attached > "euro.patch" which I apply to the SuSE fontconfig package to make sure > that default fonts for European languages (including English) always > have an Euro symbol. > > But this patch is trivial and I think correct, therefore there > are some severe bugs in code related to lang. > > Takashi Iwai <tiwai@suse.de> fixed the problem yesterday, > his patch (fc-lang-idx-fixes.diff) is attached.Ok, I changed the cache format so that it uses the same format as fc-lang generates. Please test the latest CVS version. I''m a bit worried, because both Takashi''s patch and what I committed seem to drop |en| from two fonts which *do* have the Euro symbol, Bitstream Charter and Courier 10 Pitch. It would be useful if someone could look into this; I don''t have time to do that right now. Reverting euro.patch brings these fonts back, so there''s probably still a bug in the charset handling somewhere. pat
Mike FABIAN
2006-Feb-10 03:32 UTC
[Fontconfig] Re: most fonts don''t support English anymore???
Patrick Lam <plam@MIT.EDU> ????????:> Ok, I changed the cache format so that it uses the same format as > fc-lang generates. Please test the latest CVS version.I''ll test today.> I''m a bit worried, because both Takashi''s patch and what I committed > seem to drop |en| from two fonts which *do* have the Euro symbol, > Bitstream Charter and Courier 10 Pitch.No, these fonts definitely do *not* have the Euro symbol. I have 2 versions of "Bitstream Charter" on my system, one is coming with Xorg, the other with Ghostscript: mfabian@magellan:~$ fc-list "Bitstream Charter:outline=true" file /usr/share/ghostscript/fonts/bchbi.pfa: /usr/X11R6/lib/X11/fonts/Type1/c0632bt_.pfb: /usr/share/ghostscript/fonts/bchri.pfa: /usr/X11R6/lib/X11/fonts/Type1/c0648bt_.pfb: /usr/X11R6/lib/X11/fonts/Type1/c0633bt_.pfb: /usr/X11R6/lib/X11/fonts/Type1/c0649bt_.pfb: /usr/share/ghostscript/fonts/bchr.pfa: /usr/share/ghostscript/fonts/bchb.pfa: mfabian@magellan:~$ The "Courier 10 pitch" is distributed with Xorg: mfabian@magellan:~$ fc-list "Courier 10 pitch:outline=true" file /usr/X11R6/lib/X11/fonts/Type1/c0582bt_.pfb: /usr/X11R6/lib/X11/fonts/Type1/c0611bt_.pfb: /usr/X11R6/lib/X11/fonts/Type1/c0419bt_.pfb: /usr/X11R6/lib/X11/fonts/Type1/c0583bt_.pfb: mfabian@magellan:~$ None of these has an Euro symbol. If you really have versions of these fonts with an Euro symbol, I''d like to know where you got them from because then I''d like to update the fonts in the SuSE distribution. I am not aware of any existing updates for these fonts. PS: for checking whether a font has a certain character or not, a new feature in fontconfig would be very useful. For example it would be nice to make fc-list :char=20AC,2019,038E-03E1 list all the fonts which have glyphs for the Unicode codepoints 20AC, 2019, and the complete range from 038E-03E1. If the urgent problems with fontconfig are fixed, maybe we can think about adding such a feature. -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
Mike FABIAN <mfabian@suse.de> ????????:> Patrick Lam <plam@MIT.EDU> ????????:>> I''m a bit worried, because both Takashi''s patch and what I committed >> seem to drop |en| from two fonts which *do* have the Euro symbol, >> Bitstream Charter and Courier 10 Pitch. > > No, these fonts definitely do *not* have the Euro symbol.While checking again whether these fonts have an Euro symbol, I noticed a bug with fc-match: mfabian@magellan:~$ fc-list "Bitstream Charter:style=Regular" file scalable outline /usr/X11R6/lib/X11/fonts/Type1/c0648bt_.pfb: :outline=True:scalable=True /usr/X11R6/lib/X11/fonts/75dpi/charR18.pcf.gz: :outline=False:scalable=False /usr/X11R6/lib/X11/fonts/75dpi/charR08.pcf.gz: :outline=False:scalable=False /usr/X11R6/lib/X11/fonts/75dpi/charR10.pcf.gz: :outline=False:scalable=False /usr/X11R6/lib/X11/fonts/75dpi/charR12.pcf.gz: :outline=False:scalable=False /usr/share/ghostscript/fonts/bchr.pfa: :outline=True:scalable=True /usr/X11R6/lib/X11/fonts/75dpi/charR14.pcf.gz: :outline=False:scalable=False /usr/X11R6/lib/X11/fonts/75dpi/charR24.pcf.gz: :outline=False:scalable=False mfabian@magellan:~$ I.e. there are both outline and bitmap versions of "Bitstream Charter" available. fc-list works fine, but trying to match the outline versions with fc-match doesn''t work, it always matches the bitmap versions: mfabian@magellan:~$ fc-match "Bitstream Charter:style=Regular:outline=true" charR12.pcf.gz: "Bitstream Charter" "Regular" mfabian@magellan:~$ fc-match "Bitstream Charter:style=Regular:scalable=true" charR12.pcf.gz: "Bitstream Charter" "Regular" mfabian@magellan:~$ This worked correctly with fontconfig-2.3.2.20050721: mike@nozomi:~$ fc-list "Bitstream Charter:style=Regular" file scalable outline /usr/X11R6/lib/X11/fonts/Type1/c0648bt_.pfb: :outline=True:scalable=True /usr/X11R6/lib/X11/fonts/75dpi/charR08.pcf.gz: :outline=False:scalable=False /usr/X11R6/lib/X11/fonts/75dpi/charR10.pcf.gz: :outline=False:scalable=False /usr/X11R6/lib/X11/fonts/75dpi/charR18.pcf.gz: :outline=False:scalable=False /usr/X11R6/lib/X11/fonts/URW/bchr.pfa: :outline=True:scalable=True /usr/X11R6/lib/X11/fonts/75dpi/charR12.pcf.gz: :outline=False:scalable=False /usr/X11R6/lib/X11/fonts/75dpi/charR14.pcf.gz: :outline=False:scalable=False /usr/X11R6/lib/X11/fonts/75dpi/charR24.pcf.gz: :outline=False:scalable=False mike@nozomi:~$ fc-match "Bitstream Charter:style=Regular:scalable=true" c0648bt_.pfb: "Bitstream Charter" "Regular" mike@nozomi:~$ fc-match "Bitstream Charter:style=Regular:outline=true" c0648bt_.pfb: "Bitstream Charter" "Regular" mike@nozomi:~$ rpm -q fontconfig fontconfig-2.3.2.20050721-10.3 mike@nozomi:~$ I.e. it seems to be a bug introduced recently in fontconfig. Anyway, neither the bitmap nor the outline versions have an Euro symbol. -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
Patrick Lam
2006-Feb-10 04:31 UTC
[Fontconfig] Re: most fonts don''t support English anymore???
Mike FABIAN wrote:> No, these fonts definitely do *not* have the Euro symbol. > > I have 2 versions of "Bitstream Charter" on my system, one > is coming with Xorg, the other with Ghostscript:Here''s my Bitstream Charter fonts: -rw-r--r-- 1 root root 33799 2006-01-14 20:31 /usr/X11R6/lib/X11/fonts/Type1/c0632bt_.pfb -rw-r--r-- 1 root root 34869 2006-01-14 20:31 /usr/X11R6/lib/X11/fonts/Type1/c0648bt_.pfb -rw-r--r-- 1 root root 35229 2006-01-14 20:31 /usr/X11R6/lib/X11/fonts/Type1/c0633bt_.pfb -rw-r--r-- 1 root root 35118 2006-01-14 20:31 /usr/X11R6/lib/X11/fonts/Type1/c0649bt_.pfb I thought that they had Euro because I loaded it in gucharmap and it showed an Euro symbol, but it must just be getting it from Sans or something sneaky like that.> PS: > for checking whether a font has a certain character or not, > a new feature in fontconfig would be very useful. For example > it would be nice to make > > fc-list :char=20AC,2019,038E-03E1 > > list all the fonts which have glyphs for the Unicode codepoints 20AC, > 2019, and the complete range from 038E-03E1. If the urgent problems > with fontconfig are fixed, maybe we can think about adding such a > feature.Yep, that would be useful too. Let''s see what urgent problems remain right now. Hopefully the set of urgent problems is decreasing. pat
Mike FABIAN wrote:> mfabian@magellan:~$ fc-list "Bitstream Charter:style=Regular" file scalable outline > /usr/X11R6/lib/X11/fonts/Type1/c0648bt_.pfb: :outline=True:scalable=True > /usr/X11R6/lib/X11/fonts/75dpi/charR18.pcf.gz: :outline=False:scalable=False > /usr/X11R6/lib/X11/fonts/75dpi/charR08.pcf.gz: :outline=False:scalable=False > /usr/X11R6/lib/X11/fonts/75dpi/charR10.pcf.gz: :outline=False:scalable=False > /usr/X11R6/lib/X11/fonts/75dpi/charR12.pcf.gz: :outline=False:scalable=False > /usr/share/ghostscript/fonts/bchr.pfa: :outline=True:scalable=True > /usr/X11R6/lib/X11/fonts/75dpi/charR14.pcf.gz: :outline=False:scalable=False > /usr/X11R6/lib/X11/fonts/75dpi/charR24.pcf.gz: :outline=False:scalable=False > mfabian@magellan:~$Hmm. I wonder why I only get one font in fc-list on two different systems: plam@mp:~/hacks/fontconfig$ fc-list/fc-list "Bitstream Charter:style=Regular" file scalable outline /usr/X11R6/lib/X11/fonts/Type1/c0648bt_.pfb: :outline=True:scalable=True Ah, charR12.pcf.gz is called ''Charter'' on my system: plam@mp:/etc/fonts$ fc-list "Charter:style=Regular" file scalable outline /usr/X11R6/lib/X11/fonts/100dpi/charR18.pcf.gz: :outline=False:scalable=False /usr/X11R6/lib/X11/fonts/100dpi/charR08.pcf.gz: :outline=False:scalable=False /usr/X11R6/lib/X11/fonts/100dpi/charR10.pcf.gz: :outline=False:scalable=False /usr/X11R6/lib/X11/fonts/100dpi/charR12.pcf.gz: :outline=False:scalable=False /usr/X11R6/lib/X11/fonts/100dpi/charR14.pcf.gz: :outline=False:scalable=False /usr/X11R6/lib/X11/fonts/100dpi/charR24.pcf.gz: :outline=False:scalable=False I''ll take a look at it. pat
Mike FABIAN wrote:> I.e. there are both outline and bitmap versions of "Bitstream Charter" > available. fc-list works fine, but trying to match the outline > versions with fc-match doesn''t work, it always matches the bitmap > versions:Hmm. It''s going to be hard for me to reproduce this bug because of what I just said. ''Bitstream Charter'' is scalable whereas ''Charter'' isn''t, so it''s not like they have the same name... I guess you could point me at a copy of the bitmap font called ''Bitstream Charter''. pat
Mike FABIAN
2006-Feb-10 05:08 UTC
[Fontconfig] Re: most fonts don''t support English anymore???
Patrick Lam <plam@MIT.EDU> ????????:> Mike FABIAN wrote: >> No, these fonts definitely do *not* have the Euro symbol. >> >> I have 2 versions of "Bitstream Charter" on my system, one >> is coming with Xorg, the other with Ghostscript: > > Here''s my Bitstream Charter fonts: > > -rw-r--r-- 1 root root 33799 2006-01-14 20:31 > /usr/X11R6/lib/X11/fonts/Type1/c0632bt_.pfb > -rw-r--r-- 1 root root 34869 2006-01-14 20:31 > /usr/X11R6/lib/X11/fonts/Type1/c0648bt_.pfb > -rw-r--r-- 1 root root 35229 2006-01-14 20:31 > /usr/X11R6/lib/X11/fonts/Type1/c0633bt_.pfb > -rw-r--r-- 1 root root 35118 2006-01-14 20:31 > /usr/X11R6/lib/X11/fonts/Type1/c0649bt_.pfb > > I thought that they had Euro because I loaded it in gucharmap and it > showed an Euro symbol, but it must just be getting it from Sans or > something sneaky like that.gucharmap is a GTK2 program and these are always searching for fallback fonts for every single glyph which cannot be displayed yet with the fonts already loaded. This is a very nice and useful feature because one almost never sees missing characters. But of course this makes gucharmap useless for checking whether a certain font has an Euro or not. If you grep for fonts in /proc/{pid}/maps for the pid of gucharmap, you will see that gucharmap loaded several fonts and not only "Bitstream Charter". For checking whether a font has a certain glyph I currently often use "xfd -fa" but then one also has to make sure that the correct font has really been opened (for example with FC_DEBUG). Another good way for checking is using a font editor like "fontforge". -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
Patrick Lam <plam@MIT.EDU> ????????:> Mike FABIAN wrote: >> mfabian@magellan:~$ fc-list "Bitstream Charter:style=Regular" file scalable outline >> /usr/X11R6/lib/X11/fonts/Type1/c0648bt_.pfb: :outline=True:scalable=True >> /usr/X11R6/lib/X11/fonts/75dpi/charR18.pcf.gz: :outline=False:scalable=False >> /usr/X11R6/lib/X11/fonts/75dpi/charR08.pcf.gz: :outline=False:scalable=False >> /usr/X11R6/lib/X11/fonts/75dpi/charR10.pcf.gz: :outline=False:scalable=False >> /usr/X11R6/lib/X11/fonts/75dpi/charR12.pcf.gz: :outline=False:scalable=False >> /usr/share/ghostscript/fonts/bchr.pfa: :outline=True:scalable=True >> /usr/X11R6/lib/X11/fonts/75dpi/charR14.pcf.gz: :outline=False:scalable=False >> /usr/X11R6/lib/X11/fonts/75dpi/charR24.pcf.gz: :outline=False:scalable=False >> mfabian@magellan:~$ > > Hmm. I wonder why I only get one font in fc-list on two different systems: > > plam@mp:~/hacks/fontconfig$ fc-list/fc-list "Bitstream > Charter:style=Regular" file scalable outline > /usr/X11R6/lib/X11/fonts/Type1/c0648bt_.pfb: :outline=True:scalable=True > > Ah, charR12.pcf.gz is called ''Charter'' on my system:Ah, yes. sorry. That difference in the names of the bitmap fonts is caused by a patch I apply to the freetype2 package in SuSE Linux. My patch prepends the foundry name plus a space to the family name in case of bitmap fonts. Without that, there are many fonts just called "Fixed" which look completely different and which have nothing to do with each other and when selecting "Fixed" in KDE or Gnome one gets results which appear rather random, the style changes often if one changes the size and one cannot select some fonts at all. With my patch, the fonts are called "Sony Fixed", "Misc Fixed", "ETL Fixed", ... Then they can be easily distinguished and the desired fonts can be selected without problems in KDE and Gnome.> plam@mp:/etc/fonts$ fc-list "Charter:style=Regular" file scalable > outline /usr/X11R6/lib/X11/fonts/100dpi/charR18.pcf.gz: > :outline=False:scalable=False > /usr/X11R6/lib/X11/fonts/100dpi/charR08.pcf.gz: > :outline=False:scalable=False > /usr/X11R6/lib/X11/fonts/100dpi/charR10.pcf.gz: > :outline=False:scalable=False > /usr/X11R6/lib/X11/fonts/100dpi/charR12.pcf.gz: > :outline=False:scalable=False > /usr/X11R6/lib/X11/fonts/100dpi/charR14.pcf.gz: > :outline=False:scalable=False > /usr/X11R6/lib/X11/fonts/100dpi/charR24.pcf.gz: > :outline=False:scalable=False > > I''ll take a look at it.Thank you. -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
Patrick Lam <plam@MIT.EDU> ????????:> Mike FABIAN wrote: >> I.e. there are both outline and bitmap versions of "Bitstream Charter" >> available. fc-list works fine, but trying to match the outline >> versions with fc-match doesn''t work, it always matches the bitmap >> versions: > > Hmm. It''s going to be hard for me to reproduce this bug because of what > I just said. ''Bitstream Charter'' is scalable whereas ''Charter'' isn''t, > so it''s not like they have the same name... > > I guess you could point me at a copy of the bitmap font called > ''Bitstream Charter''.If you like, you can try to apply my patch (attached) to your freetype 2. If not I can make an edited copy of one of these bitmap fonts for you which is already called "Bitstream Charter". -------------- next part -------------- A non-text attachment was scrubbed... Name: freetype2-bitmap-foundry.patch Type: text/x-patch Size: 1851 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20060210/de213be7/freetype2-bitmap-foundry-0001.bin -------------- next part -------------- -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
Mike FABIAN wrote:> I.e. there are both outline and bitmap versions of "Bitstream Charter" > available. fc-list works fine, but trying to match the outline > versions with fc-match doesn''t work, it always matches the bitmap > versions: > > mfabian@magellan:~$ fc-match "Bitstream Charter:style=Regular:outline=true" > charR12.pcf.gz: "Bitstream Charter" "Regular" > mfabian@magellan:~$ fc-match "Bitstream Charter:style=Regular:scalable=true" > charR12.pcf.gz: "Bitstream Charter" "Regular" > mfabian@magellan:~$Ok, here''s what I''ve discovered so far: * scalable=true isn''t recognized by fc-match as a matching criterion. (_FcMatchers in fcmatch.c:187 is the list of matchers) * FcDefaultSubstitute adds a bunch of criteria to the pattern which cause the outline version to be rejected. * The criterion which causes the outline version to be rejected is FC_PIXEL_SIZE. FcDefaultSubstitute notes that we don''t specify a pixelsize, so it computes one. (fcdefault.c lines 131-1515). Furthermore, FC_PIXEL_SIZE gets put before FC_OUTLINE, so that it eliminates the outline version before FC_OUTLINE can work. * Since the outline font doesn''t have an FC_PIXEL_SIZE element, then it doesn''t get the v = v * 100 + v1_offset, which causes it to have a lower score than the bitmap fonts, which is why it gets rejected. * The pattern elements are sorted to enable binary search on pattern elements, which is why pixelsize comes before outline. In fact, the matching pattern never has FcPatternGet called on it (it''s only accessed sequentially), so we don''t quite need to sort elements there, but that seems to enable a whole bunch of unsortedness bugs to come up. I don''t know what the correct solution to this problem is, but that''s what happening. Perhaps we shouldn''t sort patterns used for matching. pat
Takashi Iwai <tiwai@suse.de> ????????:> At Fri, 10 Feb 2006 11:58:33 -0500, > Patrick Lam wrote: >> >> Mike FABIAN wrote: >> >> > I.e. there are both outline and bitmap versions of "Bitstream Charter" >> > available. fc-list works fine, but trying to match the outline >> > versions with fc-match doesn''t work, it always matches the bitmap >> > versions:There is a similar problem with "spacing". It works fine when using "fc-list": mfabian@magellan:~$ fc-list :lang=fa:style=Regular:spacing=100 Courier New:style=Regular,Normal,oby?ejn?,Standard,????????,Normaali,Norm?l,Normale,Standaard,Normalny,???????,Norm?lne,Navadno,th???ng,Arrunta mfabian@magellan:~$ But it doesn''t work with fc-match: mfabian@magellan:~$ fc-match :lang=fa:style=Regular:spacing=100 arial.ttf: "Arial" "Regular" mfabian@magellan:~$ (should have matched "Courier New" here). -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
Mike FABIAN wrote:> There is a similar problem with "spacing". It works fine > when using "fc-list": > > mfabian@magellan:~$ fc-list :lang=fa:style=Regular:spacing=100 > Courier New:style=Regular,Normal,oby?ejn?,Standard,????????,Normaali,Norm?l,Normale,Standaard,Normalny,???????,Norm?lne,Navadno,th???ng,Arrunta > mfabian@magellan:~$In this case, the FcDefaultSubstitute is adding the following constraint: family: "Bitstream Vera Sans"(w) "Verdana"(w) "Arial"(w) "Albany AMT"(w) "Luxi Sans"(w) "Nimbus Sans L"(w) "Helvetica"(w) "Nachlieli"(w) "MgOpen Modata"(w) "FreeSans"(w) "Kochi Gothic"(w) "AR PL KaitiM GB"(w) "AR PL KaitiM Big5"(w) "?? ????"(w) "Baekmuk Dotum"(w) "SimSun"(w) "sans-serif"(w) "Roya"(w) "Koodak"(w) "Terafik"(w) This does not include "Courier New", but it does include "Arial". This does match: $ fc-match/fc-match ''Courier New'':lang=fa:style=Regular:spacing=100 Courier_New.ttf: "Courier New" "Regular" If you want Courier New to match that way, you''ll have to modify fonts.conf. But you probably shouldn''t, since it is trying to match a sans-serif font by default. If you try to match a monospace font... plam@fermat:~/hacks/fontconfig$ fc-match/fc-match monospace:lang=fa:style=Regular:spacing=100 Courier_New.ttf: "Courier New" "Regular" ... then it works as it should. (FC_DEBUG=3 helps when diagnosing these problems.) pat
Takashi Iwai <tiwai@suse.de> ????????:> At Fri, 10 Feb 2006 11:58:33 -0500, > Patrick Lam wrote: >> >> Ok, here''s what I''ve discovered so far: >> >> * scalable=true isn''t recognized by fc-match as a matching criterion. >> (_FcMatchers in fcmatch.c:187 is the list of matchers) >> >> * FcDefaultSubstitute adds a bunch of criteria to the pattern which >> cause the outline version to be rejected. >> >> * The criterion which causes the outline version to be rejected is >> FC_PIXEL_SIZE. FcDefaultSubstitute notes that we don''t specify a >> pixelsize, so it computes one. (fcdefault.c lines 131-1515). >> Furthermore, FC_PIXEL_SIZE gets put before FC_OUTLINE, so that it >> eliminates the outline version before FC_OUTLINE can work. >> >> * Since the outline font doesn''t have an FC_PIXEL_SIZE element, then it >> doesn''t get the v = v * 100 + v1_offset, which causes it to have a lower >> score than the bitmap fonts, which is why it gets rejected. >> >> * The pattern elements are sorted to enable binary search on pattern >> elements, which is why pixelsize comes before outline. In fact, the >> matching pattern never has FcPatternGet called on it (it''s only accessed >> sequentially), so we don''t quite need to sort elements there, but that >> seems to enable a whole bunch of unsortedness bugs to come up. >> >> I don''t know what the correct solution to this problem is, but that''s >> what happening. Perhaps we shouldn''t sort patterns used for matching. > > Stop blocking the fonts which have no corresponding elements. > The patch below should fix this problem. > > Takashi > > --- src/fcmatch.c-dist 2006-02-10 14:42:51.000000000 +0100 > +++ src/fcmatch.c 2006-02-10 17:55:00.000000000 +0100 > @@ -673,6 +673,10 @@ FcFontSetMatch (FcConfig *config, > } > } > > + /* We had no matching, just try the next one */ > + if (score == 1e99) > + continue; > + > /* If there''s a previous champion, and current score > * beats previous best score, on this element, then > * knock out the previous champion and anythingThis patch alone was not enough. It fixed the problem on Takashi''s machine, but not on my machine. Probably the reason was that the order of fonts in the cache files on Takashi''s machine and my machine was different, i.e. it just accidentally "fixed" the problem on Takashi''s machine. Takashi made a better patch, which is slightly more complicated. It is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: fc-fcmatch-pattern-fix.diff Type: text/x-patch Size: 2027 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20060210/d22f842f/fc-fcmatch-pattern-fix.bin -------------- next part -------------- -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
Patrick Lam <plam@MIT.EDU> ????????:> Mike FABIAN wrote: >> There is a similar problem with "spacing". It works fine >> when using "fc-list": >> >> mfabian@magellan:~$ fc-list :lang=fa:style=Regular:spacing=100 >> Courier New:style=Regular,Normal,oby?ejn?,Standard,????????,Normaali,Norm?l,Normale,Standaard,Normalny,???????,Norm?lne,Navadno,th???ng,Arrunta >> mfabian@magellan:~$ > > In this case, the FcDefaultSubstitute is adding the following constraint: > > family: "Bitstream Vera Sans"(w) "Verdana"(w) "Arial"(w) "Albany > AMT"(w) "Luxi Sans"(w) "Nimbus Sans L"(w) "Helvetica"(w) "Nachlieli"(w) > "MgOpen Modata"(w) "FreeSans"(w) "Kochi Gothic"(w) "AR PL KaitiM GB"(w) > "AR PL KaitiM Big5"(w) > "?? ????"(w) "Baekmuk Dotum"(w) "SimSun"(w) "sans-serif"(w) > "Roya"(w) "Koodak"(w) "Terafik"(w) > > This does not include "Courier New", but it does include "Arial". This > does match: > > $ fc-match/fc-match ''Courier New'':lang=fa:style=Regular:spacing=100 > Courier_New.ttf: "Courier New" "Regular" > > If you want Courier New to match that way, you''ll have to modify > fonts.conf. But you probably shouldn''t, since it is trying to match a > sans-serif font by default. If you try to match a monospace font... > > plam@fermat:~/hacks/fontconfig$ fc-match/fc-match > monospace:lang=fa:style=Regular:spacing=100 > Courier_New.ttf: "Courier New" "Regular" > > ... then it works as it should. > > (FC_DEBUG=3 helps when diagnosing these problems.)I see. Thank you very much for the explanation! Then it is probably a bug in the KDE konsole that it tries to find fallback fonts for languages not supported by the font selected in the setup by using some equivalent of "fc-match :lang=fa:spacing=100" instead of "fc-match monospace:lang=fa:spacing=100". Dirk, do you think so as well? -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
Mike FABIAN wrote:> Then it is probably a bug in the KDE konsole that it tries to find > fallback fonts for languages not supported by the font selected in the > setup by using some equivalent of "fc-match :lang=fa:spacing=100" > instead of "fc-match monospace:lang=fa:spacing=100". > > Dirk, do you think so as well?Well, you didn''t ask me, but I''m going to say that it is anyway. fonts.conf contains: <!-- If the font still has no generic name, add sans-serif --> <match target="pattern"> <test qual="all" name="family" compare="not_eq"> <string>sans-serif</string> </test> <test qual="all" name="family" compare="not_eq"> <string>serif</string> </test> <test qual="all" name="family" compare="not_eq"> <string>monospace</string> </test> <edit name="family" mode="append_last"> <string>sans-serif</string> </edit> </match> So :lang=fa:spacing=100 ought to mean a sans-serif font, all else being equal. If there''s some other reason to also prefer monospace, then it would take that, but sans-serif is the default. pat
Mike FABIAN wrote:> This patch alone was not enough. > > It fixed the problem on Takashi''s machine, but not on my machine. Probably > the reason was that the order of fonts in the cache files on Takashi''s > machine and my machine was different, i.e. it just accidentally > "fixed" the problem on Takashi''s machine. > > Takashi made a better patch, which is slightly more complicated.Yeah, Takashi''s initial patch fixed the problem on my machine too. Nevertheless, the new patch looks more likely to work (since the problem was already fixed on my machine), so I''ve committed it. pat
Mike FABIAN
2006-Feb-14 06:37 UTC
[Fontconfig] incompatible changes in cache format (was: most fonts don''t support English anymore???)
Patrick Lam <plam@MIT.EDU> ????????:> Mike FABIAN wrote: >> I found that this problem is a side effect of the attached >> "euro.patch" which I apply to the SuSE fontconfig package to make sure >> that default fonts for European languages (including English) always >> have an Euro symbol. >> >> But this patch is trivial and I think correct, therefore there >> are some severe bugs in code related to lang. >> >> Takashi Iwai <tiwai@suse.de> fixed the problem yesterday, >> his patch (fc-lang-idx-fixes.diff) is attached. > > Ok, I changed the cache format so that it uses the same format as > fc-lang generates. Please test the latest CVS version.Your change in the cache format causes crashes on systems where old caches are still around, i.e. it causes crashes after updating. GTK2 applications crash with a backtrace like this: The backtrace of a crash looks like below: #0 0xb7996fa7 in FcCharSetUnionLeaf (result=0xbf815494, al=0x5fd0742c, bl=0x810f1f0) at fccharset.c:509 #1 0xb7998ce1 in FcCharSetOperate (a=0xb744844c, b=0x810eb78, overlap=0xb7996f90 <FcCharSetUnionLeaf>, aonly=1, bonly=1) at fccharset.c:465 #2 0xb79a3623 in FcFontSetSort (config=0x80f9520, sets=0xbf8155dc, nsets=1, p=0x80f95a0, trim=1, csp=0x0, result=0xbf815754) at fcmatch.c:812 #3 0xb79a3984 in FcFontSort (config=0x810f1f0, p=0x80f95a0, trim=1, csp=0x0, result=0xbf815754) at fcmatch.c:1031 #4 0xb7b18198 in pango_fc_font_map_get_type () from /opt/gnome/lib/libpangoft2-1.0.so.0 #5 0xb7aec820 in pango_font_map_load_fontset () from /opt/gnome/lib/libpango-1.0.so.0 #6 0xb7aea83a in pango_context_get_font_description () from /opt/gnome/lib/libpango-1.0.so.0 #7 0xb7aeab82 in pango_itemize_with_base_dir () from /opt/gnome/lib/libpango-1.0.so.0 #8 0xb7af2afb in pango_layout_iter_get_char_extents () from /opt/gnome/lib/libpango-1.0.so.0 #9 0xb7af36cc in pango_layout_iter_get_char_extents () from /opt/gnome/lib/libpango-1.0.so.0 #10 0xb7d0f96d in gtk_label_new () from /opt/gnome/lib/libgtk-x11-2.0.so.0 similar crashes with similar backtraces happen with "fc-match -s sans", i.e. everything calling FcFontSort () crashes. The crashes can be "fixed" by calling "fc-cache -f -v" and removing all old ~/.fonts.cache-q files in the home directories of users. How to deal with such incompatible changes in cache files? Frederic Crozat wrote recently that he calls "fc-cache -f" in the post install script of his fontconfig RPM-package. But even that won''t be enough if old ~/.fonts.cache-2 files are still there. Either incompatible changes should never happen (probably not realistic) or fontconfig should somehow detect old cache files which are incompatible to the current version of fontconfig. fcint.h contains a magic number #define FC_CACHE_MAGIC 0xFC02FC02 which appears to be intended for that purpose. Maybe that number should be incremented with each incompatible change to invalidate old, incompatible cache files? I just tried that and it seems to work partly. fc-match sans generates a complete ~/.fonts.cache-2 file for all fonts in my system although the time stamps of the cache files in /var/cache/fontconfig appear to be OK. But fc-cache -v run as root doesn''t generate new caches in /var/cache/fontconfig, it just skips: mfabian@magellan:~$ sudo fc-cache -v fc-cache: "/usr/share/fonts": skipping, 0 fonts, 3 dirs [...] It skips very slowly though, it takes as much time for skipping as for generating new cache files, i.e. fontconfig seems to notice that there is something wrong with these caches. Nevertheless fc-cache doesn''t write new files unless called with "-f". After that, "fc-cache -v" skips fast again. Do you agree that FC_CACHE_MAGIC should be incremented with each incompatible change? If yes, we probably should fix these issues. -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
Mike FABIAN wrote:> Your change in the cache format causes crashes on systems where > old caches are still around, i.e. it causes crashes after updating.Yes, I bet it would. Ideally we wouldn''t change the cache format once fontconfig becomes stable. But I guess that''s not a very satisfactory answer, because we might have to change the cache format more than we might like. One option is to increment the cache version number (fonts.cache-3, etc).> fcint.h contains a magic number > > #define FC_CACHE_MAGIC 0xFC02FC02 > > which appears to be intended for that purpose.The magic number just helps determine that it''s a fontconfig cache, but I suppose it could be changed. The other thing is that there''s a line for determining architectures (by recording sizeof various things); this line could also have a version number incorporated into it. The question, I guess, is how often we''re going to have these incompatible changes. If it''s not very often, then we increment the filename number. If it''s going to be more often than that, we can change the magic number. I''m not really sure which is best.> fc-cache -v > > run as root doesn''t generate new caches in /var/cache/fontconfig, > it just skips: > > mfabian@magellan:~$ sudo fc-cache -v > fc-cache: "/usr/share/fonts": skipping, 0 fonts, 3 dirs > [...]That''s probably a straight out bug that ought to be fixed. I''ll take a 10-minute look at it today. pat
Mike FABIAN wrote:> run as root doesn''t generate new caches in /var/cache/fontconfig, > it just skips: > > mfabian@magellan:~$ sudo fc-cache -v > fc-cache: "/usr/share/fonts": skipping, 0 fonts, 3 dirs > [...] > > It skips very slowly though, it takes as much time for skipping as for > generating new cache files, i.e. fontconfig seems to notice that there > is something wrong with these caches. Nevertheless fc-cache doesn''t > write new files unless called with "-f". After that, "fc-cache -v" > skips fast again.It currently isn''t part of FcDirCacheValid or FcDirCacheCurrentArch''s contract to read in the cache file and determine if the cache has the correct MAGIC. However, it would seem to be trivial to add it to FcDirCacheCurrentArch, which should fix this problem. I''ll do that in a few minutes. Also, fc-cache has a sleep for 2 seconds, so that might be why it seems to be skipping slowly. fc-cache runs pretty quickly for me, except for the pause at the end. pat
Patrick Lam <plam@MIT.EDU> ????????:> Also, fc-cache has a sleep for 2 seconds, so that might be why it seems > to be skipping slowly. fc-cache runs pretty quickly for me, except for > the pause at the end.No, it was not only that pause at the end, it took much longer than 2 seconds for directories which have many fonts. -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
Patrick Lam <plam@MIT.EDU> ????????:> Ideally we wouldn''t change the cache format once fontconfig becomes > stable. But I guess that''s not a very satisfactory answer, because we > might have to change the cache format more than we might like. One > option is to increment the cache version number (fonts.cache-3, etc). > >> fcint.h contains a magic number >> >> #define FC_CACHE_MAGIC 0xFC02FC02 >> >> which appears to be intended for that purpose. > > The magic number just helps determine that it''s a fontconfig cache, but > I suppose it could be changed. The other thing is that there''s a line > for determining architectures (by recording sizeof various things); this > line could also have a version number incorporated into it. > > The question, I guess, is how often we''re going to have these > incompatible changes. If it''s not very often, then we increment the > filename number. If it''s going to be more often than that, we can > change the magic number. I''m not really sure which is best.Dirk M?ller <dmueller@suse.de> told me that incrementing the magic number might cause a problem if some 3rd party software vendors distribute applications which are statically linked against older versions of fontconfig. When calling such statically linked applications and "normal" applications alternately, the cache files will always be updated because the magic number is always wrong. Dirk had the idea that this could be avoided by having a version number in the architecture signature. You also wrote above that this is a possibility. Having the version number in the architecture signature might avoid the problem with applications statically linked against fontconfig because those would get their own architecture section. I don''t know whether applications linked statically against fontconfig exist, i.e. I don''t know whether this problem is important in practice or not. -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????