[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ugly left-side cropping in documentation
From: |
David Kastrup |
Subject: |
Re: ugly left-side cropping in documentation |
Date: |
Tue, 28 May 2013 11:01:33 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
"Phil Holmes" <address@hidden> writes:
> ----- Original Message -----
> From: "Werner LEMBERG" <address@hidden>
> To: <address@hidden>
> Sent: Tuesday, May 28, 2013 8:01 AM
> Subject: ugly left-side cropping in documentation
>
>
>>
>> Have a look at the image in this section:
>>
>>
>> http://www.lilypond.org/doc/v2.17/Documentation/notation/displaying-staves#nested-staff-groups
>>
>> Whatever the snippet tries to show, it is cut off.
>>
>>
>> Werner
>
> I believe this has happened since 2.17.13 - I've not analysed further.
2.17.15 would be first.
> It is definitely an artefact of -dpreview and brackets, which do not
> appear to be taken into account in the cropping. I think this is a
> critical regression.
>
> There are other similar reports:
>
> http://code.google.com/p/lilypond/issues/detail?id=2968
Reported in November, should be a different problem.
> http://code.google.com/p/lilypond/issues/detail?id=3318
Well, just dug up the thread referenced from there:
<URL:http://lilypond.1069038.n5.nabble.com/dpreview-crops-staff-bracket-td145267.html>
which would have saved me the below (I'm still letting it stand). It
looks like this has not been registered as a separate issue, and there
has been no reply from Mike so far. So what are we going to do?
Pre Scriptum:
Bisection gives
7b2cb93fc69c7d7c45f0ae6495f688752efeb107 is the first bad commit
commit 7b2cb93fc69c7d7c45f0ae6495f688752efeb107
Author: Mike Solomon <address@hidden>
Date: Sat Mar 23 19:09:28 2013 +0100
Fixes manual beaming over rests and vertical spacing problem (issue 3242)
:040000 040000 3cca4a11040bbe18efe1e1ad88ea21094748cf0d
0e685cbbaf4f43ad59e0e74ac90925d3c33aa2f3 M lily
:040000 040000 f2f6bae625b7e31d2f695676de1010a756e8552a
7845ab09e23ab3934815226bc109e9a89b07476e M scm
WTF? The commit message does not look like it would have _any_
connection with braces or horizontal extents. And yet it just throws
code out that is explicitly intended and documented to deal with system
start brackets.
- // Ditto - seems kludgy, but this time logic of SystemStartBrackets
- if (my_dim.is_empty ())
- {
- my_dim = Skyline (my_dim.direction ());
- my_dim.set_minimum_height (isinf (max_raise) ? 0.0 : max_raise);
- }
-
[...]
- // In horizontal spacing, there are grobs like SystemStartBracket
- // that take up no vertical spcae. So, if the y extent is empty,
- // we use the entire Y extent ot make the X a sort of horizontal wall.
- // Ditto for vertical spacing and grobs like BassFigureAlginmentPositioning.
- if (a == Y_AXIS && yex.is_empty ())
- yex.set_full ();
-
- if (a == X_AXIS && xex.is_empty ())
- xex.set_full ();
-
The respective change set #3
<URL:https://codereview.appspot.com/7516048/#ps9001> is called "Removes
evil code from C++, replaces with happy defaults in Scheme".
However, the only defaults that are changed in Scheme with regard to the
system braces is marking them as "cross-staff". Which does not seem to
cater for the kind of horizontal reckoning that the "evil code" in C++
had provided.
--
David Kastrup