#58 Font-dependent bug in "Type2 Charstring Parser"

[<unknown>]

XeTeX fails to render a file depending on the font used, crashing with the message further on. This happens e.g. when using "Zapfino Extra LT Pro", but not with "Zapfino Extra LT One" (or Two/Three/Four).

("C:\Program Files\MiKTeX 2.9\tex\generic\oberdiek\se-ascii-print.def")
[1]
** WARNING ** "seac" character deprecated in Type 2 charstring.
** ERROR ** Type2 Charstring Parser: Parsing charstring failed: (status=-1, stack=5)

Output file removed.
)

[<unknown>]

Corresponding logfile.

[<unknown>]

Further research revealed the following report dating back to 2006 (!):

http://www.tug.org/pipermail/xetex/2006-June/004136.html

If this is still correct, the problem seems to lie in XeTeX's driver for PDF conversion being slightly too strict in not implementing deprecated OTF-features.

[<unknown>]

COPY OF http://www.tug.org/pipermail/xetex/2006-June/004136.html:
***********************
Pablo Rodríguez oinos at web.de
Sun Jun 18 21:37:26 CEST 2006:

When I try to generate a rather big PDF file with the original GFS Didot
font, I get an error and the end of the process.

** WARNING ** "seac" character deprecated in Type 2 charstring.
** ERROR ** Type2 Charstring Parser: Parsing charstring failed:
(status=-1, stack=5)
Output file removed.

The problem is that the GFS fonts use the endchar operator for
generating the composite characters.

The issue is that the endchar command for OpenType fonts is deprecated
and because of that it isn't implemented in (x)dvipdfmx.

Since the endchar operator for composite characters in OpenType CFF
fonts could to be very similar to the seac operator in Type1 fonts, it
could be easy to implement it. I don't code, but there may be an
explanation of the seac/endchar for Type2 fonts at
http://partners.adobe.com/public/developer/en/font/5177.Type2.pdf.

I hope it helps,
Pablo
***********************