Add option to force paper size for latex/pdf output

[jonaslb]

As the title says - or perhaps make A4 the default?

To expand, tex-live and other distributions have a default paper size, that can be set by the user, and which seems to be respected by pdflatex and latex.
However packages like xcolor and geometry (used in the latex template) will change the paper size to letter, unless the size is forced by setting it as an option to the document class.

I assume it is possible to work around the issue by making my own custom template. I don't think that it is a reasonable solution though - it seems like a bit much just for standard paper.

[mpacer]

Given the widespread use of letter as a default not only here but in many cases, I don't think we'll be changing the default.

But it would seem possible to put a hook in that would directly declare the paper size in the call to the geometry class. What's nice is that we can use that as a way of setting the document size despite its setting it to be the default.

I can't find anything in the documentation of xcolor saying that it sets the default paper size to letter, could you point me to where it talks about that? Or in the source, where that change actually is implemented.

The question is where to input this kind of a parameter. We could include a flag, on the command line, but then that might require either hand picking a set of options and hard coding the solution or checking to make sure that no one can hijack it to pass in malicious arguments (I think that shouldn't be the case but I don't know the full ramifications).

Hardcoding for a few common options seems most straightforward but overall not really addressing the problem. Especially given the variety of control that geometry optional arguments can offer.

Alternatively, this may be a good test case for something I've been thinking about this more generally. Basically, we don't want to grow the API a bit to for every bit of greater expressivity we might want in the context of advanced LaTeX commands. If needed, I can find links to other issues and prs in which this is discussed, but @takluyver, @Carreau and @ellisonbg have all expressed a reluctance to let people fiddle with too much with advanced LaTeX/TeX settings from within the nbconvert environment.

But I could imagine having something that is less intense than a full new template/preprocessor/exporter class setup to be able to get access to these kind of features in a reproducible way. Basically the problem I see with not letting people do a bit of this kind of stuff within nbconvert is that it just is adding steps to the workflow, where nbconvert could/should be removing them by making whatever changes are regularly being made to the document more reproducible.

I'm thinking that we could begin to define a way – for LaTeX templates at least – to have a file that can be included in the vein of an environment.yml or a requirements.txt file that could make changes to (at least) the preamble of a document, that would (for example) allow you to replace \usepackage{geometry} with \usepackage[a4paper]{geometry}.

There's an easy way to do it that I could see being perilous to actually work with, where it actually postprocesses/filters(I'm not sure which) the LaTeX file and finds and replaces instances of one string of text with the other. However, I worry that that would be subject to injection attacks if someone were to be uncareful with where they source their files from.

If we wanted to insert commands where there are none, we could include a line %insert-preamble-code-here which could be specially detected, is unlikely to be used by anyone not writing documentation for this feature in any other case, and thus would act as a landmark to use when deciding where to insert preamble code.

In the meantime, I would just recommend converting to LaTeX and then manually changing the geometry call in the LaTeX document before compiling it with XeLaTeX yourself. It's not the prettiest solution, but unless we have some other handle into the declaration statements that's going to be the next best thing.

[jonaslb]

Regarding xcolor changing the paper size - I agree that this seems undocumented. But no, I can't point you to the point where this happens in the code, because honestly I find tex code (as complicated as that) to be entirely unreadable. But it's really easy to reproduce with a minimal working sample, assuming you have a4 as the default. I tested it with pdflatex and xelatex from texlive 2016.

\documentclass{article}
\usepackage{xcolor} % Comment out for effect.
\begin{document}
This document is set as A4 by default on my system, but with the xcolor package, it produces paper in another format (probably letter).
\end{document}

Exporting to LaTeX, manually editing, and then compiling has been my workaround for now. And it works fine, of course. I am merely slightly annoyed that I cannot simply click File -> Download As -> pdf via Latex, because it produces incompatible paper (it's small, so I don't care too much about custom styling).

Perhaps it would be possible to use the locale standard module? I know that on my system, it gives

>>> locale.getdefaultlocale()
('da_DK', 'UTF-8')

From Wikipedia, only US and Canada uses letter - so it might be relatively simple to implement some sort of switch based on this?

[Carreau]

That's I think, a place where custom templates published on PyPI and registered through entry-points could be useful.

I personally agree that A4, Metres, Celsius (Kelvins?), Liters, day/month/year should be the default,
but should not be changed in minor revisions.

Having a default that change depending on locales is a recipe for nightmare though.

[mpacer]

@Carreau You're right that it's probably easiest to solve this particular issue with a custom template and entrypoint given the current setup. But that's a lot of work to just change the page size of the output pdf file. We should be able to accommodate something like this more easily than that.

On all of the unit default…does the notebook encode any system for metrics (even imperial units?)? Why would it need to decide whether Celsius is default? I'm guessing you were joking around, but…seriously lets not touch the units problem in LaTeX here. Unless we want to reduce everything to scaled points…

I happen to like the Ax system because of its use of the silver ratio, but I'm going to guess that it just shouldn't be made the default given the rarity of this request and the size of the user base that is already (quietly) happy with letter as a default.

And if we're going to be changing date defaults, clearly it should be to ISO 8601 Week #-day of week(Monday 1–Sunday 7)-year and not / but - to avoid any file path issues that can arise if people put dates in file names.

[mpacer]

Also I agree having defaults based on locales is basically the software equivalent of scaphism(https://en.wikipedia.org/wiki/Scaphism), in that it is more or less inviting the worst kinds of bugs with honey and then waiting for them to do their worst to the victim.

[jonaslb]

Paper format is considered a locale setting in other places though. On Ubuntu, I can type locale and get an entry for LC_PAPER. I assume this is what most printing applications follow. They allow this to be changed of course, but they will default to a4 like they should.

About the date format (although it's probably irrelevant), I don't know if you're joking because I've never seen the weeknumber-notation form of ISO 8601, so it seems odd that someone would prefer it. The regular 2016-09-31 format is everywhere though.

[mpacer]

@jonaslb I assumed @Carreau was joking a bit since most of those weren't relevant to the notebook.

And since you asked…
The week number thing was mostly a joke…but it is a personal hobby horse, but there are good reasons for preferring it it mostly related to human cognition as it interfaces with formal timekeeping systems, particularly with an eye toward local (subyear) mental time keeping analysis:

• most people have weekly based schedules (so knowing the day of the week rather than the absolute day can be useful for remembering context)
• its good for financial bookkeeping
• its good for personal goalkeeping as weeks tend to be the right level of abstraction along which to plan for things (errors are kept small while still allowing for global level planning and backwards looking analysis)
• every week is identical and there's no need to remember which months have 30 vs 31 days
• it is easier to calculate the exact number of days between two dates (as long as they're in the same year)
• it is easier to remember (within a year) where events were relative to each other with greater precision because the major unit is a week and not a month (thereby also making the major unit actually the same)
• it is easier to calculate conversions between (most) date systems because there is no inequality between the major units — most major calendars (though not all) use a 7 day week (not true for months)
• after the 12th week it has no chance of being mistaken for a month/day format
• after the 31st week it has no chance of being mistaken for any kind of format based on months,

There also is the distinction of leading with year versus leading with week number. My general approach is to lead with week number for everything that is relatively active and lead with year number for everything that is archival or meant to be referred to across years.

… I can go on but that seems enough to explain why someone would prefer it.

[mpacer]

I don't know about Windows or other *nix systems, but locale doesn't include LC_PAPER on OS X 10.11.6, so I'm not sure whether most printing applications that work across those operating systems follow that since it may not exist by default.

[isarandi]

Any progress on this? Basically all of Europe uses the A4 paper size.

[MSeal]

No one is working on this atm. Someone would need to make some contributions to the pdf exporter to support page layouts as a configuration options. I've tagged this as help wanted to try and get more attention for someone who wants the same and is willing to put time into implementing.