http://codereview.appspot.com/4951062/diff/99002/lily/stem.cc
File lily/stem.cc (right):
http://codereview.appspot.com/4951062/diff/99002/lily/stem.cc#newcode284
lily/stem.cc:284: string style = robust_symbol2string
(heads[0]-get_property (style), default);
I think Aleksandr is right.
See
LGTM.
http://codereview.appspot.com/5504091/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi David,
Could you make your own patch for the doc changes?
And, as you mentionned, the unused function should be removed. Do you
want me to commit this change?
Bertrand
http://codereview.appspot.com/4917044/
___
lilypond-devel mailing list
lily-guile updates pushed as 6ee8c04678442855cb794d4598c056c15c42673b.
http://codereview.appspot.com/4917044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM. You'll be happy to know that Mike and I are currently trying to
get rid of \markuplines, so that there will only be a \markup command.
http://codereview.appspot.com/5312050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
LGTM.
http://codereview.appspot.com/5306050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
http://codereview.appspot.com/5306050/diff/2001/lily/spring-smob.cc
File lily/spring-smob.cc (left):
http://codereview.appspot.com/5306050/diff/2001/lily/spring-smob.cc#oldcode42
lily/spring-smob.cc:42: return a == b ? SCM_BOOL_T : SCM_BOOL_F;
On 2011/10/21 11:27:35, dak wrote:
scm_is_true
http://codereview.appspot.com/5293053/diff/12001/lily/page-layout-problem.cc
File lily/page-layout-problem.cc (right):
http://codereview.appspot.com/5293053/diff/12001/lily/page-layout-problem.cc#newcode79
lily/page-layout-problem.cc:79: footnotes_added = g-get_property
(footnote-stencil) !=
A small comment to show you a possible solution for the indentation.
This can be apply at every line length comment.
http://codereview.appspot.com/5293053/diff/12001/lily/page-breaking.cc
File lily/page-breaking.cc (right):
Sorry for this total mistake. !ly_is_equal (..., SCM_EOL) should do it,
then.
http://codereview.appspot.com/5293053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, but the result is really disturbing. We need to think about a
better approach of character boxes in MetaFont. The ideal solution
would be to create a mask for each character. For example, a mask for
the espressivo glyph would be a fill between its 6 dots.
I know it's impossible to
Pushed as 8adeb99e344bf047b9b3b9b48a9e97e59e8fc4d3 and
71aa438bce0f68b0e8ab8c633b4902c971ede48b.
http://codereview.appspot.com/5233042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I pushed the doc as b4a2cb2cf00347c477ed595f1435cc212e70ce33.
Could the remaining C part of the patch be 'countdowned'?
http://codereview.appspot.com/4917044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
LGTM. Two tiny changes and it'll be ready to push.
http://codereview.appspot.com/4951062/diff/78001/ly/engraver-init.ly
File ly/engraver-init.ly (right):
http://codereview.appspot.com/4951062/diff/78001/ly/engraver-init.ly#newcode1107
ly/engraver-init.ly:1107: \remove Stem_engraver
Sorry, I
LGTM
http://codereview.appspot.com/5240054/diff/1/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
http://codereview.appspot.com/5240054/diff/1/Documentation/contributor/source-code.itexi#newcode953
Thanks Neil, I'll make two commits. Do you want to see them both on
codereview?
Comment in lily-guile restored.
http://codereview.appspot.com/5233042/diff/12001/lily/lily-guile.cc
File lily/lily-guile.cc (left):
http://codereview.appspot.com/5233042/diff/12001/lily/lily-guile.cc#oldcode72
Reviewers: ,
Message:
Hi,
This is a try to increase performance, especially under Windows (see
http://code.google.com/p/lilypond/issues/detail?id=1926).
As I don't use Windows to compile LilyPond, can someone test it?
Regards,
Bertrand
Description:
Optimizes note-heads.cc and introduces
http://codereview.appspot.com/4639065/diff/42001/lily/stem.cc
File lily/stem.cc (right):
http://codereview.appspot.com/4639065/diff/42001/lily/stem.cc#newcode855
lily/stem.cc:855: if (attach !scm_is_eq (style, ly_symbol2scm
(mensural))
I meant: the stem is aligned to the right of the
Here's the second part of my review. I saw that kievan notation has
beams, contrary to what I thought. If you're intrepid, you can also try
to implement the kievan beaming parameters in you KievanVoice.
Hold on, it's the end!
Bertrand
http://codereview.appspot.com/5233042/diff/1/lily/note-head.cc
File lily/note-head.cc (right):
http://codereview.appspot.com/5233042/diff/1/lily/note-head.cc#newcode79
lily/note-head.cc:79: out = fm-find_by_name (idx_either);
Unfortunately, this doesn't work. If the condition line 73 is false,
You can't solve the Kievan bar line problem without calculate every dot
position. I made a pure MetaFont version of the Kievan bar line:
fet_beginchar (kievan end of piece (slash), barline.kievan);
% this draws the end of piece figure
% this figure is placed at the end of the
Thanks Keith, I'll quickly fix that in a new issue.
http://codereview.appspot.com/4639065/diff/42001/lily/stem.cc
File lily/stem.cc (right):
http://codereview.appspot.com/4639065/diff/42001/lily/stem.cc#newcode853
lily/stem.cc:853: extract_grob_set (me, note-heads, heads);
... OK.
Pushed as bb7cac7b276bd7d1335523f3be8df815cf894ece.
http://codereview.appspot.com/4514042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Pushed as 688f5f1711d8ca07338385a2ae0191b1a8aae315.
http://codereview.appspot.com/4553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Pushed as 829f0ded77ee44ea6f0566fb5e5318802a8857ad.
http://codereview.appspot.com/5030053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Update done.
I think the C part is ok.
There's maybe a few things to change in the doc.
Shall I wait for a countdown or push directly?
Bertrand
http://codereview.appspot.com/4917044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
New patch set.
I hope this is ready for to be pushed, now.
http://codereview.appspot.com/4553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Thanks a lot, Neil.
Could you have a last look at the Scheme files?
I'm not sure of the indentation.
I created a new scm/text.scm file for the definitions I couldn't put
elsewhere.
Bertrand
http://codereview.appspot.com/4553056/
___
lilypond-devel
Hey!
I'm currently writing a doc entry that explains how to use replacements.
I have a few questions:
Where do you think I should put it? In NR 1.8.1 or 1.8.2?
Do you think I have to move the table from the regtest to the Appendix A
(and keep the rest of the regtest as a regtest)?
Bertrand
Thanks for applying these!
Sorry to bother you again with indentation, but you don't have to
replace spaces with tabulators in scripts/musicxml2ly.ly .
We decided that the rule for Python is 4 spaces per indentation level.
For more infos, see:
On 2011/09/20 12:07:31, J_lowe wrote:
Where do you think I should put it? In NR 1.8.1 or 1.8.2?
Hmm.. I'd say 3.3.3 actually
Oh, yes! This is better.
Do you think I have to move the table from the regtest to the
Appendix A (and
keep the rest of the regtest as a regtest)?
I am not
LGTM.
On 2011/09/20 14:15:53, Ian Hulin (gmail) wrote:
don't have to == don't need to, I assume you mean you shouldn't
with tabulators in scripts/musicxml2ly.ly .
Yes, this was a subtle DON'T DO IT! :)
http://codereview.appspot.com/4974078/
___
New patch set including some documentation work.
http://codereview.appspot.com/4553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Hmm, I don't understand one comment, but I agree with the others.
Thanks,
Bertrand
http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/input.itely#newcode1636
Documentation/notation/input.itely:1636: @end lilypond
Yes,
Pushed as 2fff263f10fd542454455994aea5ff3bbe075c7d
http://codereview.appspot.com/4912041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Pushed as f9251331576c94fa6aa4b85776917d3774b13b63
http://codereview.appspot.com/4387046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi Pal!
I updated the patch.
This wasn't working since Werner's e10a13.
It couldn't be applied to 0dcc93: I forgot some files that I added in
0e31cd.
Bertrand
http://codereview.appspot.com/5030053/
___
lilypond-devel mailing list
On 2011/09/18 21:47:04, janek wrote:
I think LGTM, but it would be great if you'd add a regtest to
demonstrate what
this patch is fixing.
I don't think so. mensural-ligatures.ly contains every case fixed by
this patch.
If I make a regtest to show such tiny graphical differences, then we
Hi Ian,
I have some comments. The rest of the patch LGTM.
Regards,
Bertrand
http://codereview.appspot.com/4974078/diff/3001/scm/document-identifiers.scm
File scm/document-identifiers.scm (right):
http://codereview.appspot.com/4974078/diff/3001/scm/document-identifiers.scm#newcode31
Pushed as:
0dcc93c0a5a97d048db2f7631966f41ae0059ab5
and
0e31cd90e44673eca7ac59705ce4bed33dd8e80e
Thank you all for this review!
Bertrand
http://codereview.appspot.com/4639065/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Hi Joe,
At last, a fix for that!
But this looks unfinished. Are you working on a solution that would
avoid having to specify the X-extent?
A fix that calculates the font size of the ParenthesesItem according to
the Y-extent of the parenthesized grobs would also be awesome :)
Bertrand
Reviewers: benko.pal,
Message:
Hi,
The new mensural style introduced with commit
0dcc93c0a5a97d048db2f7631966f41ae0059ab5 created some ugliness's in
mensural ligatures.
This patch fix these. I also added serifs to flexas.
Regards,
Bertrand
Description:
Unifies mensural ligatures with
New patch set.
After thinking about that during three weeks, I decided to remove the
long tie and even reduce the length of the default tie. Janek, thank you
for showing me that overshooting vowels was useless and maybe
disturbing.
I also changed the è for a e...
Thanks,
Bertrand
New patch set (inspired by Janek's ideas).
On 2011/09/14 21:05:28, benko.pal wrote:
* Use the left-stemmed longa in ligatures.
exactly what is this last one?
When note_shape is MLP_LONGA and the direction of the stem is UP, then
the left-stemmed longa is used.
I know, this should be
Thanks Janek.
Does someone else thinks the long tie should be removed?
Bertrand
http://codereview.appspot.com/4912041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Great. I removed the dynamics.
Is someone opposed to this patch to be pushed?
I suggest we put this issue in the next countdown.
Thanks,
Bertrand
http://codereview.appspot.com/4387046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Ok Pal, I removed the left-stemmed longa.
I don't know where you could put these rules.
Maybe we should start a new doc part that references the established
engraving rules?
Bertrand
http://codereview.appspot.com/4639065/
___
lilypond-devel mailing
New patch set.
'' and '@' have been added to the lexer.
'' is therefore a perfectly working escape character in lyrics.
Bertrand
http://codereview.appspot.com/4553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
LGTM, with the same comment.
http://codereview.appspot.com/4962072/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2011/09/12 22:37:05, janek wrote:
i've looked at latest screenshot attached to tracker issue and... wow!
It looks
really great!
Thanks a lot :)
http://codereview.appspot.com/4639065/diff/13002/ly/engraver-init.ly#newcode1063
ly/engraver-init.ly:1063: \override Stem #'thickness = #2
I'd
On 2011/09/12 22:37:05, janek wrote:
i've looked at latest screenshot attached to tracker issue and... wow!
It looks
really great!
Thanks a lot :)
http://codereview.appspot.com/4639065/diff/13002/ly/engraver-init.ly#newcode1063
ly/engraver-init.ly:1063: \override Stem #'thickness = #2
I'd
LGTM.
Is there any way to also move \time, \key, \repeat and \alternative from
the parser?
Bertrand
http://codereview.appspot.com/4969076/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2011/09/12 21:35:03, janek wrote:
can you tell me what needs work in this patch? I've read Mike's
comments, but i
don't understand what should be done.
This patch contains many copy/paste from the arpeggio engraver. We
obviously need a new grob, since the braces need some special grob
Thanks for your reviews!
On 2011/09/12 19:16:26, benko.pal wrote:
http://codereview.appspot.com/4639065/diff/13002/lily/mensural-ligature.cc#newcode147
lily/mensural-ligature.cc:147: Direction stem_dir = stem ?
get_grob_direction
(stem) : CENTER;
this is unneeded: there are no stemmed notes
On 2011/09/06 08:54:40, janek wrote:
I'm not sure what you mean. Are you saying that i should assign (i *
(gap +
stemthick), 0) to a variable in the for loop? I.e. sth like
for i := 0 step 1 until linecount - 1:
foobar := (i * (gap + stemthick), 0);
Ok, DynamicText and DynamicLineSpanner should be removed.
But what about the others?
* Simple trill is directed (as a Script), so TrillSpanner logically has
to be directed.
* Slurs, Ties and TupletBrackets are also directed, so I don't see any
reason for LigatureBrackets to behave differently.
This requires an update.
The patch fails to apply.
Bertrand
http://codereview.appspot.com/4917046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: J_lowe, dan_faithful.be,
Message:
I updated the patch and added a regtest.
Dan, I don't have time for now to rewrite the whole part combiner. Do
you want to do it ? If so, I can help you (at my level).
Bertrand
Description:
New partcombineUp and partcombineDown functions
Fix issue
Updated.
Bertrand
http://codereview.appspot.com/4387046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Just a quick review.
Bertrand
http://codereview.appspot.com/4931043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Sorry, I forgot to send the comments.
http://codereview.appspot.com/4931043/diff/1/mf/feta-noteheads.mf
File mf/feta-noteheads.mf (right):
http://codereview.appspot.com/4931043/diff/1/mf/feta-noteheads.mf#newcode168
mf/feta-noteheads.mf:168: gap# := (0.95 - 0.008 * design_size) *
stemthick#;
Reviewers: ,
Message:
Hi,
Graham asked me to document an small issue.
(http://codereview.appspot.com/4875054/)
And this became something bigger.
He also told me to push it directly, but I made a few changes in the
interface as I read the code and wrote the doc.
So the review concerns only the
LGTM :)
Bertrand
http://codereview.appspot.com/4875054/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
(Two minor comments however).
http://codereview.appspot.com/4875054/diff/1/lily/auto-beam-engraver.cc
File lily/auto-beam-engraver.cc (right):
http://codereview.appspot.com/4875054/diff/1/lily/auto-beam-engraver.cc#newcode172
lily/auto-beam-engraver.cc:172: return !scm_is_false (scm_call_4
That wasn't working 'cause I forgot to add some files to git...
This is now fixed.
Bertrand
http://codereview.appspot.com/4807053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
Hi everyone,
This follows 8d148ea05fa4b34f8cc3407e112363d715b27ad8
This is fully working, except for a small issue in make doc.
The two examples I put in the doc are working alone, but not with make
doc:
there should be short ties in ~è~, but we mysteriously get medium
use separate binding for (/ word-space 2)
Done.
http://codereview.appspot.com/4808074/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Pushed as 8d148ea05fa4b34f8cc3407e112363d715b27ad8
Bertrand
http://codereview.appspot.com/4808074/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Benchmark done on a book with many beams:
without the patch: 51.8s and 80 pages
with the patch: 52.2s and 83 pages
I also noticed some ugliness's between beams and figured bass. The
figures stay exactly where they were, but the stems are longer and
collide a bit with them.
Bertrand
Same remark for fingerings.
See input/regression/fingering-cross-staff.ly
Consecutive ties look better in input/regression/tie-single.ly
http://codereview.appspot.com/4898044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Here's how a better solution should work:
* create a smaller tie in addition to this one
* use a scm regexp to find this special case; something like:
#(use-modules (ice-9 regex))
#(display (regexp-substitute #f (string-match ([^:])~([^:])~([^:])
questa~è~in)
'pre 1 2 3 'post))
But I don't
Reviewers: ,
Message:
figuredBassCenterContinuations fails to merge continuation lines on if a
figure is composed of three or more figures.
This tiny patch fixes that.
Bertrand
Description:
Fixes figuredBassCenterContinuations.
Please review this at http://codereview.appspot.com/4868046/
I forgot these cases (o~è~in; a~è~in; o~è~an...). They are often elided
(quest'in instead of questa~è~in) by editors and composers.
So your view is that lyric ties are not used in the real world? I
still feel them as a pedagogy resource for young musicians or
something. Or maybe old scores
Secondly, it does not follow the policy for syllable separator, which
is '[space]--[space]', not '-[space]'.
I already fixed it in this patch (for every language).
Finally, 2nd and 3rd stanzas look _very_ improbable to me in that it
has three syllables on a single note, which requires two
What if we want a larger padding?
In your regtest, the clef collides with the third notehead when we set
the padding with:
\override Score.SpacingSpanner #'left-loose-column-padding = #2
There's also two trailing whitespaces.
Regards,
Bertrand
LGTM (still one trailing whitespace in the regtest).
Bertrand
http://codereview.appspot.com/4841052/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
This needs an update to be applied.
Cheers,
Bertrand
http://codereview.appspot.com/4813048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Changes done.
Passes make, regtest comparison and make doc.
Bertrand
http://codereview.appspot.com/4808074/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
Better handling of lyric ties:
* The space between two tied words is no more fixed. Its value is
word-space. The default space is therefore decreased.
* New glyph, so that we won't need an external font.
* Increased vertical space between words and tie. It is therefore now
This should work now.
http://codereview.appspot.com/4807053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
lily/text-interface.cc updated.
http://codereview.appspot.com/4553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi,
I think I found a proper way to calculate church rests.
I also updated so that it applies on the latest git HEAD.
Bertrand.
http://codereview.appspot.com/4536068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Hi Pál (besides, are you Pál Benkő the chess master?)
Thanks for this nice review.
1. about the very existence of usable-duration-logs -
ok, it's generic, but who uses this genericity?
is it not always (0 -1 -2 -3)?
is it not always a range with lower end -3?
is it not always a
I updated the patch.
There's now a list of special characters and a \replace command for
markups.
The escape character is now '§'. It's the only one that works great
with lyrics. And it isn't used elsewhere in LilyPond's syntax.
The syntax for using the list of special characters
Ouch...
The problem with '' is that it fails on lyrics:
this works:
\new Lyrics \lyricmode { as; }
but this doesn't:
\new Lyrics \lyricmode { s; }
There is the same kind of issues with almost every easy-to-type special
character:
@ % $ # \ / ^ ~ + = * ; ( ) [ ] { }
This is the exact list of
Reviewers: ,
Message:
Hi!
This patchs allows to add braces the same way as arpeggios.
Very useful for complex organ music.
Check this out, there is several examples:
http://imslp.org/wiki/12_Pi%C3%A8ces_pour_Orgue_(Gigout,_Eug%C3%A8ne)
For the moment, the new engraver is a clone of
http://codereview.appspot.com/4536068/diff/37002/lily/multi-measure-rest.cc#newcode241
lily/multi-measure-rest.cc:241: length = (2 -i) / 2;
The division by 2 changes the result. Not that I understand too well
what it is
supposed to be doing.
To be honest, I never understood well how this
I should have write 2 (-i + 1) instead of /2...
the +1 multiplies by 2, not divides.
Whoops, I meant -(i + 1)...
perhaps the best would be 1 -i.
Thanks.
When I told you I never understood , I wasn't kidding!
An update will follow this comment.
Bertrand
It doesn't need to be ordered.
It can have holes, but there's a small issue with this for now:
Church rests are only looking for maximum and minimum values. You can
therefore find longas in a church rest if you set usable-duration-logs
to '(0 -1 -3).
I don't know whether it's better to keep this
I updated the patch to work on the latest git HEAD.
After doing a clean regtest comparison (git clean -fxd, config, make,
make test-baseline, make check), I don't see anything.
The logs' names show this is due to Mike's last commits.
Regards,
Bertrand
http://codereview.appspot.com/4807053/
This is really dirty, but here's an update that does what you want (I
hope).
If you have ideas to clean a bit this mess...
Thanks,
Bertrand
http://codereview.appspot.com/4536068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://codereview.appspot.com/4536068/diff/30001/lily/multi-measure-rest.cc#newcode130
lily/multi-measure-rest.cc:130: double duration_log = -log2
(ml.Rational::to_double ());
log2 is a floating point operation not guaranteed to be exact. One
usually uses
a loop for figuring out a proper
Patch updated.
I abandonned the idea of including a special characters list.
http://codereview.appspot.com/4553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
A new file in ly with definitions using add-text-replacements!?
Like this?
germanHTML = #(add-text-replacements! '((ss; . ß)
[...])
englishLaTeX = [...]
This way, users can easily stack special characters with this syntax:
\paper {
\englishHTML
Yes, sorry for that.
Just for information, ancient fonts are stored in the parmesan-* files.
For the ancient fonts, we really need to think about a less hard-coded
solution.
http://codereview.appspot.com/4650052/
___
lilypond-devel mailing list
Updated with the good bounds.
The problem with mensural/neomensural/Petrucci styles is that they often
have different ledger line thicknesses. The best solution is to get
these ledger lines out of metafont. But this requires much more work.
For the moment, the exception is handled by the next
Maybe I should have been more clear in the description.
The glyph I added in feta-rests.mf is for the default style. You have to
remove mf/out/feta* before compiling.
There's no problem when I try this patch with your example.
But again, maybe I don't understand what you mean.
Thanks
Reviewers: ,
Message:
Minor patch that adds a useful glyph for baroque music.
Description:
New breve rest with ledger lines
Please review this at http://codereview.appspot.com/4650052/
Affected files:
M lily/rest.cc
M mf/feta-rests.mf
Index: lily/rest.cc
diff --git a/lily/rest.cc
Hi Mike!
There is a problem with your patch, I can not compile until the end,
even after git clean -fxd. This crashes when building internals.texi
And there is still the same spacing issues with number_raise and notes
higher than 9...
Thanks,
Bertrand
1 - 100 of 154 matches
Mail list logo
