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

[Sandy Ginoza <[e-mail]>]

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? 

Thanks,
Sandy 



> On Aug 22, 2022, at 1:55 PM, Carsten Bormann <[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
>