2.1 already existing ideas and approaches
Thanh's approach xor approach alternative approach
As the title indicates, an unsorted list of ideas from various sources, together with comments added before or during the workshop.
2.1.1 Thanh's approach
This set of notes (taken from an e-mail) covers Thanh's approach as implemented in a prototype version of pdfTeX.

-------------------------------------------------------------------------
  • snapping: support for grid typesetting. New primitives:
    • \pdfsnaprefpoint: insert a whatsit node representing a reference point
    •  \pdfsnapy: insert a whatsit node that cause the position of the ``drawing pen'' to be moved onto a grid. This happens only during shipping phase.

      Example: after a display math it is difficult to get the next line to be on the grid. With snapping it might look like following:

,--------
|     <text before displayed math>
|     $$ <some math> $$
|     \vadjust pre{\pdfsnapy \snapunit plus .8\snapunit minus .2\snapunit}
|     <text after displayed math>
`--------

\snapunit is a dimen, typically it would be \baselineskip. To make it work, there is one thing more: \pdfsnaprefpoint must be  inserted into each page, typically in header. Let's call the y- position of this whatsit node Y1. The above example says  roughly this: when pdftex reachs the \pdfsnapy node, it can move the drawing pen up and down in range (- .2\snapunit,.8\snapunit) to snap to a point with y-position Y2 so that (Y2- Y1) is a multiple of \snapunit. The \pdfsnapy node must be inserted before the text line following the displayed math, so we use \vadjust pre{...} to insert it (\vajdust with "pre" is an extension of pdftex).
  •    \pdfsnapycomp: insert a whatsit node for snapping compensation
The problem with the previous example is that sometimes the space after math is changed too much, while the space before   math remains unchanged.  Hence the result may look ugly, because the spaces around the math are not proportional. So it is better that the movement after math is somehow compensated into the space before math too. \pdfsnapycomp is for this purpose. The previous example with \pdfsnapycomp will look like:

,--------
|     <text before displayed math>
| \vadjust{\pdfsnapycomp 500}
|     $$ <some math> $$
|     \vadjust pre{\pdfsnapy \snapunit plus .8\snapunit minus .2\snapunit}
|     <text after displayed math>
`--------

So the skip at \pdfsnapy will be distributed to 50% at  \pdfcompsnap and 50% at \pdfsnapy.
\pdfsnapy and \pdfsnapycomp are whatsit nodes, with an exception that they are discardable after a break.
When a page break occurs between \pdfcompsnap and \pdfsnapy,   then \pdfcompsnap has no effect, e.g., the extra space is inserted  at \pdfsnapy only.

-----------------------------------------------------------------

Below is the summary of what I have done in 0.14h:

Node types:
  • pdf_snap_ref_point_node: a whatsit node representing a reference point for snapping; no associated data
  • pdf_snap_x_node: a whatsit node representing a node that can be  snapped in x-direction; has a glue specifying:
  • the basic unit of the ``grid''
  • how much it can be moved left/right

    Example: 5pt plus 4pt minus 3pt -- grid of 5pt for each cell, snap nodes  can be moved as much as 4pt forward (right) and 3pt backward (left). Any 'fill' or higher order means that the movement amount is unlimited.
  • pdf_snap_y_node:    similar, but for y-direction

New primitives:

\pdfsnaprefpoint:    insert a reference point

\pdfsnapx:    insert a whatsit node that can be snapped in x- direction

\pdfsnapy:    similar, but for y-direction

\pdflinesnapx:    specify a snap_x node that will be automatically prepended  to each line after line- breaking=20

\pdflinesnapy:    similar, but for y-direction


Example:
  • have a \pdfsnaprefpoint in each page (e.g., in header)
  • let's assume \baselineskip=10pt; saying somewhere in the beginning

  \pdflinesnapy 10pt plus 5pt minus 4pt

would have the effect to snap every line to a grid with the reference at the location of \pdfsnaprefpoint to the nearest multiple of 10pt, given that the movement amount is in range (-4pt, 5pt).
  • to snap the reference of a box, insert a \pdfsnapy somewhere inside the box so that it ends up at the baseline of the box.
2.1.1.1 issue: happens at \shipout which is probably too late
from Chris:

From my present understanding I can see why he did what he has done, leaving the `snapping' until the last moment and hoping the right things snap:-).  But I am unsure how it will work in practice.  Of course, anything better would really mean throwing out glue as we know it, and then you have to redo Knuthian algorithms ... not a good idea!!   So I guess someone should try using his stuff to see if anything like what they expect happens ... but???
2.1.1.2 comments by Hans H.
i remember that we played with that -)

the problem with snapping is that it can lead to oscillation (i.e. by snapping something, other things get influenced) which is why i put it aside

>New primitives: 
>\pdfsnaprefpoint:
>    insert a reference point
>\pdfsnapx:
>    insert a whatsit node that can be snapped in x- direction
>\pdfsnapy:
>    similar, but for y-direction
>\pdflinesnapx:
>    specify a snap_x node that will automatically prepended
>    to each line after line-breaking
how does this snap fo rlines that are 20% too heigh?

i can imagine something:

line (ht/dp <= optimal)
line (ht/dp <= optimal)
line (ht/dp > optimal)
line (ht/dp <= optimal)
line (ht/dp > optimal)
line (ht/dp <= optimal)

you can either let line 3 and 5 take two lines, or let them take 1.5 lines each which kind of syncs the last line (and next par)

so, some control is needed here for a too high line:
  • - move up or down and accept overlap
  • - center over two lines
  • - center over 1.5 line if the following one is also too high but only on the same page
  • - ...

it's a can of worms -)

there is so much involved (becaue other things may move as well, like marginal notes, floats, whatever);

hm, i need to play with it a bit;another approach is to provide more control over baselines:
  • - force lineheight and depths for each line (we discussed that before) for instance by providing means to set the height depth of first and last lines of boxes (explicit) and paragraphs (mvl, implicit)
  • - if there is a line in a paragraph with more height/depth than the default (+ some threshold), can happen with for instance in line math, then this line should be centered over two lines so that the next line ends up on the grid again;so there you need to feed into into the par/page break handling (at the pdf output level it's too late)
  • - provide more information, for instance, the top of page situation is often messy; there is no real good way to ask how much space is left on the page without invoking the otr, which in itself messes up things (when typesetting on a grid, one needs to make decisions, and it's for instance handy to know what the (accumulated) height is of inserts;
  • - i can probably come up with some more of this
Hans
2.1.1.3 comments by Morten
I know Achim (ANT) experimented with a skyline model for the line spread  which could be very useful for TeX, when people do something like "bla bla  $2^{2^2}$ blub" where a possible descender directly above does not touch the letters below. When typesetting statistics books I often get in trouble when trying to do the common \hat\lambda inline! He also did another model which always snaps to the grid (probably too restrictive for mathematical texts). I saw that Thanh had released a patch with some  \snipsnapsnappy primitive.
2.1.2 xor approach
This is very much simplified look at how xor (the experimental output routine for LaTeX implements grid design using only the functionality available within TeX.
  • grid alignment points are placed as special penalities into the vertical galley
  • on the mail vertical galley they trigger the OR which examines the page so far and adjusts it (thereby freezing any content which becomes rigid)
  • the assumption being that this is okay as normal glue should only adjust itself in places between alignment points so that no later interaction on the page is necessary. valid assumption?

important: adding alignment points need to be suppressible, e.g., a heading need to disable any alignment points inside its title that would interfer with its own typesetting. That was one of the earlier sources of errors.
also important: alignment needs to happen while building the page, it is quite likely that something that TeX considers fitting is no longer fitting when it needs to align near the bottom (ie backing up by a line and taking an earlier page break might be necessary).
2.1.3 alternative approach
what might be an alternative approach is to directly influence the baselineskip calculation and the adding of glue by assuming that a vertical list being build actually lives on a grid at least certain point of that list, at least if at startup of building this list a corresponding data structure is being set up.

questions:
  • how could that work?
  • how does this relate to superglue, if at all?
  • how does one handle lines that are too large and currently are handled by \lineskip?

Comment by Frank: I have no idea who brought this up and when (could have been me).