on 25 Feb 1999 14:39:30 +0000,
PS>> either use the old unicode->cp1252 table, or to use the non
PS>> unicode table that Windows use ("cmap 3" or something like that;
JC> I believe you're wrong.
I'm sure I was.
JC> Microsoft defines 2 cmaps for non-Ideographic scripts: (3,0), which
JC> is used with Symbol fonts, and (3,1), which stands for Unicode.
There must be another one.
I have plenty of TTF fonts that have some glyphs that are not referenced
in the unicode internal table; yet on Windows they show up at the right
ttfdump ArmNH.ttf (an armenian font) shows two things:
glyphIdArray = 3
glyphIdArray = 4
glyphIdArray = 5
glyphIdArray = 6
Char 0x0020 -> Index 3
Char 0x0021 -> Index 4
Char 0x0022 -> Index 5
Char 0x0023 -> Index 6
Char 0x0024 -> Index 7
Char 0x0025 -> Index 8
The second list is the table that for each unicode char shows a glyph;
but some glyphs are indexed there.
I wonder if Windows doesn't use simply the table built whith "glyphIdArray"
I have experienced that it is as if a 'static' table is enclosed on
the True Type fonts, and Windows generally use it (when not using unicode);
using unicode table a greater number of glyphs are available; but sometimes
not all, that is some are not accessible that were accessbile using the
JC> The only difference between `old' and `new' CP-1252 is whether or not
JC> the three new glyphs (including the Euro sign) are assigned. I don't
JC> think that there is any reason to use the `old' mapping,
Of course there is, and that is the reason I asked you to have a
*-microsoft-fontspecific to handle that (the better being trough the
"static table"): most non cp1252 cheapo fonts claim themselves to be cp1252
(that chould be the default the font maker programs put inside the file);
using the new cp1252 encoding brokes a big lot of the vietnamese, thai,
hebrew, armenian, etc. fonts out there.
The problem is that using the new cp1252 encoding allmost all the cheap
TTF fonts out there will be screwed; the solution will be to allows to
use the "static table", but I haven't enough knowledge of True Type internals
to explain it better.
JC> as older
JC> fonts are not likely to contain the new glyphs, and xfsft will silen-
JC> tly ignore mappings to an undefined glyph.
But then a blank glyph will be used instead; that is indeed a problem,
that can make a text difficult to read and the font almost unusable.
JC> (Yes, that's the issue we
JC> already had an occasion to disagree about in the past.)
Maybe I expressed incorrectly myself...
Using the new encoding trough unicode matching for *-microsoft-cp1252 is right;
but there should be a way to use the "default static table" whithout using
unicode, so the ordering will allways be the same, independently of the
changes Microsoft can do in cp1252; and I would like
to use *-microsoft-fontspecific for it.
Using 'ttfdump ArmNH.ttf' and ftview I see that the glyph for symbol
Armeternity (a wheel looking like a flower) is at position 107 (glyph 107
tells ftview); in the output of ttfdump I see:
glyphIdArray = 107
which makes sense, the char Armeternity is at position 0xA1 in Armscii-8
encoding. now if I search for glyph 107 in the unicode table I see it nowhere.
all others armenian letters show on both glyphIdArray lines and unicode
JC>  A `cmap' is a TrueType data structure that maps character codes to
JC> glyphs. Cmaps are identified by a couple of small integers (pid, eid),
JC> where `pid' identifies the platform, and `eid' the encoding for plat-
JC> forms that have more than one; pid=3 stands for Microsoft.
BTW, the line "glyphIdArray = 107" shows in cmap 1,0 which according
to the freetype *.h files is:
#define TT_PLATFORM_MACINTOSH 1
#define TT_MAC_ID_ROMAN 0
... and now I realize that 1,0 doesn't use unicode at all (only (3,1), (2,1)
and (0,*) use unicode).
Could it be that Windows uses the macintosh encoding table (1,0) ?
Or maybe uses it to complete (3,1) when there are holes ?
I have no access to a Windows machine to do testing; but now I think that
what I wanted was use of that cmap 1,0 table; only that it wouldn't be
very correct to call it *-microsoft-fontspecific :)
How can xfsft be instructed to use that macintosh encoding ?
Pablo Saratxaga PGP Key available, key ID: 0x8F0E4975