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

[Julian Reschke <[e-mail]>]

Am 28.10.2020 um 12:07 schrieb Julian Reschke:
> 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

FYI: in the meantime, both tickets have been closed as "wontfix".

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