Questions related to document layouts.

[no-vici]

Hi again,

I've been diving into your code for ratio based layouts and found a few things that make my head spin. I hope you won't mind helping me clear the mist.

Parsing for the division layout in the layoutParse states that:

...
local number = SILE.parserBits.number
...
division = P("division")
    * (
      (ws * number * ws * number)
      + (ws * number)
      + (lpeg.Cc(9))
    ) / function(n, ratio)
    local layout = require("resilient.layouts.division")
    return layout({ n = n, ratio = ratio })
  end

I went into Lpeg document and found:

lpeg.Cc ([value, ...]): Creates a constant capture. This pattern matches the empty string and produces all given values as its captured values.

You used lpeg.Cc(9), so this returns 9. So what is the meaning of (ws * number * ws * number) + (ws * number)? I know the ws bit but not the number and the previous combination.

The function(n, ratio) returns layout({ n = n, ratio = ratio }), so n = 9 and what is the value of ratio? Is the value of ratio obtained from division.lua and it would be 100%ph / 100%pw?

Thank you for your valuable time.

[Omikhleia]

Er. LPeg is hard and I am not always sure I got it right.
This being said, here, the "+" between the expressions being a "or" alternative, I want to parse:

• division N r --> n = N, ratio = r (explicit values for both, i.e. the ws * number * ws * number case),
• or division N --> n = N, ratio = nil (the one-number case ws * number; and this, later in the logic, means we will indeed use the page ratio (100%ph / 100%pw) in that case),
• or division --> n = 9 (as a default), ratio = nil (i.e. the lpeg.Cc(9) case; and same as above regarding it).

Does it make sense?

[no-vici]

Would the added figure help here?
Yep, this is very helpful! Thank you. The manual I printed a while ago did not have 1.4 section, it stops at 1.2.4 The legacy layout. So for dimen, could it be %pw or in pixels?

[Omikhleia]

So for dimen, could it be %pw or in pixels?

Could be anything, but these are usually specified in inches or mm

For instance, here is a table from Lulu.com

I could add such a table, but the values really depend (other print-on-demand services would recommend other values, and there's also different tables depending whether the book is a hardback or a paperback, etc.) -- It's at best indicative ^^ and Lulu here is very cautious (real big values IMHO). E.g. for an "ateliers demiluxe" layout, I'd likely use at most 0.25in rather than their suggested 0.5in for 300+ pages... It does seem sufficient to me, but these things are tricky.

[no-vici]

Thank you for explaining the «dimen» clearly.

You are right, those recommended figures are quite tricky. I had to used smaller numbers.

[Omikhleia]

You are right, those recommended figures are quite tricky. I had to used smaller numbers.

Yes :) The problem, I would guess, for many print-on-demand services is that they offer various paper sizes, various paper quality (thickness), and various binding methods: paperback binding, hardcover binding... and some even have coil binding---and those coils are going to eat a whole lot of the inner margins! So they won't detail all possible issues depending on all possible cases, but will just recommend pretty wide margins 🤣

[no-vici]

... and some even have coil binding---and those coils are going to eat a whole lot of the inner margins!

Mine was ring bound, not much room left from the text body ;)

Thank you once again for your valuable time and patience.

Cheers.

[Omikhleia]

Thank you once again for your valuable time and patience.

You are welcome! I'll probably tag a 2.0.1 release soon, so anything that can still make it in that milestone is great. I created an issue #39 to take into account the proposed clarifications on the offset.