Mechanism for rounding margins to integer number of pattern repetitions
duetosymmetry opened this issue · comments
@mcnees showed that this can be achieved using the tikz library 'math', which has a floor() function. We would want to enhance the \GP@setpattern macro so that it records code for computing the selected pattern's unit horizontal and vertical length (which is different from the side length in #8, but can be computed from it). We need to decide on the logic for when the package overrides the margins to try to get to an integer number of reps. This could just mean having a (void) option, e.g. 'integerbody' or some better name.
I imagine three variants of this that might be relevant.
- Integer number of repetitions such that the full grid does not intrude on the user-defined margins. For instance, if the user wants to print but can't do full bleed and must keep the grid within the area their printer can cover. Or if they have to strictly obey margins set by the house style for a journal. Use the floor calculation for this.
- Integer number of repetitions that may go slightly over the user-defined margins. If the user wants to stay close to margins but wants to maximize the size of the grid. Use the ceiling calculation for this.
- Integer number of repetitions that come closest to user-defined margins. When the user has an idea of what margins would look best for their use case, and wants to get as close as possible (either above or below) with a whole number of pattern repetitions.
Ok, with these three possible modes (potentially named integerboxes=floor, integerboxes=ceil, or integerboxes=round), we have to consider the logic of whether or not to override the margins. The option could also be unspecified. Should it have a default action?
What do you think should be the behavior with various combinations of specifying or not specifying geometry= and integerboxes=?
I would call the options something like integerboxes=inside , intergerboxes=outside, and integerboxes=nearest. That should make the meaning clear: Use the largest number of an integer number of boxes that stays inside the specified or default margins, use the smallest number of integer boxes that go past the margins, or use whichever option comes closest to the margins.
This seems like an option that a user would only invoke with the intent of overriding the margins, so the default (false) leaves the specified or default margins untouched. Any other option overrides the specified or default margins (unless they already fit an integer number of boxes).
If the user specifies geometry= we obey the margins strictly. If they specify geometry= and also integerboxes= we replace the margins with margins computed for that option.
I have the basics working on my branch feature/integerboxes. However, interfacing with the geometry package is tricky. Using the \geometry command like we have so far simply appends more and more options. This means our request to the package can become over-specified -- for example if the user specifies a page size and a margin size, then we compute the appropriate textarea size and request it. The geometry package processes the specifications in order and stops once it gets page size and margin size, because textarea size is known after these two. Asking for a new textarea is an over-specification.
Thoughts?
Can we call the \newgeometry command after recomputing the margins? That should override all the options that the package was given initially.
See section 7 of the geometry package documentation.
The version 5 provides the new commands \newgeometry{···} and \restoregeometry, which allow you to change page dimensions in the middle of the document. Unlike \geometry in the preamble, \newgeometry is available only after \begin{document}, resets all the options ever specified except for the papersize-related options: landscape, portrait, and paper size options (such as papersize, paper=a4paper and so forth), which can’t be changed with \newgeometry.
I guess we would have to make \newgeometry{options} one of the first commands. If I put
\AtBeginDocument{\newgeometry{margin=0.5in}}
right after the call to pagecolor, then the package draws the grid with these margins instead of the margins originally passed to the geometry package. So I think if we call this with the newly computed margins it will handle everything correctly.
- Related to how to use
\geometry{}, I think our current approach of setting the pattern's default geometry, and then further applying the user specified geometry is also incorrect. - I can see that we would get the margins right with your proposal. I think I have to read the docs for the geometry pattern to see what other kinds of things the user might pass -- and if they will all end up being ignored if we use
\newgeometry(which is my reading of the text you quoted)