Re: [Tools-discuss] UTF-8 in PDF on datatracker

[Tom Pusateri <[e-mail]>]

> On Aug 5, 2019, at 4:16 PM, Henrik Levkowetz <[e-mail]> wrote:
> 
> Hi Tom,
> 
>> On 2019-08-05 20:01, Tom Pusateri wrote:
>> 
>> 
>>> On Aug 5, 2019, at 1:54 PM, Carsten Bormann <[e-mail]> wrote:
>>> 
>>> On Aug 5, 2019, at 19:29, Tom Pusateri <pusateri=[e-mail]> wrote:
>>>> 
>>>> “On page 21, HTML and text version has “TTL⩾0", which gets mangled in PDF version.”
>>> 
>>> Well, you have a 
>>> 
>>> U+2A7E GREATER-THAN OR SLANTED EQUAL TO
>>> 
>>> there.  I think you want a
>>> 
>>> U+2265 GREATER-THAN OR EQUAL TO
>>> 
>>> (I have no comment on the PDF situation.)
>>> 
>>> Grüße, Carsten
>> 
>> Thanks. My co-author inserted it and also added the —utf8 switch but I see that is now deprecated:
>> 
>> xml2rfc --utf8 draft-ietf-dnssd-push.xml -o draft-ietf-dnssd-push.html --html
>> Warning: The --utf8 switch is deprecated.  Use the new unicode insertion element <u>
> 
> In this case (since the PDF is created from the htmlized text), this is
> irrelevant.
> 
> However, even if --utf8 (for v2 xml) is deprecated, it still works for some
> uses.  Going forward, it will eventually be removed.  But the bug here is in
> the htmlized-text to pdf processing, not in whether --utf8 is used or not.
> 
> 
>    Henrik

In this case, for v2 or v3, I don’t think these two options (—utf8 and <u>) are equivalent.
In the current xml2rfc using v2 input, the —utf8 option is necessary to get the correct TXT and HTML output.

The <u> element will not do this as currently defined and seems to be for a different purpose.

Thanks,
Tom