Omikhleia
commented
2 years ago Instead of opening a new issue, I'll provide my experimenting results here, since it seems pretty well related with the issues I am facing and the things a refactor might need to address. I hesitated with #385, also somehow related, but which seems more specific.
I am trying to have 3 (two-side) master sections than can be switched anytime in the course of a book:
- The main (right, left) masters which correspond to the default regular book pages
- The (tworight, twoleft) masters for a two-columns layout: the use case for it is, after regular pages, to have a two-column lexicon or an index.
- The (landright, landleft) masters where the content (and ideally the footnotes, but see below) are rotated: the use case for it is for wide (possibly multi-page) tables (chronologies etc.) that wouldn't fit well on a portrait page.
Expected layout design illustration:
I can alleviate some constraints, for clarity:
- Just to keep it clear, it is acceptable to change masters on a new page (i.e. I don't need, esp. regarding the two-column case, switching between these layouts in a same-page flow).
- In the two-column case,
- It is acceptable for footnotes to be in the second column only. In this scenario, footnotes would not be recommended (and endnotes are indeed preferable in such cases), so a "degraded" behavior is ok for minimal support of a few footnotes. I.e. I don't really care what happens at the end of that section or if footnotes are so long that they fill the column.
- Eventually, balanced columns would be ideal, but I propose ignoring them for now (I tried and failed, but this is still minor regarding the expected layout and I understand the balanced-frames package is still experimental).
- In the landscape case,
- I have no idea if the footnote frame can be rotated as shown in the above design and if the insertions module can "steal" space as expected. I propose to alleviate that requirement for now and let the footnotes live at their usual "bottom" place above the folio...
- The mirrored content frames in the design are rotated so that to be always oriented towards the spine of the book. Let's admit this is debatable and accept alleviating that requirement.
This being said, I tried to make a MWE and encountered a number of issues. You'll find attached a "bare" class and example attached, where I annotated "HACK" each of the problem I somehow solved in weird ways.
Those "HACKS" don't feel very natural to me, but I eventually succeeded in having the one-column / two-column switching ok (pages 1-6). I am still failing with landscape switch (I just rotated here the content frame by a small angle, not 90°, to better see what happens)
- Page 7-8 show the expected rotation... but folios disappeared! (EDIT: They are there without the rotate declaration on the "content" frame, so it's clearly related with it.)
- Page 9 (expected to be back in normal portrait layout) gets wholly rotated (not just the content!)... But hey, it has its folio^^
- EDIT (noticed later): page 9 also has a weird foonotes frame height.
I am stuck there - so may some other eyes can be involved and help making this work...
alerque
The use of a module variable is going to produce a stateful action that might trip us up later in the event two or more typesetters are working on different places in a document. Rather than wait for bugs to crop up in usage this should be moved into the current typesetter or class state to just avoid those surprises.
As noted in comments the implementation reaches far too deep into other code for comfort.