|
|
Created:
10 years, 5 months ago by Keith Modified:
10 years, 5 months ago CC:
lilypond-devel_gnu.org Visibility:
Public. |
DescriptionReduce offsets of \super and \sub
This brings chordNames and text superscripts into better agreement
with the shifts in user-provided scans.
Patch Set 1 #
Total comments: 2
MessagesTotal messages: 13
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.
Sign in to reply to this message.
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?
Sign in to reply to this message.
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.
Sign in to reply to this message.
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.
Sign in to reply to this message.
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
Sign in to reply to this message.
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.
Sign in to reply to this message.
Would it be possible to directly compute the height of the current font's `x' glyph as a basis value for raising and lowering?
Sign in to reply to this message.
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 ?
Sign in to reply to this message.
> 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'.
Sign in to reply to this message.
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
Sign in to reply to this message.
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/).
Sign in to reply to this message.
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.
Sign in to reply to this message.
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.
Sign in to reply to this message.
|