mbutterick / typesetting

document-layout tools [mirror of https://git.matthewbutterick.com/mbutterick/typesetting]
https://git.matthewbutterick.com/mbutterick/typesetting
MIT License
33 stars 2 forks source link

footer customization #14

Open mbutterick opened 5 years ago

mbutterick commented 5 years ago
odanoburu commented 4 years ago

what are your plans on this? I'm missing a way of specifying a footer that includes the page number (it is not possible to so yet, right?)

mbutterick commented 4 years ago

The current default footer includes the page number. The footer-display attribute controls whether it’s hidden or shown. Where I’m stuck is customizing the other fields, without introducing a bunch of special-purpose attributes like footer-display-date-format-days etc. I think the footer needs to become a special case of a more general facility for specifying elements that are repeated on each page.

odanoburu commented 4 years ago

I see the problem… one solution that comes to mind is to introduce a few more special quads (currently the break quads are special, right? in the way that they ignore the text inside them, for instance)

we could have a special quad for current-page number; if we had something like

#lang quadwriter

'(q ((footer-display "false"))
    "We are at page "
    (q ((current-page-number "")
        ;; because quad doesn't accept attributes without values
        ))
    ".")

I don't think it's very elegant, but maybe it's just the syntax (special quads could have special syntax?).

the same idea could be used for other things like getting the current position in the page (which might be useful for links? have no idea how internal PDF links are implemented; does quad already implement them?)

mbutterick commented 4 years ago

It makes more sense to do it that way than to have some magic string like __$$PAGE_NUMBER$$__ that gets replaced. Though I would probably do it this way:

(q ((meta "current-page-number")))

Or maybe ref is a better attribute name than meta. But that way, similar values could also be grouped under that attribute.

One reason I’ve put off this problem is that it introduces another complication, which is circular references: the page breaks depend on the layout of the text, but in this case part of the text (= the literal page number) is not known until the page breaks are calculated. I don’t know how text processors ordinarily handle this. I suppose the “magic” quad should just have a width imputed to it of, say, 2–3em, on the idea that probabilistically, that’s accurate, and any error won’t be that noticeable in context.

odanoburu commented 4 years ago

Though I would probably do it this way:

yes, that's much better!

I don’t know how text processors ordinarily handle this.

I think (La)TeX assumes some width and updates things (if needed) whenever it gets rerun. but I don't really know the details, I'll see if I can learn more…