[tex-k] epstopdf: using eps libraries

[Marcel Tünnissen]

Hi,

I have some eps files that I want to include in my latex document.
Apparently
pdflatex runs epstopdf. The problem is that my eps file includes some
libraries that are eps file as well and my gs doesn't allow them to be run
unless you set the '-dNOSAFER' option.

For this reason I tried to convert one file with:
$ /usr/bin/epstopdf --nogs --gscmd='gs -dNOSAFER'
-o=pics/triangles-eps-converted-to.pdf pics/triangles.eps

But then my pfdlatex gives the following message:

<use ./pics/heptagons-eps-converted-to.pdf>Syntax Warning: May not be a PDF
file (continuing anyway)
Syntax Error: Couldn't find trailer dictionary
Syntax Error: Couldn't read xref table

$ epstopdf --version
epstopdf ($Id: epstopdf.pl 26570 2012-05-22 16:14:37Z karl $) 2.18

$ gs --version
9.06

I tried to look in the archive (using NOSAFER, but it didn't give me so
much)

Thanks for any help, regards,
Marcel

ps Please reply to all, since I am not a subscriber to the list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/tex-k/attachments/20121111/b88ee477/attachment.html>

[Karl Berry]

Hi Marcel,

$ /usr/bin/epstopdf --nogs --gscmd='gs -dNOSAFER'

--nogs says "don't run gs". So I suspect the output is still .eps, not
.pdf. What happens without that option?

If that doesn't solve it, please send the actual .eps in question,
and be sure you're using the latest epstopdf:
epstopdf ($Id: epstopdf.pl 26570 2012-05-22 16:14:37Z karl $) 2.18
(You can get it from mirror.ctan.org/support/epstopdf/ if need be.)

Best,
Karl

[Reinhard Kotucha]

Post by Karl Berry
Hi Marcel,
$ /usr/bin/epstopdf --nogs --gscmd='gs -dNOSAFER'
--nogs says "don't run gs". So I suspect the output is still .eps, not
.pdf. What happens without that option?

The --gscmd argument doesn't tell gs what to do. One could try

epstopdf --nogs f.eps | \
gs -q -dNOPAUSE -dNOSAFER -sDEVICE=pdfwrite -sOutputFile=f.pdf -

Regards,
Reinhard

Post by Karl Berry
If that doesn't solve it, please send the actual .eps in question,
epstopdf ($Id: epstopdf.pl 26570 2012-05-22 16:14:37Z karl $) 2.18
(You can get it from mirror.ctan.org/support/epstopdf/ if need be.)
Best,
Karl

[Marcel Tünnissen]

Hi,

Thanks Reinhard, that works great!

Btw, without the --nogs was the first thing I tried, but that gave me this:

$ /usr/bin/epstopdf --gscmd='gs -dNOSAFER' -o=f.pdf triangles.eps
epstopdf ($Id: epstopdf.pl 26570 2012-05-22 16:14:37Z karl $) 2.18
!!! Error: Cannot open Ghostscript for piped input

Cheers
Marcel


On Sun, Nov 11, 2012 at 8:37 PM, Reinhard Kotucha

Post by Reinhard Kotucha

Post by Karl Berry
Hi Marcel,
$ /usr/bin/epstopdf --nogs --gscmd='gs -dNOSAFER'
--nogs says "don't run gs". So I suspect the output is still .eps, not
.pdf. What happens without that option?

The --gscmd argument doesn't tell gs what to do. One could try
epstopdf --nogs f.eps | \
gs -q -dNOPAUSE -dNOSAFER -sDEVICE=pdfwrite -sOutputFile=f.pdf -
Regards,
Reinhard

Post by Karl Berry
If that doesn't solve it, please send the actual .eps in question,
epstopdf ($Id: epstopdf.pl 26570 2012-05-22 16:14:37Z karl $) 2.18
(You can get it from mirror.ctan.org/support/epstopdf/ if need be.)
Best,
Karl

--
----------------------------------------------------------------------------
[phone]
Marschnerstr. 25
reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/tex-k/attachments/20121111/e71ea1ea/attachment.html>

[Norbert Preining]

Karl,

Post by Marcel Tünnissen
$ /usr/bin/epstopdf --gscmd='gs -dNOSAFER' -o=f.pdf triangles.eps
epstopdf ($Id: epstopdf.pl 26570 2012-05-22 16:14:37Z karl $) 2.18
!!! Error: Cannot open Ghostscript for piped input

I checked epstopdf.pl, that is indeed a problem, the argument to
--gscmd is not split into words, but passed as a whole as the
gs command. Thus, adding additional arguments does not work.

I am not even sure if --gscmd='gs -dNOSAFER' could work, as we push
later on -dSAFER onto the cmd line arguments.

Maybe we extend epstopdf in two ways:
* add a command line switch -nosafer that changes the -dSAFER to -dNOSAFER
* split the --gscmd into words

WDYT?

Best wishes

Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
ROYSTON (n.)
The man behind you in church who sings with terrific gusto almost tree
quarters of a tone off the note.
--- Douglas Adams, The Meaning of Liff

[Reinhard Kotucha]

Post by Norbert Preining
I checked epstopdf.pl, that is indeed a problem, the argument to
--gscmd is not split into words, but passed as a whole as the
gs command. Thus, adding additional arguments does not work.

At a first glance I thought that --gscmd was supposed to replace
options too, but obviously its purpose is to change only the program
name. It's probably superfluous since $^O is checked already.

Post by Norbert Preining
I am not even sure if --gscmd='gs -dNOSAFER' could work, as we push
later on -dSAFER onto the cmd line arguments.

Yes, this can't work.

Post by Norbert Preining
* add a command line switch -nosafer that changes the -dSAFER to
* -dNOSAFER

Sounds good, but it should be ignored if ($restricted != 0).

Post by Norbert Preining
* split the --gscmd into words

IMO the benefit is very small because you can't pass arbitrary options
to gs this way. The order matters. I suppose that you can write

gs -dNOSAFER file1.ps -dSAFER file2.ps

Regards,
Reinhard

[Norbert Preining]

Hi Karl,

attached is a patch for epstopdf.pl. It implements
--nosafer
which includes -dNOSAFER instead of -dSAFER, as well as splitting
of --gscmd argument at white spaces.

Both things are done only if not restricted.

Please review.

Post by Reinhard Kotucha

Post by Norbert Preining
* split the --gscmd into words

IMO the benefit is very small because you can't pass arbitrary options
to gs this way. The order matters. I suppose that you can write

Not arbitrary, but at least some options?

Best wishes

Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
HIDCOTE BARTRAM (n.)
To be caught in a hidcote bartram is to say a series of protracted and
final goodbyes to a group of people, leave the house and then realise
you've left your hat behind.
--- Douglas Adams, The Meaning of Liff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: epstopdf.pl.diff
Type: text/x-diff
Size: 2406 bytes
Desc: not available
URL: <http://tug.org/pipermail/tex-k/attachments/20121112/dec874aa/attachment.bin>

[Heiko Oberdiek]

Post by Norbert Preining
attached is a patch for epstopdf.pl. It implements
--nosafer
which includes -dNOSAFER instead of -dSAFER, as well as splitting
of --gscmd argument at white spaces.

Sorry, I think the latter is a very bad idea. There are command names
with spaces. A different option (--gsopt) is much more cleaner.

Yours sincerely
Heiko Oberdiek
--

[Heiko Oberdiek]

Post by Reinhard Kotucha

Post by Norbert Preining
I checked epstopdf.pl, that is indeed a problem, the argument to
--gscmd is not split into words, but passed as a whole as the
gs command. Thus, adding additional arguments does not work.

At a first glance I thought that --gscmd was supposed to replace
options too, but obviously its purpose is to change only the program
name. It's probably superfluous since $^O is checked already.

No, it is definitely not superfluous:
* The automatic checks might fail (especially on windows there are many
different standard command names 32bit, 64bit, ...).
* There can be several ghostscript installations on a machine
(different versions, different ports, different locations).
There are PostScript files that do not work with any Ghostscript
version and a Ghostscript version might not work with any
PostScript file. For this reason and for testing reasons I
have about fifteen Ghostscript versions installed.
Thus --gscmd makes it easy to select a different
Ghostscript program.

Post by Reinhard Kotucha

Post by Norbert Preining
* add a command line switch -nosafer that changes the -dSAFER to
* -dNOSAFER

Sounds good, but it should be ignored if ($restricted != 0).

Yes, -dSAFER must be in force for restricted mode.

Post by Reinhard Kotucha

Post by Norbert Preining
* split the --gscmd into words

Bad idea, because the command name may already contain spaces.
IMHO it is better to add an new option --gsopt or similar to add
additional Ghostscript options.
In restricted mode this kind of option also needs to be disabled
unless the options are parsed and found harmless. The option
value might contain quite complex code (e.g. PostScript code
in option -c of Ghostscript). This and unknown settings
(e.g. -dXYZ) must be ignored/rejected in restricted mode
to avoid security holes.

Post by Reinhard Kotucha
IMO the benefit is very small because you can't pass arbitrary options
to gs this way. The order matters. I suppose that you can write
gs -dNOSAFER file1.ps -dSAFER file2.ps

At least different option settings for different files are not needed
for `epstopdf', because it only converts one file.

Yours sincerely
Heiko Oberdiek
--

[Norbert Preining]

Hi Heiko,

Post by Heiko Oberdiek
Yes, -dSAFER must be in force for restricted mode.

done alteady

Post by Heiko Oberdiek

Post by Norbert Preining
* split the --gscmd into words

Bad idea, because the command name may already contain spaces.

Ugg, yes, and one cannot quote that away.

Post by Heiko Oberdiek
IMHO it is better to add an new option --gsopt

I'll send a patch tomorrow or tonight.

Post by Heiko Oberdiek
In restricted mode this kind of option also needs to be disabled
unless the options are parsed and found harmless.

Parsing is too error prone, I would say disabled.

Norbert

[Norbert Preining]

Post by Norbert Preining

Post by Heiko Oberdiek
IMHO it is better to add an new option --gsopt

I'll send a patch tomorrow or tonight.

Here it is. Again gsopts is split at white space.
Otherwise ... well I can if it is necessary, but then one has to do
--gsopt -dSAFER --gsopt -dFOO --gsopt BLA ...
instead of
--gsopts "-dSAFER -dFOO BLA..."

Is that ok to split at white space?

COmments?

Thanks

Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
ROCHESTER (n.)
One who is able to gain occupation of the armrest on both sides of
their cinema or aircraft seat.
--- Douglas Adams, The Meaning of Liff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: epstopdf.pl.diff
Type: text/x-diff
Size: 3020 bytes
Desc: not available
URL: <http://tug.org/pipermail/tex-k/attachments/20121112/00b2b0e9/attachment.bin>

[Heiko Oberdiek]

Post by Norbert Preining

Post by Norbert Preining

Post by Heiko Oberdiek
IMHO it is better to add an new option --gsopt

I'll send a patch tomorrow or tonight.

Here it is. Again gsopts is split at white space.
Otherwise ... well I can if it is necessary, but then one has to do
--gsopt -dSAFER --gsopt -dFOO --gsopt BLA ...
instead of
--gsopts "-dSAFER -dFOO BLA..."
Is that ok to split at white space?

For example, options -I, -sFONTPATH=..., might have values with spaces.

Thus I think, --gsopt without splitting at white space is necessary
and --gsopts with splitting at white space is useful for convenience.

Yours sincerely
Heiko Oberdiek
--

[Reinhard Kotucha]

Post by Heiko Oberdiek

Post by Norbert Preining

Post by Norbert Preining

Post by Heiko Oberdiek
IMHO it is better to add an new option --gsopt

I'll send a patch tomorrow or tonight.

Here it is. Again gsopts is split at white space.
Otherwise ... well I can if it is necessary, but then one has to do
--gsopt -dSAFER --gsopt -dFOO --gsopt BLA ...
instead of
--gsopts "-dSAFER -dFOO BLA..."
Is that ok to split at white space?

For example, options -I, -sFONTPATH=..., might have values with spaces.
Thus I think, --gsopt without splitting at white space is necessary
and --gsopts with splitting at white space is useful for convenience.

Please excuse me for hijacking the tread, but there is a long standing
issue with the removal of "binary junk". Two years ago I created
three testfiles which cause epstopdf to crash. You'll find the files

test-TN5002-cr.eps
test-TN5002-crlf.eps
test-TN5002-lf.eps

under Build/source/extra/epstopdf .

The binary headers are described in Adobe TN5002. I padded the
PostScript section with comment characters so that the part of the
header denoting the length of this section contains the bytes "\r\n".

The regular expression which tries to remove the "binary junk" doesn't
work in this case. The patch below uses substr() in order to remove
the header if the magic number defined in TN5002 is recognized and
falls back to the current behaviour otherwise.

At a first glance not much is gained because gs crashes now with

Error: /undefined in II*

II* is the byte order mark of a TIFF image. Curiously, despite of the
error message, for all three test files ghostscript created valid and
correct PDF files. So I think there is at least a little gain.

The TN5002 header is written to the global variable $TN5002_header and
can be decoded with

my ($magic, $psstart, $pslen, $metastart, $metalen,
$tiffstart, $tifflen, $checksum)
= unpack("H8VVVVVVH4", $TN5002_header);

The proper way would be to send only everything between $psstart and
$psstart+$pslen to gs, but these values have to be corrected because
stuff is inserted by epstopdf. Admittedly, it certainly sounds easier
than it is. I must admit that my motivation is quite limited because
Siep's epspdf.rb script works like a charm.

Regards,
Reinhard


--- epstopdf-orig 2012-05-23 01:07:56.000000000 +0200
+++ epstopdf 2012-11-12 23:43:23.000000000 +0100
@@ -441,6 +441,7 @@
my $buflen;
my @bufarray;
my $inputpos;
+my $TN5002_header;

# We assume 2048 is big enough.
my $EOLSCANBUFSIZE = 2048;
@@ -459,8 +460,15 @@
# entire file
if ($buf =~ /%!/) {
# throw away binary junk before %!
- $buf =~ s/(.*?)%!/%!/o;
- $inputpos = length($1);
+ if ($buf =~ /^\xC5\xD0\xD3\xC6/) { # binary header
+ # according to Adobe TN-5002
+ $TN5002_header = substr($buf, 0, 29);
+ $buf = substr($buf, 30);
+ $inputpos = 30;
+ } else {
+ $buf =~ s/(.*?)%!/%!/o;
+ $inputpos = length($1);
+ }
}
$lfpos = index($buf, "\n");
$crpos = index($buf, "\r");

[Norbert Preining]

Hi Reinhard,

Post by Reinhard Kotucha
The proper way would be to send only everything between $psstart and
$psstart+$pslen to gs, but these values have to be corrected because

To cut things short: Does your patch fix a ral problem
and does not create new ones? If yes, why not check it in to
the tl svn?

BTW, Karl, what is with the patch I sent for the gsopts etc? Should
I commit that one?

Best wishes

Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
SHIFNAL (n.,vb.)
An awkward shuffling walk caused by two or more people in a hurry
accidentally getting into the same segment of revolving door. A
similar effect is achieved by people entering three-legged races
unwisely joined at the neck instead of the ankles.
--- Douglas Adams, The Meaning of Liff

[Reinhard Kotucha]

Post by Norbert Preining
Hi Reinhard,

Post by Reinhard Kotucha
The proper way would be to send only everything between $psstart
and $psstart+$pslen to gs, but these values have to be corrected
because

To cut things short: Does your patch fix a ral problem and does not
create new ones?

Hi Norbert,
without the patch, gs crashes when the binary header contains a
linebreak:

Error: /undefined in be-3.0

(this originates from %!PS-Adobe-3.0 EPSF-3.0).

In order to be sure that I don't break anything, I remove the first 30
bytes from the file only if it begins with the 4-byte magic number
described in Adobe TN5002. Otherwise the old behavior is retained.

When the binary header is properly stripped, current versions of gs
are able to process the file. They run into trouble when they
encounter the preview image at the end:

Error: /undefined in II*

But though gs complains, it creates a valid PDF file. Thus, my patch
is better than nothing.

Post by Norbert Preining
If yes, why not check it in to the tl svn?

I hesitated in order to allow you to apply your patch first, just
to prevent you from having to resolve conflicts in svn. Not a big
deal, but always extra work.

Now I'm glad to hear that Heiko looks at it. BTW, as far as I've
seen, there are no PostScript files beginning with arbitrary binary
junk. All files with binary headers I've seen comply with TN5002.

The usage has changed. The original idea was to allow programs to
access a preview image quickly, but nowadays programs like CorelDraw
or InDesign put their source code there. People believe that these
programs can read PostScript code, but they are cheating. I have to
revise my expectation that the binary headers are a remnant from the
MS-DOG era and will disappear. No, they are still ubiquitous today.

Regards,
Reinhard

[Norbert Preining]

Post by Heiko Oberdiek
Thus I think, --gsopt without splitting at white space is necessary
and --gsopts with splitting at white space is useful for convenience.

Attached patch implements both behaviours.

Best wishes

Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
ABOYNE (vb.)
To beat an expert at a game of skill by playing so appallingly that
none of his clever tactics or strategies are of any use to him.
--- Douglas Adams, The Meaning of Liff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: epstopdf.pl.diff
Type: text/x-diff
Size: 3823 bytes
Desc: not available
URL: <http://tug.org/pipermail/tex-k/attachments/20121113/02374606/attachment.bin>