tectonic icon indicating copy to clipboard operation
tectonic copied to clipboard

`a4paper` option to `article` class not honored in PDF output (but `geometry` is OK)

Open teras opened this issue 6 years ago • 11 comments

First of all, well done for this marvellous system, which would probably make all other monolithic systems obsolete :)

Now, I don't know if you accept this kind of issues, but just in case... Here is a minimum sample file that produces the correct output with xelatex but with problem in margins with tectonic. Maybe have a look at it?

\documentclass[10pt, a4paper]{article}
\usepackage{marginnote}
\reversemarginpar
\begin{document}
{\marginnote{\small LEFT} RIGHT
\end{document}

teras avatar Jun 18 '18 23:06 teras

I think this is related to #126, where Tectonic always uses the US Letter paper size. If I change a4paper to letterpaper in the example above, the output looks more correct (I think?).

The subsystem for setting the paper size isn't something I've really explored, but by the same token it's not something I've monkied with very much, so hopefully these issues can be solved relatively easily. I am more than willing to provide guidance if you'd like to try investigating yourself!

pkgw avatar Jun 19 '18 13:06 pkgw

Yes please tell me what to do.

teras avatar Jun 19 '18 14:06 teras

Unfortunately, even chaning the paper size, didn't fix this issue.

Attached are the files produced as letterpage, from tectonic and xelatex.

test-tectonic.pdf test-xelatex.pdf

teras avatar Jun 19 '18 15:06 teras

Hey @teras, thank you for looking into this ❤️ it had me all morning testing! Truly, there are render differences that appear in both tectonic and XeLaTeX, let me know if the fix below works for you.

Reproducing, testing and a workable fix

Our bug happens when we do something like the following documentclass.tex test file:

\documentclass[10pt, a4paper]{article}

\usepackage{marginnote}
\reversemarginpar

\begin{document}
  {\marginnote{\small LEFT} RIGHT
\end{document}

Produces a US letter-sized document with tectonic but an a4 sized one with xelatex.

Resorting to something more global like the geometry package fixes this issue and gives us consistent rendering across tectonic and XeLaTeX, a4 size is used correctly and there are no margin differences. So with our geometry.tex test file:

\documentclass[10pt]{article}

\usepackage[a4paper]{geometry}
\usepackage{marginnote}
\reversemarginpar

\begin{document}
  {\marginnote{\small LEFT} RIGHT
\end{document}

Admittedly the render of geometry isn't exactly the same as of the documentclass option, because they do different things. If you can work it out with geometry I think is a reliable solution for consistent typesetting.


Building the documents

$ tectonic -p documentclass-tectonic.tex
$ latexmk -pdfxe documentclass-xelatex.tex

$ tectonic -p geometry-tectonic.tex
$ latexmk -pdfxe geometry-xelatex.tex

Output files

documentclass-tectonic.pdf documentclass-xelatex.pdf geometry-tectonic.pdf geometry-xelatex.pdf

Neved4 avatar Oct 21 '21 10:10 Neved4

@pkgw despite the above being a workable fix and a good way to avoid bumping into this, I'm still puzzled and don't have an answer for why the a4paper option for a document class produces different results. Maybe something related to the guts of how each engine does the processing? Need an expert on the processing internals that can help debug this ⚡️

Neved4 avatar Oct 21 '21 10:10 Neved4

@mnrvwl Yes, it's a good question. Realistically I think it will be unlikely that I'll have a chance to really dig into this one — so if someone else wants to take a look at the internals, I am happy to provide some guidance for the investigation!

pkgw avatar Oct 23 '21 14:10 pkgw

@teras Can you test the above and let me know if it works? 💛

Neved4 avatar Oct 07 '22 13:10 Neved4

Hello

Looking back at this issue, I found that on my current file I already use this block of code:

\usepackage{geometry}
\geometry{a4paper, textwidth=14.5cm, textheight=21cm, marginparsep=3mm, marginparwidth=2.8cm, left=3.5cm}
\setlength\parindent{0in}
\hfuzz=10.002pt

I can't remember if, when I originally reported this problem, I was already using the geometry package -- maybe not. But now I am. And I can confirm that with this workaround, the problem doesn't happen any more, even if this isn't solved.

Thank you for the effort. Indeed this piece of software is so nice and works like magic ...

teras avatar Oct 08 '22 21:10 teras

@teras Thanks to you for opening great issues!

There's other issues where whitespacing differences arose (https://github.com/tectonic-typesetting/tectonic/issues/376, https://github.com/tectonic-typesetting/tectonic/issues/126#issuecomment-325400920). It seems certainly a good idea to have the output be predictable to what other users from the TeX community expected it to be, even if Tectonic's goal is to be its own thing.

Note that while output differences like this are not common they do exist, and you may find them using pdfTeX/XeTeX/LuaTEX too and sometimes between the packages and the different engines.

Passing the size to the standard document classes may not always be respected or interpreted the same way, so \geometry can be a more robust alternative to avoid these differences across the multitude of engines and packages.

As Tectonic will evolve and diverge over time maybe we could suggest using \geometry instead somewhere in the docs.

Do you consider the workaround sufficient to close the issue or would you rather wait until tectonic's output is the same as XeTeX?

Neved4 avatar Oct 08 '22 22:10 Neved4

@mnrvwl thank you for your welcome comments. An open source community is not always like this.

For me, I totally agree that it's impossible to be compatible with irrelative projects and keep your quality at a standard.

If adding just a general case package like \geometry fixes most of the problems, I believe it's enough, as long as this information is put in an obvious (and really visible) location.

At any case, since a working workaround was found, please feel free to close this issue.

teras avatar Oct 09 '22 13:10 teras

I think I would like to keep this issue open as a reminder to look into whether we're handling PDF page sizing, or some other aspect of things, in a way that isn't compatible with other TeX engines. Maybe there is a good reason for the different behavior but I feel like this is something where we should be behaving the same. I'll retitle the issue to try to capture this.

pkgw avatar Oct 21 '22 03:10 pkgw