Menu

#98 decorative initials from EBGaramondInitials.pfb invisible

Future
pending
None
5
2014-08-28
2014-07-27
karl berry
No

Bob Tennent reported a bug in dvipdfmx at http://tug.org/pipermail/tex-live/2014-June/035580.html, where the letter L is not typeset from the EBGaramondInitials.pfb font. Akira replied saying that dvipdfmx did work with the .otf; but of course it's still a bug.

I reduced Bob's example to this plain TeX file, say tryeb.tex:

\special{pdf:mapline EBGaramondInitials-tlf-ly1--base EBGaramondInitials <EBGaramondInitials.pfb}
\font\i = EBGaramondInitials-tlf-ly1--base at 30pt \i L \nopagenumbers \end

Then tex tryeb.tex; dvipdfmx tryeb.dvi.

That is, we're just typesetting the L (which does exist in the font). dvipdfmx does not report any error, but the L is not visible in the output (although the L shows up in the output from pdftotext). The PDF resulting from both pdftex and tex|dvips|ps2pdf looks fine.

Both the dvipdfmx from TL14 and the one from current TL sources have the same behavior.

Looking at the PDF output file, the only immediately visible difference is that the dvipdfmx PDF uses /WinAnsiEncoding. However, when I fudged the source to avoid that (added && 0 in pdfencoding.c:436), the L was still invisible in the output.

The L fails to show up with other EBGaramondInitials*.tfm files (not surprisingly), but does show up with non-Initials fonts from EBGaramond (not surprisingly). Something about that one particular pfb, and even more specifically the "decorative" characters in that font. The "X" is a non-decorative character (I don't know why), and it shows up fine; but A and L (didn't try others) fail.

None of the "pdftype"-like programs I know about (using -z 0 to dvipdfmx, pdfinflt.ps from Ghostscript, pdftex pdf inclusion without compression, separately or in combination) manage to fully disassemble the Type 1 in the pdf, in the sense of t1disasm. (If you know about alternative "pdftype"s, I'd be very very grateful to hear.) Of course, it may well be something about the PDF per se, and not the Type 1(-subsetting) inclusion that is happening, I don't know, that's just the avenue I was pursuing.

I've run out of time before my trip to go farther, so I thought I'd report it now.

Discussion

  • Khaled Hosny

    Khaled Hosny - 2014-07-28

    Something about the complexity of those glyphs causes dvipdfmx to produce invalid Type1 charstrings. If I open the PDF in FontForge it will load the font but give a lot of warnings about the L glyph and its shape is distorted.

     
  • Khaled Hosny

    Khaled Hosny - 2014-08-28

    Fixed in TeX Live.

     
  • Khaled Hosny

    Khaled Hosny - 2014-08-28
    • status: open --> pending
     

Anonymous
Anonymous

Add attachments
Cancel