On Tue, May 26, 2009 at 07:51:22AM +0100, Trevor Daniels wrote:
Patrick McCarty wrote Monday, May 25, 2009 11:43 PM
On Mon, May 25, 2009 at 03:26:42PM -0700, Patrick McCarty wrote:
On Mon, May 25, 2009 at 2:49 PM, Trevor Daniels
<address@hidden> wrote:
>
> The lines in the html version of this section of the
> Notation Reference are significantly longer than any
> other, so long I have to scroll horizontally to read them.
>
> Does anyone else see this, or is it some subtle problem
> with IE?
IIRC, if the line lengths for any <pre> section are too wide,
IE
recalculates the width of the div to accomodate the longest
line on
the page. Other browsers don't behave this way (as far as I
remember).
I suspect the snippet "Non-default tuplet numbers" in the
Tuplets
section is the culprit. If the values of #'text are moved to
separate
lines, that should solve the problem.
And here is a patch.
Patrick
Many thanks, I'm sure your analysis is correct. But like Carl I
find
the patch doesn't apply, although I didn't see his particular
problems.
(Your patch also has 4 lines with trailing white-space, but
that's not
the problem.) Do you want to try again, or should I or Carl
simply fix
it ourselves now you've identified the cause?
Hmm, I can't figure this out.
I just applied my original patch to master (cleanly), and checked
the
snippet (both in input/new and input/lsr) for trailing whitespace.
There was only one line with trailing whitespace. Before applying
the
patch, the two files still only containing one line with trailing
whitespace.
However, the *patch* contained trailing whitespace on some of the
empty lines as well, but it still applied cleanly for me.
Maybe this is a bug in "git format-patch" in my installed git
verson
(1.6.3.1). It seems odd that "git format-patch" would add
trailing
whitespace.
I created a fresh patch and manually removed all of the trailing
whitespace from it, except for the one in the texidoc which I
fixed.
Let me know if this one works.