[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
- Manual PDF and translation (modular texlive?), zimoun, 2020/10/16
- Re: Manual PDF and translation (modular texlive?), Ludovic Courtès, 2020/10/21
- Re: Manual PDF and translation (modular texlive?), Ricardo Wurmus, 2020/10/21
- Re: Manual PDF and translation (modular texlive?), Ricardo Wurmus, 2020/10/22
- Re: Manual PDF and translation (modular texlive?),
Ricardo Wurmus <=
- Re: Manual PDF and translation (modular texlive?), Ricardo Wurmus, 2020/10/22
- Re: Manual PDF and translation (modular texlive?), zimoun, 2020/10/22
- Re: Manual PDF and translation (modular texlive?), Ricardo Wurmus, 2020/10/22
- Re: Manual PDF and translation (modular texlive?), zimoun, 2020/10/22
- Re: Manual PDF and translation (modular texlive?), Ricardo Wurmus, 2020/10/22
- Re: Manual PDF and translation (modular texlive?), zimoun, 2020/10/22
- Re: Manual PDF and translation (modular texlive?), zimoun, 2020/10/22
- Re: Manual PDF and translation (modular texlive?), Ricardo Wurmus, 2020/10/22
- Re: Manual PDF and translation (modular texlive?), Ricardo Wurmus, 2020/10/25
- Re: Manual PDF and translation (modular texlive?), Ludovic Courtès, 2020/10/26