search

sile-typesetter / sile

The SILE Typesetter — Simon’s Improved Layout Engine
https://sile-typesetter.org
MIT License
1.68k stars 99 forks source link

Refactor how grid typesetting is calculated #748

Open alerque opened 4 years ago

alerque commented 4 years ago

The current grid package is a hack by feeding special leadings depending on previous content. In cleaning this up using new length metrics I've fixed a number of bugs such as the grid debug lines not matching the frame, but I've refrained from changing the basics of how it works.

Why is this not coded as a replacement for boxupNodes() and/or pageBuilder(). It seems like the current system is pretty restrictive as far as what can be aligned to the grid and what can't.

If nothing else, we're currently assuming only glue stretch and that boxes never do. That's probably not an assumption we want to keep baking in.

simoncozens commented 4 years ago

When would vertical boxes stretch? I'm not saying they wouldn't, especially in a variable-fonts world, but I don't think our frame builders are constructed for that possibility.

I can see the appeal of rewriting it in terms of boxupNodes/pageBuilder. Rewriting the previous leading seemed like the minimally intrusive way of doing things - my idea was to essentially trust the default typesetter as much as possible and then "nudge" content onto the grid - but I would be interested to see how a different approach works out.

alerque commented 4 years ago

One thing I've been thinking about is the need to wrap stacked vertical content in a "group" (think TeX's mdframed and friends) that might get visual decorations, might get split across frame breaks, etc. This brings the possibility of a vbox containing not only other vboxes but of having vglues and hence stretch/shrink.

And yes, variable fonts is another place that might be introduce stretch/shrink to boxes instead of just glues.

I don't plan on rewritting this right away, but when I was cleaning it up it really felt like the code was in the wrong place. The extensive amount of code repeated in the included findBestBreak() was another thing that felt "off". Lets keep this issue around for now to track ideas on this and the resolution if we even do try to refactor this (successfully or otherwise).