[tlbuild] Compatibility with ConTeXt was broken in asy 2.33

[John Bowman]

Hi Mojca,
Thanks for reporting this issue, which I tracked down to a bug in the new
Ghostscript eps2write driver that causes all multipage output to appear on
page 1. This effects both the xelatex and context texengines in Asymptote.

A workaround seems to be to force each page to go to a separate file (using
%d in the filename). I should have a fix implemented later today.

Attached is a minimal example. Each label belongs to a separate page. The
generated file gsbug__.pdf is correct but gsbug__.ps, produced by

gs -q -dNOCACHE -dNOPAUSE -dBATCH -dSAFER -sDEVICE=eps2write
-sOutputFile=gsbug__.ps gsbug__.pdf

contains 2 pages but all of the postscript now appears only on page 1.

This needs to be reported to the ghostscript maintainers, but in the
meantime we need a workaround since ghostscript 9.15 and 9.16 are now
widely in use.

-- John



On Tue, May 19, 2015 at 12:36 AM, Mojca Miklavec <
mojca.miklavec.lists at gmail.com> wrote:

> Dear John,
>
> On Mon, May 18, 2015 at 10:06 PM, John Bowman wrote:
> > Hi Mojca,
> >
> > The change to support rendered 3D context images is easy. In adding
> support
> > for eps2write,
> > I didn't worry about supporting 3D context labels since context doesn't
> > support vector 3D graphics anyway (it doesn't support embedded PRC
> content).
>
> ConTeXt supports PRC by now (or at least I think it does), but we
> won't have time to add support for it in time for TL 2015 anyway, so
> true, no need to worry about true 3D.
>
> > But as I believe you are pointing out, some context users may be happy
> just
> > to have a rendered preview image.
>
> Actually this is all that is needed for printed materials.
>
> In all honesty I could have certainly used another engine, but I'm
> more comfortable and familiar doing the font setup in ConTeXt.
>
> > The patch below (snv r5715) tells asy to
> > treat context just like xe (these are special cases because they do not
> > provide dvi output). I tested this with the context from TL 2014 and it
> > seems to work as desired.
>
> Yes, it works better now, but some things still break. I will send the
> source code and some logs off-list.
>
> In short:
>
> [context runs succesfully]
> system          | total runtime: 1.508 seconds
> gs -q -dNOCACHE -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite
> -sOutputFile=cylinder__.pdf cylinder_.pdf
> gs -q -dNOCACHE -dNOPAUSE -dBATCH -dSAFER -sDEVICE=eps2write
> -sOutputFile=cylinder__.ps cylinder__.pdf
> gs -q -dBATCH -P -dSAFER -sDEVICE=eps2write -sOutputFile=/dev/null
> cylinder_.ps
> M 0.00146484 -0.000244141L -35.6001 -0.000244141L ...
> [really looooooong list of coordinates in a single line]
> ... -17.0898 148.609 -14.0703 150.828 -13.1211 151.703cM -17.0898 148.609
> /opt/local/share/asymptote/plain_Label.asy: 670.23: reading array of
> length 1 with out-of-bounds index 1
>
> Mojca
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/tlbuild/attachments/20150519/187ff863/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gsbug.asy
Type: application/octet-stream
Size: 174 bytes
Desc: not available
URL: <http://tug.org/pipermail/tlbuild/attachments/20150519/187ff863/attachment.obj>