Reduce offsets of \super and \sub

Reduce offsets of \super and \sub

This brings chordNames and text superscripts into better agreement
with the shifts in user-provided scans.

[dak, 2013-11-30 07:59:51]

https://codereview.appspot.com/35320043/diff/1/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):

https://codereview.appspot.com/35320043/diff/1/scm/define-markup-commands.scm...
scm/define-markup-commands.scm:4000: (* 0.33 baseline-skip)
I'm not sure a multiple of baseline-skip is the best metric (possibly for
limiting height in cramped situations, but not even sure about that).

It seems that it would not follow most font size changes.  In particular not the
one caused by \super itself.

[Keith, 2013-11-30 08:45:14]

On Fri, 29 Nov 2013 23:59:52 -0800, <dak@gnu.org> wrote:

> I'm not sure a multiple of baseline-skip is the best metric (possibly
> for limiting height in cramped situations, but not even sure about
> that).
>
> It seems that it would not follow most font size changes.  In particular
> not the one caused by \super itself.

True.  What is your point?

[dak, 2013-11-30 08:54:27]

On 2013/11/30 08:45:14, Keith wrote:
> On Fri, 29 Nov 2013 23:59:52 -0800, <mailto:dak@gnu.org> wrote:
> 
> > I'm not sure a multiple of baseline-skip is the best metric (possibly
> > for limiting height in cramped situations, but not even sure about
> > that).
> >
> > It seems that it would not follow most font size changes.  In particular
> > not the one caused by \super itself.
> 
> True.  What is your point?

The question is rather what the point of the patch is.  I read "This brings
chordNames and text superscripts into better agreement with the shifts in
user-provided scans." but it would seem to do so only for a particular font
size.

[Keith, 2013-12-01 00:52:57]

On 2013/11/30 08:54:27, dak wrote:

> The question is rather what the point of the patch is.  I read "This brings
> chordNames and text superscripts into better agreement with the shifts in
> user-provided scans." but it would seem to do so only for a particular font
> size.

Well, for a particular relation between font size and setting of baseline-skip,
specifically the relation that we have with LilyPond defaults.

  Do you know a better quantity on which to scale the raising of superscripts?

The code history shows that the raise of a superscript was scaled from
baseline-skip, forever.  It seems a reasonable choice, because it should
indicate the vertical scale of the surrounding text.  You would not want to take
the scale from the text being raised :
 \markup { la \concat {\huge 3 \super ième} fois }
 \markup { la \concat {\teeny 3 \super \huge ième} fois }

It might be nicer if the text-scaling functions did a local scaling of
baseline-skip :
 \markup \teeny { la \concat {3 \super ième} fois }
 \markup { la \concat {3 \super ième} fois 
   \override #'(baseline-skip . 2) \teeny { 
           la \concat { 3 \super ième} fois } }

Just checking, when I put chord-names in a multi-line score in a markup, the
baseline-skip between systems is kept distinct from the baseline-skip for
text-ish things in the score.
  music = \chordmode { \repeat unfold 20 {c2:9dim ges2:maj7} }
  \markup { \override #'(baseline-skip . 10 )
  \score {
     <<\new ChordNames \music
       \new Staff \music >>
     \layout{} }}

So the basic function of \super seems fine to me; it just raises too far.

[c_sorensen, 2013-12-01 02:09:01]

On 11/30/13 5:52 PM, "k-ohara5a5a@oco.net" <k-ohara5a5a@oco.net> wrote:

>
>   Do you know a better quantity on which to scale the raising of
>superscripts?

What about font-size?

Carl

[Keith, 2013-12-01 02:53:02]

On 2013/12/01 02:09:01, c_sorensen_byu.edu wrote:

> What about font-size?

That should work. I wonder, though, why font-size was not used initially.
I'll try it next weekend.  I would really be trying to estimate the x-height in
a 'normal' font, and since that comes up often, I would make a function to give
that height.

https://codereview.appspot.com/35320043/diff/1/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):

https://codereview.appspot.com/35320043/diff/1/scm/define-markup-commands.scm...
scm/define-markup-commands.scm:3938: (offset (* factor 0.75)))
Similarly, the raising of a superscript could be 
 (* (magstep font-size) 0.5)
with 0.5 adjusted empirically to create the right fraction of the ex-height.

[lemzwerg, 2013-12-01 05:21:49]

Would it be possible to directly compute the height of the current font's `x'
glyph as a basis value for raising and lowering?

[Keith, 2013-12-01 06:05:24]

On Sat, 30 Nov 2013 21:21:49 -0800, <lemzwerg@googlemail.com> wrote:

> Would it be possible to directly compute the height of the current
> font's `x' glyph as a basis value for raising and lowering?
>
> https://codereview.appspot.com/35320043/

I tried to do that for centering dynamics on their hairpins, but could not see
anyway except to build a sample stencil
https://codereview.appspot.com/7005056/diff/29001/scm/output-lib.scm#newcode861
and decided against it because it costs some time and I cannot guess be sure it
would do any good (in someone's real situation where he uses some other font for
dynamics).

Do you know if the fonts, in the form LilyPond uses, will report their x-height,
and if so how to get the information out of pango ?

[lemzwerg, 2013-12-01 06:33:20]

> Do you know if the fonts, in the form LilyPond uses,
> will report their x-height, and if so how to get the
> information out of pango?

I've just looked up the source code, and the concept of the x-height doesn't
seem to be part of Pango.  The nearest I can find is the strikethrough position,
cf. `pango_font_metrics_get_strikethrough_position'.

[janek, 2013-12-01 07:56:08]

LGTM

I have one request: this patch makes the situation better, and even if the
baseline-skip approach is wrong, it was already used that way so it's not making
things worse.  I suggest to push this patch, and then work on making this
smarter (in the spirit of "best is the enemy of the good").

best,
Janek

[Keith, 2013-12-01 09:16:14]

On Sat, 30 Nov 2013 23:56:09 -0800, <janek.lilypond@gmail.com> wrote:

> I have one request: this patch makes the situation better, and even if
> the baseline-skip approach is wrong, it was already used that way so
> it's not making things worse.  I suggest to push this patch, and then
> work on making this smarter (in the spirit of "best is the enemy of the
> good").

Definitely.

The patch as it is already fixes both cases here
   \markup {      \concat { 8 \super va }
     \fontsize #3 \concat { 8 \super va } }
because \fontsize changes baseline-skip in harmony.

Scaling on font-size would properly change the #:properties line of some of
these functions, which affects `make doc`, and last time I did that in this file
it was a disaster (http://codereview.appspot.com/9295044/).

[dak, 2013-12-01 09:31:20]

On 2013/12/01 09:16:14, Keith wrote:
> On Sat, 30 Nov 2013 23:56:09 -0800, <mailto:janek.lilypond@gmail.com> wrote:
> 
> > I have one request: this patch makes the situation better, and even if
> > the baseline-skip approach is wrong, it was already used that way so
> > it's not making things worse.  I suggest to push this patch, and then
> > work on making this smarter (in the spirit of "best is the enemy of the
> > good").
> 
> Definitely.
> 
> The patch as it is already fixes both cases here
>    \markup {      \concat { 8 \super va }
>      \fontsize #3 \concat { 8 \super va } }
> because \fontsize changes baseline-skip in harmony.

\fontsize does, but \small, \large, \huge, \super (!) all do an override to
font-size which does _not_ affect baseline-skip in contrast to the markup
command \fontsize changing everything in concert.

[Keith, 2013-12-01 17:06:52]

On 2013/12/01 09:31:20, dak wrote:
 
> \fontsize does, but \small, \large, \huge, \super (!) all do an override to
> font-size which does _not_ affect baseline-skip in contrast to the markup
> command \fontsize changing everything in concert.

We know that, David.  
See above were we considered "It might be nicer if the text-scaling functions
did a local scaling of
baseline-skip" and then the suggestions of using font-size instead.

Let's call the issue with shifts after a \small "3697".
That issue does not get in the way of sizing the offsets correctly for the
common use-cases.