XeTeX error, no PDF

[Stephen Moye]

I have been using XeTeX 0.997 (on a Mac G5 DP) without any problems to speak of -- until tonight.

I typeset a file and got this error message:

This is XeTeXk, Version 3.141592-2.2-0.997 (Web2C 7.5.6)
%&-line parsing enabled.
entering extended mode
(./Hanover-new.tex [2] [3]
Output file removed.
)
Error 256 (driver return code) generating output;
file Hanover-new.pdf may not be valid.
Transcript written on Hanover-new.log.

%%%%%

This file uses a fmt file that I have regenerated. The file uses Hoefler Text. Oh, and I just upgraded to Leopard.

Other similar files are OK -- there are just a handful that show this problem.

Where do I start looking for problems?

Thanks for any help.


Stephen Moye

[James Crippen]

Post by Stephen Moye
I have been using XeTeX 0.997 (on a Mac G5 DP) without any problems to speak of -- until tonight.
This is XeTeXk, Version 3.141592-2.2-0.997 (Web2C 7.5.6)
%&-line parsing enabled.
entering extended mode
(./Hanover-new.tex [2] [3]
Output file removed.
)
Error 256 (driver return code) generating output;
file Hanover-new.pdf may not be valid.
Transcript written on Hanover-new.log.
%%%%%
This file uses a fmt file that I have regenerated. The file uses Hoefler Text. Oh, and I just upgraded to Leopard.
Other similar files are OK -- there are just a handful that show this problem.
Where do I start looking for problems?

This appears to be command line output from XeTeX. Start by reading
through the .log file, since much more information is available in
there. I'm not sure what the error might be, but I recall a similar
situation which was caused by broken glyphs in a font I was using.

James

[Jonathan Kew]

Happy New Year!

Post by Stephen Moye
I have been using XeTeX 0.997 (on a Mac G5 DP) without any problems
to speak of -- until tonight.
This is XeTeXk, Version 3.141592-2.2-0.997 (Web2C 7.5.6)
%&-line parsing enabled.
entering extended mode
(./Hanover-new.tex [2] [3]
Output file removed.
)
Error 256 (driver return code) generating output;
file Hanover-new.pdf may not be valid.
Transcript written on Hanover-new.log.
%%%%%
This file uses a fmt file that I have regenerated. The file uses
Hoefler Text. Oh, and I just upgraded to Leopard.

This is a failure in xdvipdfmx, the output driver. I'm guessing it is
a Leopard font issue of some kind -- there seem to be a number of
these. To try and narrow it down, the first thing to try is to run
the driver with "verbose" messages:

xetex -no-pdf Hanover-new.tex
xdvipdfmx -E -vv Hanover-new.xdv

I'm predicting that the xetex run will go fine, but xdvipdfmx will
give some kind of error message relating to a particular font.

One workaround might be to use the old xdv2pdf driver instead of
xdvipdfmx:

xetex -output-driver=xdv2pdf Hanover-new.tex

But I'd like to know what's causing the failure with xdvipdfmx, so
please try that with -vv and let us know what it reports.

JK

[Stephen Moye]

Post by Jonathan Kew
xdvipdfmx -E -vv Hanover-new.xdv

Below is the output from the commands that you provided. I was puzzled
by the line:

** ERROR ** Only RGB/CMYK/Gray currently supported.

because I have never used anything else except RGB/CMYK/Gray. Odd.

Yes,

-output-driver=xdv2pdf

works perfectly.

Thanks for the help.

And a very Happy New Year to you as well!


Stephen Moye


%%======8><-------%%

8:49 singnew% xdvipdfmx -E -vv Hanover-new.xdv
DVI Comment: XeTeX output 2008.01.01:0849
Hanover-new.xdv -> Hanover-new.pdf
<AGL:texglyphlist.txt>[1<HoeflerText-Black(Hoefler
Text:Black)@10.42pt<NATIVE-FONTMAP:HoeflerText-Black/H>
fontmap: HoeflerText-Black/H -> HoeflerText-Black/H(Identity-H)

pdf_font>> Input encoding "Identity-H" requires at least 2 bytes.
pdf_font>> The -m <00> option will be assumed for "HoeflerText-Black/H".
(CID:HoeflerText-Black)
pdf_font>> Type0 font "HoeflerText-Black/H" cmap_id=<Identity-H,0>
opened at font_id=<HoeflerText-Black/H,0>.
fontmap: HoeflerText-Black/H -> HoeflerText-Black/H(Identity-H)
[map:<00>]
(CID:HoeflerText-Black)
pdf_font>> Type0 font "HoeflerText-Black/H" cmap_id=<Identity-H,0>
opened at font_id=<HoeflerText-Black/H,1>.
FONTMAP:HoeflerText-Regular/H>
fontmap: HoeflerText-Regular/H -> HoeflerText-Regular/H(Identity-H)

pdf_font>> Input encoding "Identity-H" requires at least 2 bytes.
pdf_font>> The -m <00> option will be assumed for "HoeflerText-Regular/
H".
(CID:HoeflerText-Regular)
pdf_font>> Type0 font "HoeflerText-Regular/H" cmap_id=<Identity-H,0>
opened at font_id=<HoeflerText-Regular/H,2>.
tfm/public/cm/cmex10.tfm])
fontmap: cmex10 -> cmex10[remap]

pdf_font>> Simple font "cmex10" enc_id=<builtin,-1> opened at
font_id=<cmex10,3>.
fontmap: HoeflerText-Regular/H -> HoeflerText-Regular/H(Identity-H)
[map:<00>]
(CID:HoeflerText-Regular)
pdf_font>> Type0 font "HoeflerText-Regular/H" cmap_id=<Identity-H,0>
opened at font_id=<HoeflerText-Regular/H,4>.
** WARNING ** Unparsed material at end of special ignored.

Current input buffer is -->\relax <--

** WARNING ** Unparsed material at end of special ignored.

Current input buffer is -->\relax <--

** WARNING ** Unparsed material at end of special ignored.

Current input buffer is -->\relax <--

** WARNING ** Unparsed material at end of special ignored.

Current input buffer is -->\relax <--

** WARNING ** Unparsed material at end of special ignored.

Current input buffer is -->\relax <--

** WARNING ** Unparsed material at end of special ignored.

Current input buffer is -->\relax <--

** WARNING ** Unparsed material at end of special ignored.

Current input buffer is -->\relax <--

** WARNING ** Unparsed material at end of special ignored.

Current input buffer is -->\relax <--
<HoeflerText-Italic(Hoefler Text:Italic)@6.95pt<NATIVE-
FONTMAP:HoeflerText-Italic/H>
fontmap: HoeflerText-Italic/H -> HoeflerText-Italic/H(Identity-H)

pdf_font>> Input encoding "Identity-H" requires at least 2 bytes.
pdf_font>> The -m <00> option will be assumed for "HoeflerText-Italic/
H".
(CID:HoeflerText-Italic)
pdf_font>> Type0 font "HoeflerText-Italic/H" cmap_id=<Identity-H,0>
opened at font_id=<HoeflerText-Italic/H,5>.
** WARNING ** Unparsed material at end of special ignored.

Current input buffer is -->\relax <--

** WARNING ** Unparsed material at end of special ignored.

Current input buffer is -->\relax <--

** WARNING ** Unparsed material at end of special ignored.

Current input buffer is -->\relax <--

** WARNING ** Unparsed material at end of special ignored.

Current input buffer is -->\relax <--

** WARNING ** Unparsed material at end of special ignored.

Current input buffer is -->\relax <--

** WARNING ** Unparsed material at end of special ignored.

Current input buffer is -->\relax <--

** WARNING ** Unparsed material at end of special ignored.

Current input buffer is -->\relax <--

** WARNING ** Unparsed material at end of special ignored.

Current input buffer is -->\relax <--

** WARNING ** Unparsed material at end of special ignored.

Current input buffer is -->\relax <--

** WARNING ** Unparsed material at end of special ignored.

Current input buffer is -->\relax <--

** WARNING ** Unparsed material at end of special ignored.

Current input buffer is -->\relax <--

** WARNING ** Unparsed material at end of special ignored.

Current input buffer is -->\relax <--
]
** ERROR ** Only RGB/CMYK/Gray currently supported.

Output file removed.
8:50 singnew%

[Stephen Moye]

I just noticed, having switched to xdv2pdf, that I'm getting an
'<Error>: WARNING:' message:

This is XeTeXk, Version 3.141592-2.2-0.997 (Web2C 7.5.6)
%&-line parsing enabled.
entering extended mode
(./Monaco-new.tex
Overfull \hbox (9.57358pt too wide) in paragraph at lines 154--154
[]\sm 1) The last ruler of Monaco to descend patrilineally from the
Grimaldi fa
mily was Princess Louise-Hippolyte |
[1]Tue Jan 1 10:08:54 stephen-moyes-power-mac-g5.local xdv2pdf[484]
<Error>: WARNING: Type1 font data returned by OFAStreamPSDownload
isn't in the correct format required by the Adobe Type 1Font Format
specification.
)
(see the transcript file for additional information)
Output written on Monaco-new.pdf (1 page).
Transcript written on Monaco-new.log.

%%=====8><-----%%

I have not noticed this in the past I think. Again, as far as I know
the only typeface I'm using in these files is Hoefler Text. In spite
of the warning, things seem to be coming out correctly.

Thanks again.


Stephen Moye

[Peter Dyballa]

Post by Stephen Moye
<Error>: WARNING: Type1 font data returned by OFAStreamPSDownload
isn't in the correct format required by the Adobe Type 1Font Format
specification.

You should not need to care about these messages. They come on a
quite regular basis, at least on Tiger. The output, i.e. the
PostScript Type 1 font converted to OpenType format, seems to be OK.
FontForge accepts them, otfinfo rejects them ("not an OpenType font
(bad magic number)"), and Linotype FontExplorer X says they're not
Mac OS X compatible.

--
Greetings

Pete === -Q
==<__/% >>
_____________(_)***@_____________________________

[Stephen Moye]

Post by Peter Dyballa

Post by Stephen Moye
<Error>: WARNING: Type1 font data returned by OFAStreamPSDownload
isn't in the correct format required by the Adobe Type 1Font Format
specification.

You should not need to care about these messages. They come on a
quite regular basis, at least on Tiger. The output, i.e. the
PostScript Type 1 font converted to OpenType format, seems to be OK.
FontForge accepts them, otfinfo rejects them ("not an OpenType font
(bad magic number)"), and Linotype FontExplorer X says they're not
Mac OS X compatible.

I'm not sure that I understand. According to Linotype FontExplorer X:

Name: Hoefler Text
Family name: Hoefler Text
PostScript name: HoeflerText-Regular
Style: Regular
Unique name: Hoefler Text; 5.0d7e2; Mon. Mar 7, 2005
Format: TrueType
Format (detailed): Data-Fork Suitcase (TrueType)
Path: /Library/Fonts/Hoefler Text.dfont
Version: 5.0d7e2
Copyright: © 1992-1999 Apple Computer, Inc.
Embedding rights: Preview & Print embedding allowed
Trademark: Hoefler Text is a trademark of Apple Computer, Inc.
Vendor: Unknown
Font ID: 2013
Activated: by system
Last activated: Unknown
Import date: 7/9/07
My Rating: 0 stars
Label: None
Contained in: • Library
• Active fonts (Smart Set)

Hoefler Text seems to be TrueType, and a standard Mac OS X .dfont.

And I don't understand your reference to a conversion to OpenType
format.


Stephen Moye

[Stephen Moye]

Oops -- my bad. I completely forgot that I am using the Lucida Bright
math fonts to generate horizontal brackets. Those are, no doubt the
Type 1 fonts that are causing the problems.

Sorry for the misunderstanding.


Stephen Moye

Post by Stephen Moye

Post by Peter Dyballa

Post by Stephen Moye
<Error>: WARNING: Type1 font data returned by OFAStreamPSDownload
isn't in the correct format required by the Adobe Type 1Font Format
specification.

You should not need to care about these messages. They come on a
quite regular basis, at least on Tiger. The output, i.e. the
PostScript Type 1 font converted to OpenType format, seems to be OK.
FontForge accepts them, otfinfo rejects them ("not an OpenType font
(bad magic number)"), and Linotype FontExplorer X says they're not
Mac OS X compatible.

Name: Hoefler Text
Family name: Hoefler Text
PostScript name: HoeflerText-Regular
Style: Regular
Unique name: Hoefler Text; 5.0d7e2; Mon. Mar 7, 2005
Format: TrueType
Format (detailed): Data-Fork Suitcase (TrueType)
Path: /Library/Fonts/Hoefler Text.dfont
Version: 5.0d7e2
Copyright: © 1992-1999 Apple Computer, Inc.
Embedding rights: Preview & Print embedding allowed
Trademark: Hoefler Text is a trademark of Apple Computer, Inc.
Vendor: Unknown
Font ID: 2013
Activated: by system
Last activated: Unknown
Import date: 7/9/07
My Rating: 0 stars
Label: None
Contained in: • Library
• Active fonts (Smart Set)
Hoefler Text seems to be TrueType, and a standard Mac OS X .dfont.
And I don't understand your reference to a conversion to OpenType
format.
Stephen Moye
_______________________________________________
XeTeX mailing list
http://tug.org/mailman/listinfo/xetex

[Peter Dyballa]

Post by Stephen Moye
I completely forgot that I am using the Lucida Bright
math fonts to generate horizontal brackets. Those are, no doubt the
Type 1 fonts that are causing the problems.

This conversion can also happen when XeTeX fails to find one of the
document's fonts. As a fall-back XeTeX then chooses the TeX CM fonts,
which you probably have in PostScript Type 1 form installed. At least
this is my interpretation why CM fonts get converted. Their dates
correspond with the dates when such failures occurred.

--
Greetings

Pete

Time is an illusion. Lunchtime, doubly so.

[Jonathan Kew]

Post by Stephen Moye

Post by Jonathan Kew
xdvipdfmx -E -vv Hanover-new.xdv

Below is the output from the commands that you provided. I was puzzled
** ERROR ** Only RGB/CMYK/Gray currently supported.
because I have never used anything else except RGB/CMYK/Gray. Odd.

This is coming from some kind of color-related \special command that
the driver is not understanding correctly. If you can't see what's
wrong with your \specials (perhaps they're not even in your code, but
coming from some macro package), then please send me a complete (but
minimal) example that shows this problem, and I'll try to figure out
what's broken.

Thanks,

JK

[Stephen Moye]

Post by Jonathan Kew

Post by Stephen Moye

Post by Jonathan Kew
xdvipdfmx -E -vv Hanover-new.xdv

Below is the output from the commands that you provided. I was puzzled
** ERROR ** Only RGB/CMYK/Gray currently supported.
because I have never used anything else except RGB/CMYK/Gray. Odd.

This is coming from some kind of color-related \special command that
the driver is not understanding correctly. If you can't see what's
wrong with your \specials (perhaps they're not even in your code, but
coming from some macro package), then please send me a complete (but
minimal) example that shows this problem, and I'll try to figure out
what's broken.

That's the odd thing. This is a plain TeX project, and the only
\special-s are:

\def\dogray{\special{color gray .6}}
\def\undogray{\special{color gray 0}}

Odder, is that some files compile perfectly (using 0.997/xdvipdfmx)
while others do not.

Originally, I had \relax in the commands:

\def\dogray{\special{color gray .6\relax}}
\def\undogray{\special{color gray 0\relax}}

but have since removed them. The problem persists -- most files
typeset, while a handful do not.


Stephen Moye

[Jonathan Kew]

Post by Stephen Moye
This is a plain TeX project, and the only
\def\dogray{\special{color gray .6}}
\def\undogray{\special{color gray 0}}
Odder, is that some files compile perfectly (using 0.997/xdvipdfmx)
while others do not.
\def\dogray{\special{color gray .6\relax}}
\def\undogray{\special{color gray 0\relax}}
but have since removed them. The problem persists -- most files
typeset, while a handful do not.

You definitely don't want \relax in specials like this. Yes, it's
sometimes useful to unambiguously terminate numbers that TeX will be
scanning, but these numbers are within the \special, and aren't
scanned by TeX at all, only passed on to the driver. So \relax there
is meaningless, and will lead to warning messages from xdvipdfmx.

I seem to recall a bug in xdvipdfmx where trailing spaces in color
specials could cause problems; that has been fixed, I think (see
xdvipdfmx rev. 98, committed on October 24th), but if you have an
older build then maybe that's the source of your troubles?

Otherwise, I'd still be interested in seeing a complete sample that
fails, if possible.

JK