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

[Thomas Fossati <[e-mail]>]

Awesome, thanks Kesara.

On 29/08/2022, 05:19, "Kesara Rathnayake" <[e-mail]> wrote:



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]
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.