[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Font code page issues
From:       James Abbatiello <abbeyj () WPI ! EDU>
Date:       2000-09-28 19:13:02
[Download RAW message or body]

Recent changes have resulted in some fonts appearing rather oddly for
me.  Most of my X fonts are iso8859-1, which gets mapped to codepage
28591.  With the recent addition of 

	if ( pfi->codepage != GetACP() )
	    penalty += 0x200;

in graphics/x11drv/xfont.c, these fonts all get penalized (GetACP()
returns codepage 1252).  This might not have posed a problem, except
that I also have a few iso646.1991-irv fonts around.  These get mapped
to codepage 1252, and are thus getting chosen in preference to the
iso8859-1 fonts.  This seems wrong to me as iso8859-1 is a lot closer to
cp1252 than iso646.1991-irv is.  

I'm unclear on the solution.  Fuzzy match between pfi->codepage and
GetACP()?  Mapping iso646.1991-irv to something other than cp1252
(cp437??)?  Seeing as this is a minor cosmetic thing, I could just live
with it...

On a related note, every time I get my font metrics cache rebuilt, I get
a couple of pages of fixme's from LFD_InitFontInfo like
fixme:font:LFD_InitFontInfo font
'-dec-terminal-bold-r-normal--14-140-75-75-c-80-dec-dectech' has unknown
registry 'dec' and character encoding 'dectech'

The dec-dectech encoding is described somewhat
(http://sunsite.org.uk/packages/kermit/charsets/dectech.c and
http://sunsite.org.uk/packages/kermit/charsets/dectech.txt), but it
doesn't map to any codepage that wine knows about.  And there doesn't
seem to be any info about it on unicode.org.  So I could add another
SuffixCharset entry for this, but I'm left with the same problem as
above in that I don't know what codepage is appropriate.  Are we going
to ignore fonts in cases like this?  If so, can we silence the fixmes?


-- 
James Abbatiello

[prev in list] [next in list] [prev in thread] [next in thread]