lilypond-devel
[Top][All Lists]
Advanced

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

Re: PDF is broken for @notation{} encoding


From: David Kastrup
Subject: Re: PDF is broken for @notation{} encoding
Date: Tue, 26 May 2015 10:02:45 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

James Lowe <address@hidden> writes:

> On 26/05/15 08:35, David Kastrup wrote:
>> James Lowe <address@hidden> writes:
>> 
>>> On 25/05/15 16:08, Phil Holmes wrote:
>>>> I can try again, but it was consistent.  James might want to try?
>>>
>>> If it helps.
>>>
>>> I get the same thing too.
>> 
>> How much effort is it to do one iteration on one affected file?  I have
>> absolutely no clue how this may come about so if one could figure out
>> _which_ of the added defines is responsible, it might help boiling this
>> down.  One can probably do some sort of manual bisection on the added
>> commands but it would still require something like 7 runs.
>> 
>
> I don't really have any experience with 'bisections' so if you can give
> me some relatively simple instructions, I don't mind doing the gruntwork
> building doc over and over.

Oh, I was not talking about "git bisect".  I was talking about figuring
out manually which of definitions was at fault here.  The whole diff is

 \def\nonasciistringdefs{%
   \setnonasciicharscatcode\active
   \def\defstringchar##1{\def##1{\string##1}}%
+  %
+  \defstringchar^^80\defstringchar^^81\defstringchar^^82\defstringchar^^83%
+  \defstringchar^^84\defstringchar^^85\defstringchar^^86\defstringchar^^87%
+  \defstringchar^^88\defstringchar^^89\defstringchar^^8a\defstringchar^^8b%
+  \defstringchar^^8c\defstringchar^^8d\defstringchar^^8e\defstringchar^^8f%
+  %
+  \defstringchar^^90\defstringchar^^91\defstringchar^^92\defstringchar^^93%
+  \defstringchar^^94\defstringchar^^95\defstringchar^^96\defstringchar^^97%
+  \defstringchar^^98\defstringchar^^99\defstringchar^^9a\defstringchar^^9b%
+  \defstringchar^^9c\defstringchar^^9d\defstringchar^^9e\defstringchar^^9f%
+  %
   \defstringchar^^a0\defstringchar^^a1\defstringchar^^a2\defstringchar^^a3%
   \defstringchar^^a4\defstringchar^^a5\defstringchar^^a6\defstringchar^^a7%
   \defstringchar^^a8\defstringchar^^a9\defstringchar^^aa\defstringchar^^ab%

Now assuming that it isn't one of the percent signs or the formatting
(and it continues like that anyway), it's likely one of the added
\defstringchar commands.  So you first take out the first 16 commands
and recompile.  Any change?  Yes->problem is in the first 16 commands.
No->problem is in the second 16 commands.

You then taken out the first 8 commands in the affected block.  Any
change?  Yes->problem is in the first 4 of that block (one line).
No->problem is in the last 4 of that block.  You take out the first 2 of
the affected block of 4 (make sure that the line still ends in a % sign
either way).

Repeat until you find a single command (hopefully) where taking it out
fixes the problem.

And where, when starting from the previous version, only putting this
command in (again, make sure that the line ends with %) recreates the
problem.

If this can be boiled down to a single \defstringchar^^xy then it
becomes easier to figure out just _why_ this particular command causes
the effect.

-- 
David Kastrup



reply via email to

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