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

[Sandy Ginoza <[e-mail]>]

Hi Peter,

As always, thanks for your quick reply!  I ended up including the team directly on my reply to Carsten, as we’re unable to get the output he wants.  Perhaps you or others will have other ideas about how to do that.

Thanks!
Sandy 


> On Sep 6, 2022, at 3:00 PM, Peter Saint-Andre <[e-mail]> wrote:
> 
> This seems fine to me, although the "NEW:" text is not yet in the PDF file (I suppose it will be in your forthcoming update).
> 
> On 9/6/22 3:50 PM, Sandy Ginoza wrote:
>> Hi Team,
>> Please see Carsten's reply below; our understanding is that the display we see of the XML file in emacs is application-specific, and that it's OK to proceed. Please let us know if you believe otherwise.
>> Please note that there is some urgency here in that I will be posting an updated document today and expect the author approvals to follow quickly.
>> Thanks,
>> Sandy
>>> Begin forwarded message:
>>> 
>>> *From: *Carsten Bormann <[e-mail] <mailto:[e-mail]>>
>>> *Subject: **Re: AUTH48: RFC-to-be 9290 <draft-ietf-core-problem-details-08> for your review*
>>> *Date: *September 1, 2022 at 1:10:09 AM PDT
>>> *To: *Sandy Ginoza <[e-mail] <mailto:[e-mail]>>
>>> *Cc: *RFC Editor <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, Thomas Fossati <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, Jaime Jiménez <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>>> 
>>> Hi Sandy,
>>> 
>>> 
>>>> On 31. Aug 2022, at 23:15, Sandy Ginoza <[e-mail] <mailto:[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 <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 <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
>>> 
>>> 
>>> 
>>> 
>>>> 
>>>> 
>>>> 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] <mailto:[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 <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] <mailto:[e-mail]>> wrote:
>>>>>> 
>>>>>> On Monday, 22 August 2022 at 22:45, Carsten Bormann <[e-mail] <mailto:[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.
>>>> 
>>> 
> 
> -- 
> Xml-sg-cmt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xml-sg-cmt