feat: option to make folio on left if even and on right if odd

[jodros]

No description provided.

[alerque]

I like the feature and we should definitely support some way to handle this out of the box (since our currently documented "easy" way doesn't actually work). But this approach is just a bit too naive. In a RTL document where the writing direction is reversed, the "mirrored" pages are also the opposite of what most LTR readers expect: in a bound books odd pages are on the left and even pages are on the right.

[jodros]

Would this solve the point?

      local ltr = (SILE.settings:get("font.direction") == "LTR")
      local evenPage = (SILE.scratch.counters.folio.value % 2 == 0)
        
      if (ltf and evenPage) or (not ltr and not evenPage) then
        SILE.call("raggedleft", {}, content)
      else
        SILE.call("raggedright", {}, content) 
      end

[alerque]

Maybe. I haven't looked into when/where this is typically set vs. when/where this would be trying to read it. Also it would be complicated in a mixed-language environment. For example how would this folio function cope with a master frame layout for a parallel English/Arabic text with balanced frames? I'm wondering if a more robust setting might not be just to call out weather the "right" and "left" alignments should be on odd or even pages directly without trying to guess from the direction settings of the typesetter at some random point or some frame when there might be other considerations. Also what if people want to use the mirroring but just have a layout that is flipped from this expectation? Maybe they want their page numbers on the inside instead of the outside.

Thinking out loud here, but I'm leading towards a more explicit setting rather than trying to guess.

[Omikhleia]

It might be confusing too, if the folio frame doesn't span the whole page in some layouts (left/right mirrored alignment applying to the frame content regardless of its actual position) -- But I don't really know either, yet, what would be a proper way to better define it.

[alerque]

In almost all cases that my pea brain on 2 hours of sleep can think off off the cuff, if the folio frame does not span the whole page then almost certainly centered is going to be the wrong expectation. In those cases being aligned to one side or the other seems like it would be expected.

This does bring up an interesting issue we have with odd/even headers as well. Mirroring the frame isn't enough to reflect the design, we also have style functions that vary for different sides (in the case of headers, sometimes also for content of course but that's different).

I'm even more convinced today than I was yesterday that we shouldn't be guessing at all and should just take some explicit option. But is it possible we have some property of the frame itself that could be used for a typesetter to derive the intentions while also allowing the masters package to mirror it?

[jodros]

Of course this wouldn't work for documents with multiple columns, since it's just a draft... But that's one of the tests to be made as well, right?

 if SILE.frames.folio:right() == SILE.frames.content:right() and
    SILE.frames.folio:left() == SILE.frames.content:left() then
    ...

[jodros]

There's another type of folio mirroring that isn't being covered here.

What if the user make a folio this way, and instead of just switch from left to right, since in this case the mirroring would be handled by mirrorMaster(), the folio.mirror could align to the top or to the bottom according to given parameters...

[alerque]

I think we've opened a can of worms here (in a good way). We have a frame property for direction already, but TTB/BTT/LTR/RTL all have to do with writing system orientations. We also have those things in relation to the typesetter itself and font shaping.

We also have typesetter features for handling alignment (ragged, vfill, hfill, etc). The missing piece os some hint in frame properties about alignment that can be (optionally) used by the typesetter to align things. These hints could be used to set various properties to fulfill the goals of the layout without baking the bits into the content. In other words in place of having to add various layout artifacts to the content (thing prefixing some content with a \vfill to get a vertically centered block) a layout could be designed with frame alignment properties:

• vertical: top / center / bottom
• horizontal: left / center / right

With a special caveat that the values would be reversed by TTB/RTL frame types, these values attached to the frame could be referenced in, for example, the enter-frame and leave-frame hooks to add appropriate spaces and the typesetter to pick starting margins.

Then when we mirror frames, the properties can be reversed and all the layout will adjust. We might also need a boolean property for whether to mirror the alignment properties of a frame or not (for example the main content frame would probably not be mirrored while the folio frame or running headers might be mirrored by default).

Does this sound sane to anyone else?

Sorry if this is pushing a simple PR into "fix the world" territory, but I think it may be worth fixing this for real instead of just barely getting by for some select scenarios.

[jodros]

Indeed, there are more things to be done here than I thought when created the PR so we must keep discussing this point to have a full solution, maybe I should've created a discussion instead of a PR first.

@alerque By the way I'd like to know what you think about the other proposals I wrote there recently, mostly that about frame declaration, which I already have a PR ready to be made...