State of the art on PDF-to-Postscript conversion?
rpresser
doesn't speak PDF, and boss is unwilling to buy the upgrade for a
machine that is literally decades old. It usually does a nice job with
Postscript, but not always. One of the problems seems to be that it
cannot digest TrueType fonts, even if embedded, unless they are also
converted to Type 1; pdftops cannot do this conversion. As is well
known, ghostscript's pswrite driver produces large, unweildy postscript
that always turns Truetype fonts to bitmap fonts. I've experimented
with Ghostscript's new ps2write driver, but it fails also; a fairly
long exchange with the developers through a bug report left me without
a useful solution.
http://bugs.ghostscript.com/show_bug.cgi?id=688475
That leaves Acrobat in its various incarnations. When the manufacturer
provided Windows printer driver for the 92c is used with Acrobat 7.0
Reader, printing to a file, the Postscript is smaller than either
pdftops or pdf2ps and runs fine (with a few exceptions dealing with
embedded images that can be worked around). So using Acrobat is the
trick.
The best method I've found so far is not fully automatic. The Windows
printer is set up, pointed at a regular lpr port, and paused. Then, I
drag each of the several pdfs to be printed into the printer window.
Acrobat Reader is launched for each one and it sends the document to
the printer; the .SPL files in C:\WINDOWS\SYSTEM32\SPOOL\PRINTERS
actually contain the postscript, which can then be renamed and moved
where I wish. Cancelling all pending print jobs finishes the task.
For automating, I've tried the AcroRd32.exe /P option; the DDE option;
and using the Windows Shell "print" verb option. The problem with all
three seems to be that there's no way to tell when Acrobat is done
printing the file; and if a new file is queued too soon, it may get
lost. The "print" verb option comes closest to doing the right thing
there; as long as I delay a few seconds between queuing, the Windows
shell seems to handle the queue ok, and only loses maybe one in twelve
documents being queued. OK if you don't mind babying it, but not
perfect.
I do have a copy of Acrobat Professional 6.0 available, but not on my
development machine. This site
http://www.tgreer.com/printforum/archive/index.php/t-213.html
talks about what you can do with Acrobat Professional 7.0, .NET and
Javascript; I'd love to try that out, they'd probably let me buy a
copy.
Are there any other good solutions known?
Hans-Werner Hilse
On 10 Aug 2006 06:51:36 -0700 "rpresser" <rpre...@gmail.com> wrote:
> For automating, I've tried the AcroRd32.exe /P option; the DDE option;
> and using the Windows Shell "print" verb option. The problem with all
> three seems to be that there's no way to tell when Acrobat is done
> printing the file; and if a new file is queued too soon, it may get
> lost.
Hm? Is your print spool broken? Anyway, if you intend to wait until the
print spool is empty, just poll the spool...
> Are there any other good solutions known?
Did you try xpdf (i.e. its "pdftops" command line tool)?
-hwh
Helge Blischke
You should try the pdftops utility of the xpdf suite (make sure to use the latest
version, it is 3.01, I think) and force level2 output (by command line option
or configuration file; see the man pages).
Perhaps you could post an URL to a sample PDF to look into?
Helge
--
Helge Blischke
Softwareentwicklung
SRZ Berlin | Firmengruppe besscom
http://www.srz.de
rpresser
I mentioned in my original post that my Xerox does not like postscript
output with Truetype fonts embedded, and that xpdf/pdftops cannot
convert to Type 1. To expand on that a bit, the only choices are to
embed or not embed. Embedding gives postscript that blows up. Not
embedding gives postscript that prints with fonts substituted.
rpresser
Helge Blischke wrote:
> rpresser wrote:
> > One of the problems seems to be that it
> > cannot digest TrueType fonts, even if embedded, unless they are also
> > converted to Type 1; pdftops cannot do this conversion.
>
> version, it is 3.01, I think) and force level2 output (by command line option
> or configuration file; see the man pages).
Please see above. pdftops has been tried and found wanting. A shame; I
love it for most other purposes.
> Perhaps you could post an URL to a sample PDF to look into?
If you insist. http://member.newsguy.com/~rpresser/sample.zip contains
a sample PDF, and the postscript generated by the Xerox 92c print
driver.
chicks
rpresser wrote:
> For automating, I've tried the AcroRd32.exe /P option; the DDE option;
> and using the Windows Shell "print" verb option. The problem with all
> three seems to be that there's no way to tell when Acrobat is done
> printing the file; and if a new file is queued too soon, it may get
> lost.
>
Try pdfp here: http://www.esnips.com/web/PDFTools
It uses the DDE interface, and will wait for Acrobat/Reader to finish
spooling before submitting the next PDF for printing.
rpresser
Hans-Werner Hilse wrote:
> Hi,
>
> On 10 Aug 2006 06:51:36 -0700 "rpresser" <rpre...@gmail.com> wrote:
>
> > For automating, I've tried the AcroRd32.exe /P option; the DDE option;
> > and using the Windows Shell "print" verb option. The problem with all
> > three seems to be that there's no way to tell when Acrobat is done
> > printing the file; and if a new file is queued too soon, it may get
> > lost.
>
> Hm? Is your print spool broken? Anyway, if you intend to wait until the
> print spool is empty, just poll the spool...
My print spool is definitely not broken; I get the same behavior on a
range of machines. And if you have any advice on how to "poll the
spool", I'm all ears.
rpresser
Thanks for including the source; this may help.
Richard Owlett
Not Found
The requested URL /~rpresser/sample.zip was not found on this server.
Apache/1.3.34 Server at member.newsguy.com Port 80
rpresser
rpresser wrote:
> If you insist. http://member.newsguy.com/~rpresser/sample.zip contains
> a sample PDF, and the postscript generated by the Xerox 92c print
> driver.
Sorry; the correct URL is
http://member.newsguy.com/~rpresser/files/sample.zip
Hans-Werner Hilse
On 10 Aug 2006 08:28:49 -0700 "rpresser" <rpre...@gmail.com> wrote:
> My print spool is definitely not broken; I get the same behavior on a
> range of machines.
OK, that's now listed on my private list "why I don't like windoze" :-)
> And if you have any advice on how to "poll the spool", I'm all ears.
My XP installation has a script
c:\windows\system32\prnjobs.vbs
that does this.
-hwh
rpresser
Whoa, now that's cool. Thank you.
Chris Mattern
Well, yes. Your printer that can't print TrueType fonts...can't
print TrueType fonts. This is not a matter of PDF-to-PostScript
conversion and is not really something you can fix on the fly.
Your printer is going to have to use Type 1 fonts. You can a) find
ones you have that are acceptible b) try converting your TrueType
fonts with something like Fontforge or c) buy ones that are
acceptible.
Chris Mattern
rpresser
Ridiculous. If that were so, then why does Acrobat Reader have *NO*
trouble generating perfectly digestible postscript from the SAME pdf?
An excerpt from the middle of one of those postscript files clearly
shows what's going on:
userdict /pdf_svglb currentglobal put true setglobal
%ADOBeginSubsetFont: QADBAA+ArialMT Initial
%ADOt1write: (1.0.24)
%%Copyright: Copyright 2006 Adobe System Incorporated. All rights
reserved.
12 dict dup begin
/FontType 1 def
/FontName /QADBAA+ArialMT def
/FontInfo 6 dict dup begin
/ItalicAngle 0 def
/OrigFontType /TrueType def
/WasEmbedded true def
end def
/PaintType 0 def
/FontMatrix [0.001 0 0 0.001 0 0] def
Do you not see "/FontType 1" and "/OrigFontType /TrueType" ?
I take the point, that this on-the-fly font conversion magic is part
of my Xerox 92c printer driver, not duplicated in pdftops. Or,
perhaps, that pdftops does provide the magic, but for whatever reason,
the postscript commands it uses are indigestible by my
not-quite-compliant printer. I can accept that explanation.
But the fact remains that I cannot use pdftops, as was suggested to me,
whereas I can use Acrobat Reader.
Helge Blischke
Well, what the printer driver supplied to the output is only the Xerox
job ticket (the %XRX... lines). You must be aware that Acrobat and Adobe Reader
generate their own PostScript when printing to a PostScript printer (and pass it
to the output using the printer driver's "write-through" capability. The
TrueType to Type1 conversion is a specific feature of Acrobet or Reader,
respectively.
To get things more transparent, yould you please provide the following:
- The OS version of the Sun box which acts as the controller for your
Xerox printer (DocuPrint 92C, I suppose?);
- The PPD you use for your printer (on the XP box, you'll find it
in:
C:\EINDOWS\system32\spool\drivers\w32x86\3\yourprinter.ppd
Perhaps I could give you some hints to solve the issue or at least hack
a workaround.
rpresser
Helge Blischke wrote:
> rpresser wrote:
> > of my Xerox 92c printer driver, not duplicated in pdftops. Or,
> > perhaps, that pdftops does provide the magic, but for whatever reason,
> > the postscript commands it uses are indigestible by my
> > not-quite-compliant printer. I can accept that explanation.
> >
> > But the fact remains that I cannot use pdftops, as was suggested to me,
> > whereas I can use Acrobat Reader.
> >
>
> Well, what the printer driver supplied to the output is only the Xerox
> job ticket (the %XRX... lines). You must be aware that Acrobat and Adobe Reader
> generate their own PostScript when printing to a PostScript printer (and pass it
> to the output using the printer driver's "write-through" capability. The
> TrueType to Type1 conversion is a specific feature of Acrobet or Reader,
> respectively.
No, I wasn't aware of the write-through thing, though it certainly
makes sense and I believe you. So Acrobat is doing the font conversion
in that case, not the printer driver. But I believe the printer driver
has it also: printing from Word, using a Truetype font, directly to the
printer, not using acrobat, produced postscript which printed ok, with
this snippet:
0 0 0 1 scol 26100 VM?
11 dict begin
/FontName /TT1FDDo00 def
/FontMatrix [1 2048 div 0 0 1 2048 div 0 0 ] def
/Encoding 256 array 0 1 255 {1 index exch /.notdef put} for def
/PaintType 0 def
/FontType 1 def
/FontBBox { 0 0 0 0 } def
AddFontInfoBegin
AddFontInfo
AddFontInfoEnd
currentdict
end
So apparently the printer driver also knows to do the font conversion
itself. It doesn't really help me, though; Acrobat, ghostscript and
xpdf/pdftops all generate their own postscript, not using the driver,
and I don't have anything else that can read PDFs.
The word file, TTF font and postscript file are now at
http://member.newsguy.com/~rpresser/files/WordTest.zip
> To get things more transparent, yould you please provide the following:
> - The OS version of the Sun box which acts as the controller for your
> Xerox printer (DocuPrint 92C, I suppose?);
Yes, DocuPrint 92C. Here's the banner for the controller software:
DocuPrint version: 1.6.1g: Tue Mar 7 14:45:38 PST 2000
Copyright (C) 1983-1999 by Xerox Corporation. All rights reserved.
and for the underlying SunOS:
SunOS Release 5.6 Version Generic_105181-03 [UNIX(R) System V
Release 4.0]
Copyright (c) 1983-1997, Sun Microsystems, Inc.
> - The PPD you use for your printer (on the XP box, you'll find it
> in:
> C:\EINDOWS\system32\spool\drivers\w32x86\3\yourprinter.ppd
It's named xrp92c1.ppd. Here's the top of it:
*FormatVersion: "4.2"
*FileVersion: "7.1"
*LanguageVersion: English
*LanguageEncoding: ISOLatin1
*PCFileName: "XRP92C1.PPD"
*Product: "(Xerox DocuPrint 92C NPS PS2)"
*PSVersion: "(2015.0) 0"
*ModelName: "Xerox DocuPrint 92C NPS PS2"
*ShortNickName: "Xerox DocuPrint 92C NPS PS2 C1"
*NickName: "Xerox DocuPrint 92C NPS PS2"
*XRCCRelease: "3.0"
Do you want me to upload that too?
> Perhaps I could give you some hints to solve the issue or at least hack
> a workaround.
Well, it looks like the solution to the issue is going to have to be
automating Acrobat in some form, just as I originally posted. chicks'
program, that he posted about elsewhere in the thread is probably going
to get me there.
Helge Blischke
>
>
>
>>Perhaps I could give you some hints to solve the issue or at least hack
>>a workaround.
>
>
>
> Well, it looks like the solution to the issue is going to have to be
> automating Acrobat in some form, just as I originally posted. chicks'
> program, that he posted about elsewhere in the thread is probably going
> to get me there.
>
Well, that is nearly what I expected. I first thought of using the Adobe reader to
do the conversion on the Solaris box (SunOS 5.6 is Solaris 6), but that converts
TrueType fonts to Type42, what your PS interpreter does not support. I then
tested the conversion with my good old "Acrobat Exchange 3" which I still have
on Solaris 2.5.1 (SunOS 5.5.1) and also runs on Solaris 9 (SunOS 5.9). Thus I suppose
it sill run on your Solaris 6. And this one by default converts TT fonts to Type1.
Heureka!
As Solaris usually has the SystemV spooler system (lp command) installed, it should
be possible to use acroread as a filter for your printer. If you are interested,
contact me off line to clear further details.
Papa Joe
If you took the time to convert ttf fonts to PS... why not just outline
the font in Illustrator?
I'm quite sure Illustrator CS/10 imports PDF's with the fonts. (
activated) and you can select all then create outlines. Make sure you
output raster is set high in preferences. Fonts are in themselves
paths. Most of us use postcript fonts these days. And if you use open
type then make sure it's open type postcript.
Remember: most ttf fonts are actually just converted to quadartonic
nodes from the postcript font. Not many are originals.
--
Listen to Papa Joe
rpresser
> If you took the time to convert ttf fonts to PS... why not just outline
> the font in Illustrator?
My goal is to be able to print PDFs on a specific printer, a Xerox
Docuprint 92C, automatically, without human intervention. These PDFs
are created by other automatic processes. This needs to be done dozens
if not hundreds of times every month. Having a human load them into
Illustrator is a completely unworkable suggestion.
The solution to my problem, thanks to Helge Blischke, has turned out to
be the use of Acrobat Reader on the Sun station which acts as the
controller for the Docuprint. Acrobat Reader under unix includes the
priceless "-toPostScript" commandline option.
As it turns out, to work with the most possible types of PDF among the
ones I am using and to get around the incompatibilities of Xerox's PS
RIP, I have to generate Level 1 postscript! Fortunately it doesn't
matter, and the output is fine.
There are still some of my PDFs, using barcode CID fonts, which just
won't work, even with level 1. Fortunately these particular ones (so
far) do not require high quality output, and the slightly bitmappy
output from ghostscript's pdf2ps (run on a windows machine) is
acceptable.
Helge Blischke
> Papa Joe wrote:
>
>>On 2006-08-10 12:30:46 -0300, "rpresser" <rpre...@gmail.com> said:
>
>
>>If you took the time to convert ttf fonts to PS... why not just outline
>>the font in Illustrator?
>
>
> My goal is to be able to print PDFs on a specific printer, a Xerox
> Docuprint 92C, automatically, without human intervention. These PDFs
> are created by other automatic processes. This needs to be done dozens
> if not hundreds of times every month. Having a human load them into
> Illustrator is a completely unworkable suggestion.
>
> The solution to my problem, thanks to Helge Blischke, has turned out to
> be the use of Acrobat Reader on the Sun station which acts as the
> controller for the Docuprint. Acrobat Reader under unix includes the
> priceless "-toPostScript" commandline option.
>
> As it turns out, to work with the most possible types of PDF among the
> ones I am using and to get around the incompatibilities of Xerox's PS
> RIP, I have to generate Level 1 postscript! Fortunately it doesn't
> matter, and the output is fine.
is capable of CID fonts is a matter of the version (I think 2015 or greater
is mandatory, but I'm not sure).
>
> There are still some of my PDFs, using barcode CID fonts, which just
> won't work, even with level 1. Fortunately these particular ones (so
> far) do not require high quality output, and the slightly bitmappy
> output from ghostscript's pdf2ps (run on a windows machine) is
> acceptable.
>
Helge