Re: [help-texinfo] Umlaut strangeness

[Gavin Smith]

On 5 June 2016 at 00:33, Karl Berry <address@hidden> wrote:
>     I've done some work on this and have made some progress, managed to
>     output this sequence when generating a PDF bookmark
>
> Wow, that's great.
>
>     ! pdfTeX warning (dest):name{FE FF 00 DCbersicht 2} has been
>     referenced but does not exist, replaced by a fixed one
>
> Argh.  pdftex is just trying to match strings.  Can the bookmark display
> name (Unicode) be separated from the destination (= node name, in
> whatever format it is)?

They are separate: my code had changed them both, but the current code
should only change the display name.

>     grep to think it is a binary file,
>
> That binary/text stuff for grep "helpfully" invented a few years ago is
> so frustrating.  As far as I know the only way to force it is to supply
> --text, and that only works with GNU grep, so that would then have to be
> tested for.  Double argh.

1. In the current code, the "destination names" aren't output in the
UTF-16 encoding, so the null bytes shouldn't appear if the destination
names are written to the log file.
2. The "destination names" are internal, and aren't displayed, and the
encoding shouldn't matter.
3. Nonetheless, I had trouble with PDF files that had non-ASCII
destination names. (Maybe because I am using old and buggy PDF
readers?) But the current development texinfo.tex tries to use
ASCII-only destination names. This should work okay as long as two
destinations do not normalize to the same thing.
4. It's easy to imagine that null bytes in the log files would cause
problems. This should not happen at the moment.
5. But apparently newer GNU grep causes problems if the encoding of
the file differs from the encoding from the user's locale. For
example, in a UTF-8 locale, bytes that aren't valid UTF-8 sequences
would cause a file to be viewed as binary. That could cause problems.