[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with ~ and ^
> OK, I have a problem. The documents, when converted to PDF via
> ghostscript 5.94, have blanks for ligatures like fi, fl, and copyright
> symbols. I have seen this before, and it usually has to do with some
> improper encoding. It looks fine when the PS file is viewed.
>
> Any ideas? I was really starting to like LY1 too.
Yes, this is a "acroread does not implement the pdf standard" problem.
It was fixed in gs beta 5.97. At least, it now works for me.
See the quoted mail from the gs beta/pdf dev
lists for further explanation.
-------- Original Message --------
Subject: Ghostscript vs. Acrobat Reader quirks [2]
Date: Sun, 21 Nov 1999 09:56:28 -0800
From: "L. Peter Deutsch" <ghost@aladdin.com>
Reply-To: ghost@aladdin.com
To: pdfdev@lists.pdfzone.com
Dear fellow PDF developers, Ghostscript pre-release testers, and others:
Thanks very much for your comments regarding the problems of producing
Acrobat-compatible PDF output.
To my astonishment, an hour after I sent the previous message, I found what
appears to be the final key to producing output that Acrobat will read
reliably (in addition to the workarounds for the 7 other apparent problems):
Ensure that no two fonts in the output file have the same FontName.
There is, of course, nothing in the PDF specification that states or even
implies that this is a requirement; in fact, the specification may even say
at some point that because fonts are always accessed through the resource
dictionary mechanism, their FontNames don't matter. Nevertheless, the above
made the difference for both AR3 and 4.
Font subsetting seems to work OK, as long as no two fonts have the same name
even when one ignores the XXXXXX+ prefix. (I.e., one can't have two
different subsets of the same font in a single file.)
Fortunately, none of the workarounds (including the above) require doing
things contrary to the PDF specification: they all involve avoiding things
that the specification says are legal (and that work on the Ghostscript and
xpdf interpreters).
Several of you suggested taking these problems up with Adobe. I've been
having friendly discussions with Adobe all along about improving the
published PDF specification, and they are taking the issue very seriously.
Their practice on specifications seems to be to make major improvements
infrequently rather than minor fixes more frequently, so I think it may be a
while before we see results.
One person suggested defining a "truly portable PDF (subset)" that would
work on all implementations, including AR. I agree that this is important.
If Adobe is thorough about documenting, in an appendix to a future revision
of the PDF specification, the various Acrobat problems that I and others
have found and reported to them, I think that will serve the purpose. Adobe
is more likely to do this if they hear from more people requesting it.
> If you're talking here about bugs that are clearly Adobe's, shouldn't you
> "disown" those bugs and go about your release? The best you can do about
> Adobe's bugs is report them to Adobe and hope that they get some attention
> in the next maintenance upgrade of Acrobat. Isn't that much true?
Unfortunately, a Ghostscript that produces PDF output that AR can't read is
not a realistically useful alternative to Acrobat Distiller. AR is an
important part of the de facto definition of "legal PDF" (as, at this point,
are the Ghostscript/G*view/gv and xpdf readers). As Aandi put it, that
would amount to "the operation was a success but the patient died".
> I may be misreading this but it sounds like the "read errors" involve some
> situations that are not likely to be encountered frequently by most
> Ghostscript users. Am I wrong here? What would be a "typical" example of a
> problem?
The file that has been my nemesis through the entire process is a technical
manual produced by dvips 5.78. It uses a mix of Computer Modern, standard
PostScript (Courier and New Century Schoolbook), and other (embedded Type 1)
fonts. Among other things, it defines and uses multiple embedded fonts
named "Arial" (and this despite the fact that the name Arial doesn't even
appear in the DSC DocumentFonts list), literally dozens of them in the
course of the document, often multiple times on a single page, and they
aren't all the same. With this file, if Ghostscript doesn't use unique font
names, AR drops characters all over the place, and mis-positions them in
enough places to notice.
This file is a pretty severe example, but it isn't that far out of line.
Most of the other problems have to do with either character re-encoding or
TrueType font embedding. The latter seems to be characteristic of the
AdobePS Windows drivers, so Ghostscript has to handle it. In this area,
some of the problems are with the TrueType spec, not the PDF spec, but
fortunately (so far) I haven't run into anything I couldn't avoid pretty
easily.
Thanks again for your supportive comments. PDF is an important open
standard, and while Adobe understands that and is willing to put resources
into making/keeping it so, I think episodes like this help "keep them
honest".
BTW, more testers of Ghostscript's ps2pdf facility are always welcome.
Please see http://www.cs.wisc.edu/~ghost/aladdin/tester.html for details.
But please wait a few days for the 5.97 beta fileset, which will have the
above fix, before doing any testing.
--
L. Peter Deutsch | Aladdin Enterprises
ghost@aladdin.com | http://www.aladdin.com | 203 Santa Margarita Ave.
+1-650-322-0103 (9-12 M-F) | fax +1-650-322-1734 | Menlo Park, CA 94025
Open Source is the future of software: http://www.opensource.org
-------- Original Message --------
--
Karsten Tinnefeld tinnefeld@ls2.cs.uni-dortmund.de
Fachbereich Informatik, Lehrstuhl 2 T +49 231 755-4737
Universität Dortmund, D-44221 Dortmund, Deutschland F +49 231 755-2047