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
