bug-texinfo
[Top][All Lists]
Advanced

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

Re: pdfeTeX error when compiling lilypond.texi with accents in node name


From: Karl Berry
Subject: Re: pdfeTeX error when compiling lilypond.texi with accents in node names
Date: Fri, 22 Jun 2007 18:11:44 -0500

Hi John,

    The Texinfo source is in
    UTF-8, many node names and section titles contain accented characters.

Unfortunately I think that the general problem is that you are well
beyond the state of the implementation :(.

    That is strange, as the attached sample.texi contains node
    names and section titles with accents, 

What's happening is that a UTF-8 e-aigu or whatever is turned into the
regular Texinfo equivalent (@'e) in the aux files.  This isn't ideal,
but was a first step on the road.  Not doing that leads to many more
complications.

    I'm not sure how to solve this.  If first argument of @xrdef is only
    used internally, 

Well, the node name is printed in the output from @xref, etc.
Introducing another layer so that the node name is not used directly in
control sequence names is possible, but ...

    is it possible to add a routine which strips accents
    @-commands in it to avoid the error?

In principle, that could lead to clashes, although in practice I suppose
it's very unlikely, so it could probably be a first approximation.

Oleg, can you see if you can make UTF-8 work in node names per John's
sample document?  (Maybe just calling indexdummies to eradicate most
commands for xref processing?  I'm sure it's not that easy ...)  I'm
going to be gone the next couple days and with GPLv3 coming out shortly,
I won't be able to look at it any time soon.

    Besides this, accents disappear in PDF index side pane; is it possible
    to keep them?

That's a much harder problem.  I was under the impression that system
fonts are used in the bookmark panel, in some unknown encoding.  Or is
it always UTF-8 these days?  Do you know?

The general solution is out of reach (requiring conversion from one
arbitrary encoding to another), but perhaps it would be possible to
simply copy the input as it is, if that works.

Thanks for the report, and sorry for the bad news.

karl




reply via email to

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