Martijn, Thank you for pointing this out. This issue in the PDF has been corrected; please see https://www.rfc-editor.org/authors/rfc9639.pdf (page 62).
The fix (to get the PDF to match the TXT and HTML) involved incrementally updating the XML source file to pinpoint when the bug rears its head, and then deleting the words "as follows" (this minor change is visible in the last diff file, which shows only the most recent changes to the text file): https://www.rfc-editor.org/authors/rfc9639-lastrfcdiff.html The files are here: (please refresh) https://www.rfc-editor.org/authors/rfc9639.txt https://www.rfc-editor.org/authors/rfc9639.pdf https://www.rfc-editor.org/authors/rfc9639.html https://www.rfc-editor.org/authors/rfc9639.xml All changes from the approved I-D: https://www.rfc-editor.org/authors/rfc9639-diff.html https://www.rfc-editor.org/authors/rfc9639-rfcdiff.html (side by side) Please confirm before we continue the publication process. For more specificity, screenshots are available below. Thank you. RFC Editor/ar -- Before the fix (HTML vs. PDF - they do not match): https://www.rfc-editor.org/authors/rfc9639_p62_before.png After the fix (HTML vs. PDF - they match): https://www.rfc-editor.org/authors/rfc9639_p62_after.png > On Dec 12, 2024, at 7:00 AM, Martijn van Beurden <mva...@gmail.com> wrote: > > Hi Sandy, > > Looking it this one more time, it seems the PDF still doesnt render > correctly. In the spelling out with all the code points, it seems the > characters are spelled out right to left instead of left to right. The PDF > differs from the HTML and TXT in this respect. > > The HTML says somelike like > > where in direction of reading, the sequence of characters forming the field > content is as follows: character 1, character 2, character 3, character 4. > > The PDF says something like this: > > where in direction of reading, the sequence of characters forming the field > content is as follows: character 3, character 2, character 1, character 4. > > This seems like a tooling issue. > > Kind regards, Martijn van Beurden > > Op do 12 dec 2024 08:43 schreef Martijn van Beurden <mva...@gmail.com>: > Hi Sandy, > > This looks great, I approve. Many thanks for incorporating, and improving on, > my suggestion. > > Kind regards, Martijn van Beurden > > > Op do 12 dec 2024 00:36 schreef Sandy Ginoza <sgin...@amsl.com>: > Hi Martijn, > > Thank you for your review. We have updated the document and posted the files > here for your review: > https://www.rfc-editor.org/authors/rfc9639.xml > https://www.rfc-editor.org/authors/rfc9639.txt > https://www.rfc-editor.org/authors/rfc9639.pdf > https://www.rfc-editor.org/authors/rfc9639.html > > Diffs of most recent updates only: > https://www.rfc-editor.org/authors/rfc9639-lastdiff.html > https://www.rfc-editor.org/authors/rfc9639-lastrfcdiff.html > > AUTH48 diff: > https://www.rfc-editor.org/authors/rfc9639-auth48diff.html > > Comprehensive diffs: > https://www.rfc-editor.org/authors/rfc9639-diff.html > https://www.rfc-editor.org/authors/rfc9639-rfcdiff.html > > Please review and let us know if updates are needed or if you approve the RFC > for publication. > > Thank you, > RFC Editor/sg > > > > > On Dec 7, 2024, at 4:05 AM, Martijn van Beurden <mva...@gmail.com> wrote: > > > > Hi, > > > > Op vr 6 dec 2024 om 22:33 schreef Sandy Ginoza <sgin...@amsl.com>: > >> > >> While troubleshooting, we were advised not to mix LTR and RTL scripts > >> within the same <t> element and to include explanatory text that uses the > >> <u> element. > >> > > > > I can see why this is problematic. For that very same reason it is > > very useful as an example of course. Thank you for taking the time to > > address this. > > > >> > >> We have updated the file to be more similar to RFC 9290 (which also uses > >> “שלום") — "TITLE=שלום” now appears in artwork and is followed by the > >> following explanatory text: > >> > >> where in direction of reading, the sequence of characters is: > >> "ש" (HEBREW LETTER SHIN, U+05E9), "ל" (HEBREW LETTER LAMED, U+05DC), > >> "ו" (HEBREW LETTER VAV, U+05D5), "ם" (HEBREW LETTER FINAL MEM, U+05DD). > >> > > > > While this explains the part in Hebrew, it omits the Latin part. I > > think this should be noted. I propose the following change > > > > OLD: > > where in direction of reading, the sequence of characters is > > > > NEW: > > where in direction of reading, the sequence of characters forming the > > field content is > > > > I am not entirely sure whether 'forming the field content' is the best > > possible phrasing here. Feel free to propose something else, I just > > think that it is useful to mention that this 'spelling out' concerns > > the field content, not the field name nor the separator (see section > > 8.6 for details on these terms) > > > > I hope this proposal isn't too much trouble. > > > > Kind regards, > > > > Martijn van Beurden > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
