no objection to this change.
On 28.06.25 04:19, Daniel Kahn Gillmor wrote: > On Fri 2025-05-30 19:53:47 -0400, Daniel Kahn Gillmor wrote: >> On Tue 2025-05-20 18:07:44 -0700, rfc-edi...@rfc-editor.org wrote: >>> 27) <!--[rfced] We note that the figures in the sections listed below are >>> either misaligned and/or have broken lines in the PDF output (the >>> html and txt outputs display correctly). To avoid this issue, >>> please let us know if replacing/redrawing the non-ASCII >>> characters with ASCII characters is possible (this is commonly >>> done for structure in YANG trees; see Section 5 of RFC 9731 as an >>> example). Or if you have a different solution for a fix, please >>> let us know. >>> >>> Sections: >>> 4.1.1.1 >>> 4.1.2.1 >>> 4.1.2.2 >>> 6.2.1.1 (second structure) >>> 7.3 (both structures) >>> --> >> This is appears to be a bug in XML2RFC's PDF converter when a line >> begins with whitespace followed by a non-ASCII character. >> >> I've opened a report for xml2rfc, please feel free to follow up there: >> >> https://github.com/ietf-tools/xml2rfc/issues/1245 > The discussion at this ticket uncovered a few different things which i > didn't know: > > - according to Kesara, the RPAT/RSWG claim that the only fonts in use in > the pdf form should be Noto and Roboto Mono. > > - Roboto Mono has no coverage for BOX DRAWINGS characters or ↧ or ⇩ > > - Noto Sans Mono does have coverage for BOX DRAWINGS, but not for ↧ or ⇩ > > - Noto Sans Mono is fixed width at nearly exactly the same width as > Roboto Mono, making it a reasonable substitution. > > - With a small tweak to xml2rfc [0] it should be simple enough to have > monospace fonts fall back from Roboto Mono to Noto Sans Mono for > glyphs that aren't covered in Roboto Mono. > > [0] > https://github.com/ietf-tools/xml2rfc/pull/1261/commits/00dae3832b3583099a1a92c7048eeeff102243d2 > > I propose replacing ↧ and ⇩ with symbols from the BOX DRAWINGS range > instead. > > The attached proposed XML file makes this substitution for the MIME tree > diagrams. It will still render as misaligned, however, as long as the > fix [0] is not applied to xml2rfc. > > If you think this is reasonable, let me know and i can try to make a > comparable revision for RFC 9788. > > --dkg >
sender_key.asc
Description: application/pgp-keys
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
