Admittedly, as opposed to other Grob.padding settings no object is > moved, instead the TextSpanner itself changes its appearance. > I think you nailed the root of why I think the naming is confusing. Funnily enough I do think that the name "padding" is appropriate for Glissandos, where it is a measure of how much white-space there is between the end of the glissando and it's notehead. I just don't find it intuitive for TextSpanners in particular. I agree however that this ship has sailed.
Werner, I looked at the documentation trying to see what I would have needed to be different in order to be able to find this knowledge on my own. For me personally it would have been to have the Internals Reference offer a very concise yet detailed description of the sub-properties of the bound-details property of the line-spanner-interface <http://lilypond.org/doc/v2.19/Documentation/internals/line_002dspanner_002dinterface> . This is because my workflow in these scenarios is to go to the description of the object which is giving me trouble, see what interfaces and properties it has, and from there work out what I need to do. This is also what the Lilypond manuals suggest <http://lilypond.org/doc/v2.19/Documentation/learning/properties-of-layout-objects>. So, if the purpose of the Internals Reference is "to present information precisely and concisely", for me a precise description would be at the very least to have a list of it's sub-properties. I think someone explained to me some time ago (in a similar situation with an alist of properties although I don't remember specifically with what) that this is not possible because of the way the documentation is automatically generated. If this is not possible then a visual example in this verbose description <http://lilypond.org/doc/v2.19/Documentation/notation/spanners#using-the-line_002dspanner_002dinterfacehttp://lilypond.org/doc/v2.19/Documentation/notation/spanners#using-the-line_002dspanner_002dinterface> of the line-spanner-interface would be my next bet: a short snippet that shows it's effect in a few different grobs would probably be enough to be able to find it when hunting for a solution. Do any of the above seem feasible? El mar., 7 may. 2019 a las 6:53, Thomas Morley (<thomasmorle...@gmail.com>) escribió: > Am Di., 7. Mai 2019 um 01:53 Uhr schrieb Stefano Troncaro > <stefanotronc...@gmail.com>: > > > > Hi Harm, honestly because I generally understand "padding" as the amount > of whitespace that should be reserved between objects. > > Well, that's exactly what happens here. > bound-details.right.padding is the amount of white-space between the > end of the TextSpanner and its right-bound. > Thus the negative value, as opposed to your code going for 'X. > Admittedly, as opposed to other Grob.padding settings no object is > moved, instead the TextSpanner itself changes its appearance. > > I _guess_ (without having researched) it's also due to historical reasons: > Going for 'shorten-pair for TextSpanner would have needed additional > code to limit it to certain parts of a broken spanner, whereas > bound-details.left/right/left-broken/right-broken.padding > offers the user a direct method to set whats wished for each end of a > broken TextSpanner. > Thus, replacing the values of > bound-details.left/right/left-broken/right-broken.padding by those > from shorten-pair is not that straight-forward. > Probably the name of the padding-_sub_-property is unfortunate. > Though, I think this ship sailed long time ago. > > Btw > \override TextSpanner.padding = 10 > _moves_ the TextSpanner, nothing else, as everyone would expect. > > > Cheers, > Harm >
_______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
