pdftex + truetype + reencoding : more

[Philip A. Viton]

This may be right: in my case, the Kinch versions of the cm TTF fonts are
"registered" with Windows, though not in the \fonts directory (and in fact
the TTFONTS entry in texmf.cnf doesn't refer to the windows directory at
all). 

On the other hand, the Bakoma version isn't either registered or in the
\fonts directory; and it still has the missing-ligs problem (in this case I
insert the full path to the font file in the .map file entry).  But since
the Bakoma font has the same fontname as the Kinch font, maybe Kinch is
taking precedence?

Is there any reason why TTFs couldn't be treated essentially the way pfb
fonts are treated - ie ignoring windows registration completely? After all,
all one wants to do is to insert the encoding vector plus (parts of) the
binary into the  .pdf file.


At 11:47 PM 12/17/98 +1100, you wrote:
>
>
>"Philip A. Viton" wrote:
>> 
>> I've done a bit of experimenting here, and it looks to me as if the
encoding
>> vector is not being handled properly for TT fonts (WinNT4; AcroReader3.01;
>> pdftex 12r):
>> 
>> a. with the relevant line of cm.map reading
>> 
>>     cmr10 Cmr10 <<cmr10.ttf <cmtext.enc
>> 
>>    the pdf document shows no ligs; fhe File/DocInfo/Fonts listing shows
>>    cmr10 as a truetype font with encoding "builtin", which is surely wrong?
>> 
>> b. this is not specific to the Kinch version of the tt fonts: the tt
>> version of the Bakoma fonts have the same problem.
>> 
>> c. for comparison, using a pfb version of cmr10, the ligs display
correctly;
>>    under Font Info the encoding is listed as "custom".
>> 
>> So if the TT version lists the encoding as "builtin", while PFB shows
>> "custom" maybe that's the source of the problem?  (Or maybe I don't
>> understand encodings?)
>> 
>> At 03:24 PM 12/15/98 -0500, you wrote:
>> >
>> >Can anyone confirm whether pdftex 12r correctly re-encodes true-type (TT)
>> >fonts? I'm using the system with the TT fonts from Kinch (TrueTeX) and
>> >can't get the cmr ligatures to display.
>> >
>> >pdftex finds the TT fonts and the encoding vector cmtext.enc; but the
>> >ligatures show up as empty boxes. processing the test file through pdftex
>> >with \pdfoutput=0 gives the correct results, if that's any help.
>> >
>> >Also, the message about pdftex at cstug refers to  the file enc-note from
>> >Petr Oslak - this doesn't seem to be on the system, or did I miss it?
>> >
>> >Philip A. Viton
>> >------------------
>> >City Planning, Ohio State University
>> >viton.1 at osu.edu
>> >
>> >
>> >
>
>I have found that the BaKoMa ttf versions of the cm fonts work fairly
>well, almost all glyphs displaying correctly, PROVIDED that the fonts
>are
>not "installed" on my system. i.e. if the ttf files are not in 
>my Windows\fonts directory, then it's OK. When the ttf files are in the
>Windows\fonts directory then the glyphs in positions 0 to 31 don't
>display properly with acrobat reader 3.01. With ghostview, however,
>everything is OK whether or not the fonts are installed. So it's my
>belief that the problem is with acrobat reader, not pdftex, and I
>eagerly await acrobat 4.0.
>
>Actually, at present I'm seeing a problem with emdash's appearing
>where endash's should, and vice versa. I remember having this problem
>with some other true-type fonts a while ago, and so it's possible that
>I changed something and forgot to change it back. But I'd be interested
>to know if you witness this phenomenon.
>
>The cm ttf fonts work better than most other ttf fonts that I've tried,
>but probably only because they only have glyphs in positions 0 to 127.
>With other ttf fonts I generally find a handful of glyphs in positions
>128 to 255 not displaying correctly. I believe that Thanh has spent a
>lot of time trying to fix it, but again I believe that it's a bug
>in acrobat reader that's the problem. Things are usually better
>with GSview.
>
>Bob Howlett
>
>
>


------------------------
Philip A. Viton
City Planning, Ohio State University
190 W. 17th Ave,Columbus OH 43210
viton.1 at osu.edu