[texhax] PDF produced by pdflatex rejected by Lulu.com
Reinhard Kotucha
reinhard.kotucha at web.de
Fri Feb 10 23:15:20 CET 2012
On 2012-02-09 at 20:53:17 -0800, Donald Arseneau wrote:
> "Niall Mansfield" <texhax at uit.co.uk> writes:
>
>> We produced a book in PDF using pdflatex, and sent it to
>> Lulu.com to print a hardcopy proof.
>>
>> Days and days later (grrrrrrrrr) we got a message saying
>> they had a problem with the file and were refunding our
>> payment. The only information they provided was
>> "RIP error"
>> and
>> "It looks like there's an issue with the fonts in
>> your PDF."
>>
>> pdffonts says (below) that all fonts are embedded, so I
>> can't think what's wrong.
>>
>> Has anybody either:
>> a. successfully printed LaTeX documents with Lulu? or ...
>> b. had similar problems? Solutions?
>>
>> Thanks,
>> Niall Mansfield
>>
>> name type emb sub uni object ID
>> ------------------------------------ ----------------- --- --- --- ---------
>> NJKBOS+URWPalladioL-Roma Type 1 yes yes no 3 0
>> ZIBQYN+URWPalladioL-Bold Type 1 yes yes no 8 0
>> EEHSNB+URWPalladioL-Ital Type 1 yes yes no 19 0
>> TZDPKW+NimbusSanL-Bold Type 1 yes yes no 23 0
>> YMPRVZ+NimbusMonL-Regu Type 1 yes yes no 36 0
>> AHFKWD+NimbusSanL-ReguCond Type 1 yes yes no 52 0
>> OWTLWS+URWPalladioL-BoldItal Type 1 yes yes no 106 0
>> PalatinoLinotypeItalic CID TrueType yes no yes 127 0
>> GillSans CID TrueType yes no yes 132 0
>> PalatinoLinotypeItalic CID TrueType yes no yes 143 0
>> GillSans CID TrueType yes no yes 148 0
>
>
> Could the problem be the duplicate PalatinoLinotypeItalic and GillSans?
BTW, these duplicate entries are harmless but can confuse some
programs though. I encountered such problems when running pdfsizeopt
on the VnTeX font sample files. Further investigation showed that
if pdffonts lists different objects for the same font, these objects
don't contain the font file itself but references to a font file and
an encoding vector.
This happens, for instance, if a font file contains Roman and Small
Caps and both are used in a document. pdfTeX inserts each font only
once but needs different encodings in order to access all glyphs.
This is correct behavior and compliant with the PDF specification.
Obviously pdffonts doesn't follow the link to the actual font. It
would then notice that both links point to the same font-file object.
As far as pdfsizeopt is concerned, what I don't understand is why it
rejects only some of such files complaining about duplicate fonts,
while its author, Peter Szabó, could compile all files from
http://vntex.sf.net/fonts/samples
seamlessly on his laptop at EuroTeX 2009 [1].
Anyway, all other programs (PDF viewers and to-PostScript converters)
I'm aware of, even xpdf itself (from which pdffonts is derived), find
the actual fonts and produce proper output.
And regarding Lulu.com, I'm wondering how one can bother users with
such a stupid and useless error message:
>> "It looks like there's an issue with the fonts in your PDF."
It's foreseeable that the hotline runs hot. Looks like a self made
denial-of-service attack. Do they still respond to mails? I can't
imagine. I'm also wondering how a machine which is only aware of ones
and zeroes can provide an error message containing "It looks like
there's an issue with ...". Is it that what people call "fuzzy logic"
or is it a first attempt to support what's called "artificial
intelligence"? Or do they simply use trinary logic, supporting the
states "true", "false", and "dontknow"?
[1] http://pdfsizeopt.googlecode.com/files/pts_pdfsizeopt2009.psom.pdf
Regards,
Reinhard
--
----------------------------------------------------------------------------
Reinhard Kotucha Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover mailto:reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------
More information about the texhax
mailing list