Reduce offsets of \super and \sub (issue 35320043)
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#newcode4000 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. https://codereview.appspot.com/35320043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduce offsets of \super and \sub (issue 35320043)
On 2013/11/30 08:45:14, Keith wrote: On Fri, 29 Nov 2013 23:59:52 -0800, mailto:d...@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. https://codereview.appspot.com/35320043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Completion_*_engraver: add means to preserve scale factor; issue 3650 (issue 35370043)
LGTM https://codereview.appspot.com/35370043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Completion_*_engraver: add means to preserve scale factor; issue 3650 (issue 35370043)
https://codereview.appspot.com/35370043/diff/1/scm/define-context-properties.scm File scm/define-context-properties.scm (right): https://codereview.appspot.com/35370043/diff/1/scm/define-context-properties.scm#newcode231 scm/define-context-properties.scm:231: original duration to be split, and the length of the measure.) The description does not correspond to the actual function arguments. The function arguments, in addition, seem like a random collection of things that could prove useful or not. If there is more than one argument (the duration), then the only other argument that seems to make sense to pass is the context: then context properties like measureLength are available anyway. Parametrization via additional context properties seems excessive, again basically because such properties would be a random collection of things that could prove useful or not. Instead it would make sense to parameterize the offered callback functions into closures, like (define-public ((complete-on-multiples base) context duration) ...) (no attempt to pick a good name here). Then there is just one context variable to override, after all. https://codereview.appspot.com/35370043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: order of layout operations, and \shapeII
Hi, 2013/11/27 Keith E OHara k-oh...@oco.net: There have been a couple bug-reports (3669 3677) coming from users wanting to access LilyPond's layout decisions, in order to adjust those decisions. [...] The reference point 'ref' is the System, with origin usually the uppermost point in the System, so the output would normally be (-2 . -1). If we remove the \break, however, the Staff seems not yet to have been placed in the System when #'positions is evaluated; the Staff reference point (the midline) seems to be at the reference point of the System, as the note-head is reported to span (0 . 1). (Things get more complicated if there is a RehearsalMark, which inserts itself on the first Staff, probably moving that Staff down relative to System, when its property 'after-line-breaking = move-to-extremal-staff is evaluated.) The layout in LilyPond is not driven by a procedure; the functions that make layout decisions call each other as needed (functional, rather than procedural, programming). So callbacks generally should handle being called whenever the decision they support is requested. Aaaah, this is very helpful, thanks a lot! My only suggestion right now is to try to write callback functions that are robust to being activated at different stages of layout. Can anyone see a way to write the \shapeII function at http://lists.gnu.org/archive/html/lilypond-user/2013-11/msg00832.html so that it computes self-consistent positions for a slur using data either before, or after, LilyPond has placed each Staff relative to the System ? Maybe it would be enough to use the staff as the 'ref' (instead of the system)? I don't see any predefined function for getting the staff, though - it needs to be written. I'll gladly experiment with this, but i don't know when i'll have time :( best and thanks for the explanation, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
XY-extent: more accurate docstring (issue 35440044)
LGTM https://codereview.appspot.com/35440044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
New Catalan PO file for 'lilypond' (version 2.17.96)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'lilypond' has been submitted by the Catalan team of translators. The file is available at: http://translationproject.org/latest/lilypond/ca.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: http://translationproject.org/latest/lilypond/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/lilypond.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Be serious about setstrokeadjust in PostScript primitives (issue 8663044)
LGTM as per tracker comment (the results, haven't read the code yet...) Janek https://codereview.appspot.com/8663044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Communication style on the devel list
On Nov 30, 2013, at 10:58 PM, Janek Warchoł janek.lilyp...@gmail.com wrote: 2013/11/30 Mike Solomon m...@mikesolomon.org: I would argue that the point that Janek brings up above is not a healthy sign for LilyPond development. Several developers, including myself, have lowered their participation considerably over the past two years. Maybe i should ask the question why are you less active?. But i don't want to be overly inquiring; i assume that your job and family simply takes so much time that you cannot do LilyPond work. Janek Nothing to do with either of those - after a series of difficult conversations on the developer list, I informed the community that I’d be taking time off the project: http://lilypond.1069038.n5.nabble.com/Re-stencil-integral-use-box-extents-specified-in-markup-issue-3255-issue-9295044-td149952.html This was about a patch that ultimately made its way into the code base (a6efcfa82dae01859f0d6d3bbfbaaa6f2eeb8a9c, modified and pushed by Keith O’Hara). I made this decision after having asked several times to keep the communication between developers cordial and collegial. Insofar as I do not believe I am the only person who has run into this issue, I think this is a hindrance to LilyPond development that needs to be addressed by the community. Cheers, MS P.S. I changed the subject of this thread because I am now addressing a different issue. I do not want this message to be construed in any way as an advisement against supporting David being paid for his valuable and essential contributions to LilyPond.___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Communication style on the devel list
2013/11/30 Mike Solomon m...@mikesolomon.org: On Nov 30, 2013, at 10:58 PM, Janek Warchoł janek.lilyp...@gmail.com wrote: 2013/11/30 Mike Solomon m...@mikesolomon.org: I would argue that the point that Janek brings up above is not a healthy sign for LilyPond development. Several developers, including myself, have lowered their participation considerably over the past two years. Maybe i should ask the question why are you less active?. But i don't want to be overly inquiring; i assume that your job and family simply takes so much time that you cannot do LilyPond work. Nothing to do with either of those - after a series of difficult conversations on the developer list, I informed the community that I’d be taking time off the project: http://lilypond.1069038.n5.nabble.com/Re-stencil-integral-use-box-extents-specified-in-markup-issue-3255-issue-9295044-td149952.html !! It's very bad that i had missed that email (i'm not able to read all traffic on the lists and that one didn't seem as if there was something important going on...). I have to think about this. Mike, could we Skype tomorrow (8-13 UTC)? best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Completion_*_engraver: add means to preserve scale factor; issue 3650 (issue 35370043)
Reviewers: benko.pal, dak, Message: On 2013/11/30 11:08:26, dak wrote: If there is more than one argument (the duration), then the only other argument that seems to make sense to pass is the context: then context properties like measureLength are available anyway. That makes sense. Description: Completion_*_engraver: add means to preserve scale factor; issue 3650 Please review this at https://codereview.appspot.com/35370043/ Affected files (+110, -40 lines): M Documentation/notation/rhythms.itely M input/regression/completion-heads-factor.ly M input/regression/completion-rest.ly M lily/completion-note-heads-engraver.cc M lily/completion-rest-engraver.cc M ly/engraver-init.ly M scm/c++.scm M scm/define-context-properties.scm M scm/lily-library.scm M scm/lily.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduce offsets of \super and \sub (issue 35320043)
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.
https://codereview.appspot.com/35320043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduce offsets of \super and \sub (issue 35320043)
On 11/30/13 5:52 PM, k-ohara5...@oco.net k-ohara5...@oco.net wrote: Do you know a better quantity on which to scale the raising of superscripts? What about font-size? Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduce offsets of \super and \sub (issue 35320043)
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#newcode3938 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. https://codereview.appspot.com/35320043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduce offsets of \super and \sub (issue 35320043)
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/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduce offsets of \super and \sub (issue 35320043)
On Sat, 30 Nov 2013 21:21:49 -0800, lemzw...@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 ? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduce offsets of \super and \sub (issue 35320043)
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'. https://codereview.appspot.com/35320043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
tag for 2.17.96 is missing in git
Please add a tag for the 2.17.96 release! Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
make lilypond compile with FreeType 2.5.1
We need this backwards-compatible patch. https://codereview.appspot.com/35580043 Please apply to the stable branch also. Werner PS: Somehow I failed to automatically create a lilypond issue, due to entering an incorrect password. Do we need an issue? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make lilypond compile with FreeType 2.5.1
2013/12/1 Werner LEMBERG w...@gnu.org: We need this backwards-compatible patch. https://codereview.appspot.com/35580043 Please apply to the stable branch also. Werner PS: Somehow I failed to automatically create a lilypond issue, due to entering an incorrect password. Do we need an issue? This sometimes happens to me also. Better have an issue or there is a risk of patch being overlooked - i don't like this, but that's what we have. I created an issue for you manually, i hope that i got the format right and patchy will understand it http://code.google.com/p/lilypond/issues/detail?id=3694. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make lilypond compile with FreeType 2.5.1
I created an issue for you manually, [...] Thanks! Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduce offsets of \super and \sub (issue 35320043)
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 https://codereview.appspot.com/35320043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
