[tex-live] Fontspec overriding default paper size with LuaTeX

[David Carlisle]

On 26 May 2016 at 17:13, Bruno Voisin <bvoisin at icloud.com> wrote:

>
>
>
>
> - But what's confusing is that this is not implemented as a core LaTeX
> functionality, and instead added by an optional package whose functionality
> is not directly connected with page design.


It's not ideal but it is what it is, based on various historical facts and
decisions that it's hard to undo.
dvi has no notion of page size you just specify a text block and print it
at some offset from the top left
corner, defaulting at 1in,1in. At the time that the 2e interface was fixed
it was still uncommon for
dvi drivers to have a page size setting (and pdftex didn't exist) the
nearest would be inserting printer-model
specific codes to select the right paper tray in the printer.

the model when the <driver>.def files got done was that they should have
all the back end specific code that would be needed (it didn't quite turn
out that way)
Which is why color and graphics share def files, and why the page size gets
set in the def files for those I knew about at the time.





> It's confusing for the user to call the graphics/x package for figure
> inclusion with \includegraphics, and find out suddenly the page size of the
> output has changed.


Think of it as "corrected" not "changed" and it doesn't seem so bad.
Rendering an A4 formatted document to a letter sized pdf is (to put it
mildly) sub-optimal and as soon as latex knows it is running under pdftex
(specifically when pdftex.def gets loaded by color or graphics, or similar
code in geometry and hyperref) then it does the driver specific commands
necessary to fix the page size.

It sounds confusing but latex has done this for as long as pdftex has
existed (starting with the initial pdftex support in epsfig.sty for
latex2.09) and given how infrequently this has come up, I think in the main
it "does what people expect".

The standard document classes could (as some contributed classes do) detect
pdftex and insert a back end page size but there were a lot more relevant
drivers back then and the standard classes avoided any driver specific code
as they have to offer the standard baseline portability layer. As article
doesn't have a dvips option it can't distinguish dvips from dvisvg or emtex
or whatever else might be used to process the dvi so can't specify a page
size in general.



> It's even more confusing for the user -- like me -- to call fontspec so as
> to load fonts installed at the OS level, and find out the page size of the
> output has also changed.
>

Yes the fact that fontspec ends up loading graphics is a long story and
unfortunate, it doesn't happen if you use the newer tuenc settings which
Will had hoped to make the default but didn't get time to switch before
tl2016, hopefully in an update soon:-)


Meanwhile, related to this as you noted dvips.def and xetex.def currently
don't use a pagesize special (probably a bug I should fix) and despite the
fact that geometry has been mentioned  a few times, it currently doesn't
work in texlive 2016 luatex unless you load luatex85.sty first, owing to
the name changes of \pdfpageheight etc. (An update has been promised for
that by the geometry package maintainer so hopefully that's just a
temporary problem).

So like many things with TeX, it's all perfectly natural and understandable
if you happen to know a 30 year history and squint at it from a strange
angle, otherwise it's less understandable. But short of re-running that
history on a slightly different path it's not clear that the current
situation is wrong or can be changed.

What can I say: It's not all my fault:-)

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/tex-live/attachments/20160526/008b8d13/attachment.html>