Re: ugly left-side cropping in documentation

[David Kastrup]

"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