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

[Kesara Rathnayake <[e-mail]>]

On 27/08/22 11:05 am, Sandy Ginoza wrote:
> Authors, CMT,
> 
> Carsten and Thomas approved publication pending "repairing the PDF 
> glitch and the typo" where the "PDF glitch" is #873 
> <https://github.com/ietf-tools/xml2rfc/issues/873>.
> Is there some escalation path or alternate fix for this, as it seems as 
> though WeasyPrint won’t fix this (issue 1711 
> <https://github.com/Kozea/WeasyPrint/issues/1711> was closed as "not 
> planned”).  Any thoughts on how to proceed?
> 

WeasyPrint seems to play nice when RTL content is not within a `span` tag.
So there's a fix on xml2rfc for the current issue [1].
I have attached the PDF file generated with the fix.

[1] https://github.com/ietf-tools/xml2rfc/pull/884

   --Kesara

> Thanks,
> Sandy
> 
> 
> 
>> On Aug 22, 2022, at 1:55 PM, Carsten Bormann <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Hi Megan,
>>
>> I’m in the middle of my full reread (3 totally optional nits so far), 
>> but now I’m running into a major glitch with the PDF generation, which 
>> I found in the RFC-editor’s output and can reproduce when generating 
>> the PDF locally with both xml2rfc 3.13.1 and 3.14.1 [weasyprint-56.1]).
>>
>> Correct in HTML:
>>
>>> The following example shows how the Hebrew-language string "שלום" 
>>> (HEBREW LETTER SHIN, HEBREW LETTER LAMED, HEBREW LETTER VAV, HEBREW 
>>> LETTER FINAL MEM, U+05E9 U+05DC U+05D5 U+05DD) is represented. Note 
>>> the rtl direction expressed by setting the third element in the array 
>>> to "true”.
>>
>> Correct in TXT:
>>
>>>   The following example shows how the Hebrew-language string "שלום"
>>>   (HEBREW LETTER SHIN, HEBREW LETTER LAMED, HEBREW LETTER VAV, HEBREW
>>>   LETTER FINAL MEM, U+05E9 U+05DC U+05D5 U+05DD) is represented.  Note
>>>   the rtl direction expressed by setting the third element in the array
>>>   to "true".
>>
>> Glitch in PDF:
>>
>>> The following example shows how the Hebrew-language string ,HEBREW 
>>> LETTER SHIN) "􏰀􏰁􏰂שלום" HEBREW LETTER LAMED, HEBREW LETTER VAV, HEBREW 
>>> LETTER FINAL MEM, U+05E9 U+05DC U+05D5 U+05DD) is represented. Note 
>>> the rtl direction expressed by setting the third element in the array 
>>> to "true".
>>
>> Please note that, after a copy-paste from PDF to text, I get the three 
>> private-use characters before the שלום.
>> For comparison, poppler's pdftotext just finds a U+202B RIGHT-TO-LEFT 
>> EMBEDDING before and a U+202C POP DIRECTIONAL FORMATTING after the 
>> hebrew text (including the terminating quote) both for the running 
>> text and the artwork example that follows.
>>
>> So if the latin text for (HEBREW LETTER SHIN, weren't surprisingly 
>> reordered in the PDF, all would be fine.
>>
>> (I'd like to reconfirm that (except for the PDF glitch) the
>> presentation of the example with שלום in Appendix A looks exactly like
>> we intended -- a more beautiful rendering of the Unicode names and
>> scalars would certainly be possible, but is outside the scope of what
>> we want to achieve here.)
>>
>>
>> Grüße, Carsten
>>
> 
> 

-- 
Kesara Rathnayake
Senior Software Development Engineer - IETF LLC
[e-mail]