guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Manual PDF and translation (modular texlive?)


From: Ricardo Wurmus
Subject: Re: Manual PDF and translation (modular texlive?)
Date: Thu, 22 Oct 2020 14:50:40 +0200
User-agent: mu4e 1.4.13; emacs 27.1

Ricardo Wurmus <rekado@elephly.net> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>>> What’s interesting is that it breaks accents in the table of contents,
>>> but not elsewhere.
>>
>> These double caret sequences are representations of multi-byte
>> characters.  “^^c3^^b6”, for example, is a lowercase a with umlaut.
>>
>> The TeX log file contains a whole bunch of these messages:
>>
>>     l.139: Unicode char @u8:^^e5^^8f^^82 not defined for Texinfo
>>
>> Then later things like this:
>>
>>     Missing character: There is no ^^c3 in font cmr10!
>>     Missing character: There is no ^^9f in font cmr10!
>>     Missing character: There is no ^^c3 in font cmr10!
>>     Missing character: There is no ^^9f in font cmr10!
>>     Missing character: There is no ^^c3 in font cmr10!
>>     Missing character: There is no ^^a4 in font cmr10!
>>
>> I’m not sure this is correct, because it seems to me that “^^c3” is only
>> part of a longer multi-byte sequence, but this error indicates that
>> individual bytes are looked up in the font.
>
> With the full “texlive” package I also see “not defined for Texinfo” in
> the logs, but the characters use octal notation instead of double caret
> notation.  The generated guix.de.toc contains the correct characters
> with umlauts, while the .toc file generated with the modular TeX Live
> contains caret-notated characters.
>
> I’ll try to figure out why that is.

The reason is that the generated guix.de.toc file is ASCII-encoded in
the modular case but UTF-8 encoded in the monolithic case.  Why is that?

texinfo.tex enables byte-I/O for engines that do not have native UTF-8
support; it uses native UTF-8 for LuaTeX and XeTeX only.  Sure enough,
with

    PDFTEX=xetex make doc/guix.de.pdf

the TOC looks actually fine!  LuaTeX is broken due to a botched upgrade
(I’m working on a fix), so I haven’t tested it.

Two things are weird here:

1) texi2dvi still fails, because apparently “xetex” didn’t return a good
status code; the PDF was built fine, though.

2) we aren’t using XeTeX or LuaTeX with the monolithic “texlive”
package, so why does pdfTeX behave differently here?  I see in the logs
that the date of the format file differs — does this indicate that our
pdfTeX format file is wrong?  I will compare the two files.

Another observation: the pdftex.map file in the monolithic “texlive”
package is huge and mentions a great many fonts; in the modular TeX Live
this is generated for fonts that are actually available.  It’s not
impossible that this font map needs more entries, but perhaps everything
is fine already.  I just can’t say for sure.

-- 
Ricardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]