<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 28 May 2016 at 23:15, Karl Berry <span dir="ltr"><<a href="mailto:karl@freefriends.org" target="_blank">karl@freefriends.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">    except that all other drivers support it in an incompatible way..<br>
<br>
</span>How unsurprising.<br></blockquote><div><br>:-)<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
    was dvisvgm but I didn't understand its size at all:<br>
    etex pagesize; dvisvgm pagesize<br>
    pre-processing DVI file (format 2)<br>
    processing page 1<br>
      page size: 217.359pt x 664.121pt (76.3929mm x 233.412mm)<br>
<br>
</span>I believe dvisvgm trying to create an includable graphic rather than a<br>
full page, thus it's more or less the bounding box of the output?  </blockquote><div><br></div><div>I discounted that (due to the height), but of course I'd forgotten the page number, so yes ignore<br></div><div>dvisvgm, it just doesn't use the special at all, which is OK, my error.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Full<br>
pages are not what SVG files are for, after all.  The papersize special<br>
is not mentioned on the dvisvgm man page.  Could ask MartinG and/or look<br>
at the source if it matters.<br></blockquote><div><br></div><div>No as I say that was my error.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
    So... I was wondering if dvi drivers that support special{papersize=<br>
    could agree on how to treat multiple instances?<br>
<br>
</span>If the only thing we have to change is dvips, per your experiments, that<br>
is feasible, in principle.  It certainly seems more feasible than<br>
changing "everything else".  And also the behavior (last special on<br>
first page wins) seems better -- matches pdftex better.<br></blockquote><div><br></div><div><br></div><div>yes but (despite raising the issue) I'm not at all sure changing dvips after all this time<br></div><div>would have any good consequences.<br></div><div><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
    Changing (say) dvips would of course affect the behaviour of any<br>
    document that has this set twice (eg has hyperref and geometry both<br>
    loaded) so it's not necessarily a good idea,<br>
<br>
</span>Let's suppose, hypothetically, that we change dvips to match the others<br>
(with an option so people can get the old behavior if they want it, etc.).<br>
<br>
Would this imply you would then make further changes in latex?  If so, what?<br></blockquote><div><br></div><div>I'm not sure:-) Partly I sent the message just to stir the pot and see if anyone had<br></div><div>a brilliant idea.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
And, are any changes in this area desirable at all in latex2e?  I am<br>
skeptical.  Whatever the deficiencies and suboptimalities of the current<br>
situation (no argument that there are plenty), people have necessarily<br>
figured out how to get the page sizes they want with the software they<br>
want.  If we make any changes, I highly suspect existing workflows will<br>
break, and not in any obvious way.<br></blockquote><div><br></div><div>yes <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Or am I being too negative?  -k<br>
</blockquote></div><br></div><div class="gmail_extra">no<br><br></div><div class="gmail_extra">I suspect that changing the drivers isn't going to work, even if you added an option<br></div><div class="gmail_extra">to change the behaviour back it will just lead to confusion.<br><br><br></div><div class="gmail_extra">What I think I should probably try to do in latex is set up a system that allows cooperating<br></div><div class="gmail_extra">packages to not add the special more than once, then the issue doesn't arise.<br><br></div><div class="gmail_extra">there are various ways that could be done for example dvips/dvipdfm options could<br></div><div class="gmail_extra">instead of adding the special directly as now which implies some rather odd package ordering<br></div><div class="gmail_extra">behaviour, they could just set some defined \pagewidth and \pageheight lengths (as for pdftex/luatex)<br></div><div class="gmail_extra">and then latex could insert a single special when shipping out the first page based on those values at that time.<br><br></div><div class="gmail_extra">or something...<br><br></div><div class="gmail_extra"></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">David<br><br></div><div class="gmail_extra"><br><br></div></div>