Very Computer

-Dan

xfsft version 1.0.3
XFree86 version 3.2
latest wine version

-- Remove the OUCH- to email me
-----------------------------------------------------------------------------

DM> I've got the true type font server [xfsft] happily serving the
DM> correct fonts up, but some characters, notably a ', which is
DM> character \222 (it sits right under "r" in xfontsel) is missing.

ISO 8859-1 does not have an assignment at position 0222, so xfsft does
the right thing.  Microsoft CP-1252 does assign this position to a
forward single quote.

DM> Is it because the encodings maps don't have that character?

The ISO 8859-1 encoding map does not have this assignment.  The
CP-1252 map does.  You will need to tell the font backend that you
want your fonts in CP-1252, not in ISO 8859-1.

Make sure that you have properly installed the supplementary xfsft
encodings (in the `encodings.tar' tarball).  In your `fonts.scale'
file, add a set of entries such as

  arial.ttf -monotype-arial-medium-r-normal--0-0-0-0-p-0-microsoft-cp1252

and then rebuild the `fonts.dir' file (run `mkfontdir').  `kill -USR1'
the font server (or restart it) and the `*-microsoft-cp1252' fonts
should be available.

DM> xfsft version 1.0.3

You should be all right, this is supported since version 1.0.2.

DM> why can't a font simply export all of its characters under X
DM> without having to specify them beforehand?

A TrueType font may contain tens of thousands of glyphs; the Microsoft
`WGL4' fonts contain over 400.  A TrueType backend for a window system
must do some work to present them under a well defined encoding; it
wouldn't make sense to just present them in the order in which they
appear in the font file.

You may use the `ftview' utility to view all the glyphs in a font
file.

Good luck,

                                        J.

[Followups to c.o.l.x]

Why doesn't ttmkfdir do this?

Bob T.

 DM> many true type fonts. I've got the true type font server happily
 DM> serving the correct fonts up, but some characters, notably a ', which
 DM> is character \222 (it sits right under "r" in xfontsel) is missing.
 DM>   However, when I look at the same font under windows with "charmap.exe",
 DM> the correct character is where it should be.

So you see it whith some programs and not whith others...
A possible reason would be that the ones where you see it simply use
its position in the font (0x92) which is ok for the X11 font system
(as long as you export the font whith that glyph at the right place; which
is done whith xfsft and xtt if you use a name like *-microsoft-cp1252);
and that the programs where you don't see it call the glyph by its unicode
value (U+2019).
I think even if you export fonts in unicode encoding wine can't yet make use
of them.

 DM> If so then why can't a font simply export
 DM> all of its characters under X without having to specify them beforehand?

Because Unix is multi-user, and so two different users can have the need to
use different languages using different encodings; it is impossible to
assume and force a unique font encoding as it is done on Windows.

--
bient?t,
Pablo Saratxaga           PGP Key available, key ID: 0x8F0E4975

http://www.ping.be/~pin19314/

  To followup what I wrote before, using the "*-microsoft-cp1252" setting,
*most* of the characters show up properly, but not all unfortunately. I've
spent a long time with this and I can't figure out what the problem is.
Micro$oft must export fonts in a subtle way that wine doesn't.
  Perhaps the problem is that wine isn't aware of different encodings?
It seems to only use the first encoding it finds.

-Dan

 h>   To followup what I wrote before, using the "*-microsoft-cp1252" setting,
 h> *most* of the characters show up properly, but not all unfortunately. I've
 h> spent a long time with this and I can't figure out what the problem is.
 h> Micro$oft must export fonts in a subtle way that wine doesn't.

Could they be 0x80, 0x8e, 0x9e ?

In fact Microsoft has the bad habit of changing an encoding whithout
changing its name :-(
There is old and new cp1252.

 h> Perhaps the problem is that wine isn't aware of different encodings?
 h> It seems to only use the first encoding it finds.

Wine isn't aware of anything; it is up to the font server to deal whith
that. The font server uses the TTF enclosed unicode->glyph table, and then
a cp1252->unicode table provided in the font server; that table uses the
new cp1252 encoding; while the unicode values inside the TTF file seems
to use the old cp1252 encoding...
The TTF files have also a table that doesn't use unicode, and that
Windows can use to display the font; that table has the drawback that only
255 glyphs at max are accessible; that makes it very bad for the X11 font
servers, as they prefer to use unicode so all the glyphs are accessible,
in particular a font whith cyrillic, latin, greek etc letters can be used
in all iso-8859-* and koi8-* encodings; not just only one.
Of course that is based on the trust of the encoding tables; if Microsoft
decides to change an encoding table and still keep the same name for it
it's not the font server fault.

You can maybe search for microsoft-cp1252.enc file if you use xfsft, then
comment out lines 0x80, 0x8e, 0x9e.

--
bient?t,
Pablo Saratxaga           PGP Key available, key ID: 0x8F0E4975

http://www.ping.be/~pin19314/

Quote:>Could they be 0x80, 0x8e, 0x9e ?
>In fact Microsoft has the bad habit of changing an encoding whithout
>changing its name :-(
>There is old and new cp1252.

Quote:>The TTF files have also a table that doesn't use unicode, and that
>Windows can use to display the font; that table has the drawback that only
>255 glyphs at max are accessible; that makes it very bad for the X11 font

Quote:>You can maybe search for microsoft-cp1252.enc file if you use xfsft, then
>comment out lines 0x80, 0x8e, 0x9e.

-Dan

Quote:>>The TTF files have also a table that doesn't use unicode, and that
>>Windows can use to display the font; that table has the drawback that only
>>255 glyphs at max are accessible; that makes it very bad for the X11 font

"*-truetype-raw" is not that ! "*-truetype-raw" is the *whole* font (very
probably much more than 255 glyphs), whith possibly duplicate ones etc.
It is only useful to see what is inside the font, not for pratical
purposes.

Note also that Wine looks for only a limited set of meaningful X11
globbing names, eg "*-microsoft-cp1252", "*-microsoft-fontspecific",
"*-iso8859-1" and "*-microsoft-symbol" are the only ones you should
use.

What you would need is to change the encoding definition (I think that
xfsft allows you to do that on a per-directory basis) to either use the
old unicode->cp1252 table, or to use the non unicode table that Windows
use ("cmap 3" or something like that; but I really don't remember;
look at the xfsft documentation).

--
bient?t,
Pablo Saratxaga           PGP Key available, key ID: 0x8F0E4975

http://www.ping.be/~pin19314/

PS> What you would need is to change the encoding definition (I think
PS> that xfsft allows you to do that on a per-directory basis) to
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;
PS> but I really don't remember; look at the xfsft documentation).

I believe you're wrong.

Microsoft defines 2 cmaps[1] for non-Ideographic scripts: (3,0), which
is used with Symbol fonts, and (3,1), which stands for Unicode.  Text
fonts always use the (3,1) cmap, whether under 3.1 or NT.  Weird
things happen under Windows if a text font attempts to use the (3,0)
cmap; the (3,0) cmap is generally weird, or perhaps just badly docu-
mented.

The only difference between `old' and `new' CP-1252 is whether or not
the three new glyphs (including the Euro sign) are assigned.  I don't
think that there is any reason to use the `old' mapping, as older
fonts are not likely to contain the new glyphs, and xfsft will silen-
tly ignore mappings to an undefined glyph.  (Yes, that's the issue we
already had an occasion to disagree about in the past.)

Sincerely,

                                        J.

[1] A `cmap' is a TrueType data structure that maps character codes to
glyphs.  Cmaps are identified by a couple of small integers (pid, eid),
where `pid' identifies the platform, and `eid' the encoding for plat-
forms that have more than one; pid=3 stands for Microsoft.

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[1] 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
place.

ttfdump ArmNH.ttf (an armenian font) shows two things:

                 glyphIdArray[0] =  3
                 glyphIdArray[1] =  4
                 glyphIdArray[2] =  5
                 glyphIdArray[3] =  6
.... etc
then:

                Char 0x0020 -> Index 3
                Char 0x0021 -> Index 4
                Char 0x0022 -> Index 5
                Char 0x0023 -> Index 6
                Char 0x0024 -> Index 7
                Char 0x0025 -> Index 8
....etc

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"
lines.

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
"static table".

 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[161] =  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
lines.

 JC> [1] 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[161] =  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 ?

Thanks.

--
bient?t,
Pablo Saratxaga           PGP Key available, key ID: 0x8F0E4975

http://www.ping.be/~pin19314/

  Thanks for all of the help - now I have another one! Changing the
codepage to the "old" one seemed to fix it, now my normal fonts
all work correctly. The problem is with the Symbol fonts.
  I'm specifying them as "microsoft-symbol", but its not mapping
all of the characters. Where is the microsoft-symbol encoding,
is it defaulted inside the font server?

-Dan

PS> Could it be that Windows uses the macintosh encoding table (1,0)?

It would surprise me somewhat.

PS> Or maybe uses it to complete (3,1) when there are holes?

Did you take into account that CP-1252 has more assignments than ISO
8859-1?  The holes you are seing might be filled in with the
supplementary assignments of CP-1252.

PS> I think that what I wanted was use of that cmap 1,0 table;

PS> How can xfsft be instructed to use that macintosh encoding ?

  `*-apple-roman'

You may also define your own mapping to the Apple Roman encoding by
defining an encoding file with target `cmap 1 0'.

                                        J.

[Followups restricted]