[tex-k] epstopdf: %%BoundingBox: (atend)

[Martin von Gagern]

Hi Karl,

thanks for your reply, and sorry for the delay in replying myself.

Karl Berry wrote:
> I think the current situation is that (atend) is supported for regular
> files, but not (as you point out) pipes.  And I think this deficiency is
> why it is not claimed to be supported in the documentation.  That could
> be made more precise.
> 
> As far as I can see, supporting it for pipes means a new strategy: have
> to read the entire input file into a temporary location and then process
> that.

I fear there is some misconception here. You seem to be talking about
input from a pipe, which is indeed a rare and somewhat difficult
scenario. I on the other hand am talking about output to a pipe, namely
the ghostscript process doing the actual conversion. This is the common
case, only disabled with the --nogs command line switch, which I
consider useful only for debugging. Some parts of your mail made only
sense with respect to input pipes, so I skipped those.

> And detecting whether the input is a pipe or file in the first
> place, which I'm not sure is any trivial/portable (esp. to Windows) task.

I would think this should be easy. At the heart of it, you're not
interested in whether it's a pipe or not, but whether it's seekable or
not. So a simple "seek(HANDLE, 0, SEEK_CUR)" should indicate whether any
given file handle, be it input or output, is seekable.

But as I pointed out, I'm not overly concerned with input from a pipe,
at least for now, and output to a pipe is so much the default case, that
any particular optimization for a non-pipe output doesn't seem worth the
trouble.

> My guess is that the current maintainer of epstopdf (Gerben Wierda)
> would accept a clean patch for these things, but is unlikely to write it
> himself.  Any interest?  Anyway, I'll ask him.  (I don't have the
> time/inclination/energy to do it myself either, I'm afraid.)

I don't know whether I'll find time to do this, but if I come up with a
patch, I'll certainly post it here. I'm wondering, however, if simply
reverting a previous modification might be an easier solution. The tell
function seems to get invoked in order to determine the number of bytes
of input processed so far, so that a later seek on the input can return
to that position.

The getline function however does seem to maintain its own counter of
the number of processed input bytes. That counter is not used anywhere
else, and I assume that it is a remnant of a previous implementation
that worked without telling the position on an output pipe.

I also guess that using $bufarraypos won't work out of the box any more,
as it doesn't take binary junk before the initial %! into account. But
that should be fairly easy to remedy. Therefore I'd be highly interested
in the history of that variable: when was it introduced, did it ever
work as I assume, why was its use dropped, and so on.

>     I don't know if there is any kind of public archive of past versions 
> 
> There is no public repository for epstopdf, only the versions included
> in the various TeX (and other) distributions over the last N years.

I'm not looking forward to digging through various TeX distribution
packages to find older versions. I guess writing a patch from scratch
might be easier than that.

Greetings,
 Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://tug.org/pipermail/tex-k/attachments/20090825/b7abf1d9/attachment.bin>