[Xml-sg-cmt] <u>: Re: AUTH48: RFC-to-be 9290 <draft-ietf-core-problem-details-08> for your review

[Sandy Ginoza <[e-mail]>]

Hi Thomas and Carsten,

I’m including a few others on this mail in case they have suggestions regarding how to get the desired output.  

I believe the inclusion of the Hebrew string with <t> requires the use of <u> (and its output - afaik, there is no way to get the non-ASCII string only).  I updated the doc to use <artwork> for “שלום”, but the text output is odd in that the string appears on the far right of the page - perhaps another application-specific issue.   Though not the prettiest, the display seems ok in the HTML and PDF files.  Any thoughts on how to get the desired output with the understanding that the discussion about allowing UTF-8 more liberally throughout likely requires RSWG discussion and consensus?  

> > NEW:
> > The following example shows how the Hebrew-language string "שלום" is
> > represented, 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). Note the rtl direction expressed by setting the third element
> > in the array to "true”. 

The files are available here: 
   https://www.rfc-editor.org/authors/rfc9290.txt
   https://www.rfc-editor.org/authors/rfc9290.pdf
   https://www.rfc-editor.org/authors/rfc9290.html
   https://www.rfc-editor.org/authors/rfc9290.xml

Diffs of the most recent updates only: 
   https://www.rfc-editor.org/authors/rfc9290-lastdiff.html
   https://www.rfc-editor.org/authors/rfc9290-lastrfcdiff.html (side by side)

AUTH48 diff: 
   https://www.rfc-editor.org/authors/rfc9290-lastrfcdiff.html

Comprehensive diffs: 
   https://www.rfc-editor.org/authors/rfc9290-diff.html
   https://www.rfc-editor.org/authors/rfc9290-rfcdiff.html (side by side)


Thanks!
Sandy 



> On Sep 1, 2022, at 1:10 AM, Carsten Bormann <[e-mail]> wrote:
> 
> Hi Sandy,
> 
> 
>> On 31. Aug 2022, at 23:15, Sandy Ginoza <[e-mail]> wrote:
>> 
>> Hi Carsten,
>> 
>> Note that this is my fault as Megan is on vacation.  I delayed replying while we tested the updated version of xml2rfc to correct the PDF display of the Hebrew string.  It seems the PDF glitch (issue #873) has been fixed - please confirm, as our copy (from PDF) & paste experience is not what we expect.
>> 
>> See https://www.rfc-editor.org/authors/rfc9290.pdf
> 
> This indeed looks good now.
> 
>> Regarding the example from A.3 in the attached screenshot.
>> At this point, 2 questions:
>> 
>> 1) Does it seem odd to you that the source file (rfc9290.xml) contains the string in the reverse of how it is rendered in the publication formats? To be exact:  
>> The desired string: שָׁלוֹם 
>> (which we see in the TXT, HTML, and PDF)
>> The reversed string: םולש
>> (which we see in the sourcecode elements and u element of the XML file)
> 
> I’m not sure I’m seeing the same here you do (see screenshot below).  But that is pretty natural in this space...
> 
> The HTML (and thus PDF) publication formats pick up the “strong directional” nature of the Hebrew characters and switch to RTL rendering.
> This is certainly odd to readers that are not familiar with mixed LTR/RTL rendering, but it is the way the RTL writing systems operate.
> 
> Whether your plaintext editor picks up RTL information from the characters or not depends on the editor.
> If it does (e.g., Emacs does), moving the cursor *forward* (often done with the cursor-right key) may go *left* on the Hebrew part, which is the telltale sign of RTL support.
> (If the editor tries to hide the RTL presentation by stepping you in geometric sequence, like the Apple Mail compose editor does, selecting a part straddling the RTL/LTR boundary may be the only way to tell.)
> 
>> 2) For clarity, would it sense to walk through the string character by character, or do you prefer the current form? In other words, what do you think of changing from
>> string (names, nums)
>> to
>> char (name, num), char (name, num), char (name, num), char (name, num)
>> For example, please see:
>> https://www.rfc-editor.org/v3test/rfc9290_A3test.html#appendix-A.3-7
> 
> I like the direction [pun not intended] of this change.
> 
> But I would like to make it clear that the sequence of writing the characters is orthogonal to the presentation as LTR or RTL text:
> 
> OLD:
> The following example shows how the Hebrew-language string is represented, where in the rtldirection, each character is: "ש" (HEBREW LETTER SHIN, U+05E9), "ל" (HEBREW LETTER LAMED, U+05DC),"ו" (HEBREW LETTER VAV, U+05D5), "ם" (HEBREW LETTER FINAL MEM, U+05DD). Note the rtl direction expressed by setting the third element in the array to "true”.
> 
> NEW:
> The following example shows how the Hebrew-language string "שלום" is represented, 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). Note the rtl direction expressed by setting the third element in the array to "true”.
> 
> Because of the brutal way in which xml2rfc enforces its narrow understanding of RFC 7997, you may need to push the first “שלום” into artwork (which would allow getting rid of the quotes).
> 
> Grüße, Carsten
> 
> <PastedGraphic-1.png>
> 
> 
>> 
>> 
>> Thank you. 
>> RFC Editor/sg
>> 
>> <Screen Shot 2022-08-31 at 1.37.02 PM.png>
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Aug 31, 2022, at 7:34 AM, Carsten Bormann <[e-mail]> wrote:
>>> 
>>> Megan,
>>> 
>>> let me briefly note that our two approvals have not made it yet to https://www.rfc-editor.org/auth48/rfc9290 — just in case this is slowing down the process.
>>> 
>>> Grüße, Carsten
>>> 
>>> 
>>>> On 2022-08-23, at 11:04, Thomas Fossati <[e-mail]> wrote:
>>>> 
>>>> On Monday, 22 August 2022 at 22:45, Carsten Bormann <[e-mail]> wrote:
>>>>> After repairing the PDF glitch and the typo, and possibly addressing
>>>>> the above nits, I believe that RFC9290-to-be will be ready for
>>>>> publication.
>>>> 
>>>> +1
>>>> 
>>>> Cheers, t
>>>> 
>>>> 
>>>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>> 
>