[softwarelist] Re: !PDF Import - RISC OS
- From: Peter Newble <pcnewble@xxxxxxxxx>
- To: davidpilling@xxxxxxxxxxxxx
- Date: Thu, 24 Jan 2019 18:31:20 +0000
On 23 Jan 2019, at 12:45, David Pilling <david@xxxxxxxxxxxxxxxx> wrote:
The web page for TransPDF tells you a lot:
https://www.pacificbulbsociety.org/pbswiki/index.php/ErythroniumFour#sibericum
<https://www.pacificbulbsociety.org/pbswiki/index.php/ErythroniumFour#sibericum>
That’s incredibly useful — I didn’t know about that. (The original question was
about Ovation Pro for RISC OS but I’m now using the Windows version so this is
useful for me).
This relies on GhostScript being available and it turns the PDF into an EPS -
which is only going to print on a PostScript printer.
Note a few things about the configuration file, transpdf.txt:
i) In the latest versions of Ghostscript (since 9.18 I think; the current
version is 9.26) the device EPSWRITE is depreciated and replaced with the more
reliable EPS2WRITE. Therefore, in the third line, '-sDEVICE=EPSWRITE’ now needs
to be '-sDEVICE=EPS2WRITE'. That gives the game away that it produces
PostScript 2-compatible EPS, which is why many PDFs ed up being wholly or
partially rasterised to bitmaps, because they are based on PostScript 3 and PS2
can’t adequately render them.
ii) For that reason in the third line I have also changed '-r300’ to '-r600'.
That means that anything which GhostScript can’t translate as a vector and
needs to be rasterised ends up at 600dpi which, on a laser printer, will be of
equivalent quality. For sending to an imagesetter I would change this to
'-r1200’, but it might then probably run impossibly slowly. 300dpi is an
appropriate resolution for photographs but not for text or vector graphics,
which is where GhostScript is most likely to need to revert to rasterising.
iii) Adding 'dTextAlphaBits=4 -dGraphicsAlphaBits=4‘ to the second line creates
an anti-aliased preview image, which is much useful.
Therefore I have altered transpdf.txt to read:
pdf psloc C:\Program Files\gs\gs9.26\bin\gswin32c.exe
pdf mkpreview -dSAFER -dBATCH -dNOPAUSE -sDEVICE=tiff24nc -dTextAlphaBits=4
-dGraphicsAlphaBits=4 -sOutputFile="%s" -r300 -q -dFirstPage=1 -dLastPage=1 "%s"
pdf mkeps -dSAFER -dBATCH -dNOPAUSE -sDEVICE=eps2write -sOutputFile="%s" -r600
-q -dFirstPage=1 -dLastPage=1 "%s"
(the '-r300’ in the second line makes a generously detailed 300dpi preview
image — reducing it to '-r100’ would be good enough for most purposes, because
one doesn’t need the same resolution on screen as on paper, and it would make
things quicker.) EPS files usually have a 72dpi preview, after all, and usually
8-bit not 24-bit therefore including significant dithering artefacts too.
I've had a look at my RISC OS computer and the web, I'm surprised that I
can't find this - I have memories of having produced something that used
GhostScript. Google is not what it used to be…
In 2006/2007 I mentioned to you that I was having problems with PostScript
devices (especially Acrobat, when converting the output from RISC OS printers
drivers into PDFs, but also some printers) rejecting some EPSs containing TIFF
preview images. My laborious workround had been to import the EPS with its
preview into Ovation Pro, reference the image, then quietly swap the EPS in the
directory of referenced images with one with the preview image removed, without
telling Ovation Pro. Thus the printer driver was happy when it received the
preview-less EPS, but Ovation Pro continued to display the previously-load
preview. However, that was an annoying faff. You helpfully suggested modifying
the !OEPS applet to use GhostScript to create a preview image on importing the
EPS into Ovation Pro, which meant there would be no need to include troublesome
preview images in the original EPSs. It also had the benefit (see above) of
24-bit previews at a resolution of one’s choice, rather than nasty 72dpi 8-bit
EPS previews. I have that version but I’m not sure whether it was ever
published as such.
That worked well for some time, then stopped and I couldn’t work out why, so I
gave up on it and stopped using EPSs, instead rendering those images too
complex to be converted to drawfiles to high-resolution (600dpi or 1200dpi)
bitmaps instead. Then I also migrated from the RISC OS version of Ovation Pro
to Windows.
So this PDF filter for Windows is working in a similar way to the modified
!OEPS applet for RISC OS.
This idea can be useful, I've sometimes loaded PDF or PostScript this way,
but it's not wonderful, you have to have GhostScript, it has to have enough
memory and sometimes it will fail.
Quite.
My final thoughts were that if I promoted this I'd disappoint more people
than I would please.
Possibly. One needs to be aware that it won’t always work, as GhostScript won’t
handle all PDFs for various reasons. The problem is that the filter is more
likely to fail when printing than when initially importing the PDF — it seems
to be able to rasterise some PDFs which it then fails to convert to Postscript,
in the same way that some PDFs can be displayed correctly on screen by Acrobat
Reader, Apple Preview etc., but then fail when printed to a Postscript printer.
Thus you’ve put together an Ovation Pro document containing lots of PDF images,
it refuses to print and you’ve then got to work out why. It’s fine if you check
it with each PDF as you import it to see whether it’s OK. (I run Ovation Pro on
Windows 7, running under Parallels on a Mac, so therefore I always ‘print’ from
Ovation Pro via Acrobat Distiller to produce a PDF on the Mac desktop.)
Peter.
Other related posts:
