[rfc-i] An attempt to summarize the "page numbers in ToC" situation

[Julian Reschke <[e-mail]>]

Hi there.

So the RPC currently produces three output formats:


1) Plain text

Plain text is not paginated, and that's intentional.

Paginated output in xml2rfc is supported, but turned off by default when
producing RFCs.


2) PDF

PDF is paginated, but currently lacks page numbers in the ToC. I
consider this a defect, and opened
<https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/558>.


3) HTML

HTML can be paginated, for instance when printed. There is CSS support
for controlling headers and footers, and generating page numbers.
Unfortunately, this is not supported by browsers (when printing HTML),
but there *are* tools implementing this.

rfc2629.xslt has supported this for ages, and I believe xml2rfc should
do so as well. Enhancement request:
<https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/559>.


I believe there is consensus that page numbers can not be used to refer
to parts of an RFC. xml2rfc generates stable paragraph/table/figure
anchors both in HTML and PDF (see, for instance
<https://www.rfc-editor.org/rfc/rfc8905.pdf#section-6-2> and
<https://www.rfc-editor.org/rfc/rfc8905.html#section-6-2>).

Page numbers are indeed useful when something *is* printed. Given the
fact that plain text does not support SVG, I would argue that PDF (or
HTML, with the improvement above) are better suited for printing, so
there really is no compelling reason to change the publishing default
for plain text (well, maybe except to prove that page numbers are
unstable, because they would differ between plain text and PDF).

Best regards, Julian


_______________________________________________
rfc-interest mailing list
[e-mail]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest