Yes, thanks. 'Tis done.
Bertrand
http://codereview.appspot.com/4536068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
A small patch that redefines the braces:
* Increases the width of the smallest.
* Reduces the width of the largest.
* Increments more consistently between two braces (there were too many
tiny braces).
* Increases the thickness of the ends of braces.
* Sharpens a little the
http://codereview.appspot.com/4553056/diff/9003/input/regression/markup-special-characters.ly
File input/regression/markup-special-characters.ly (right):
http://codereview.appspot.com/4553056/diff/9003/input/regression/markup-special-characters.ly#newcode7
Thanks again, Neil !
I applied these.
http://codereview.appspot.com/4536068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Done !
Regression tests are ok.
http://codereview.appspot.com/4553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Ok, I'll change these. What about 'No.' ? 'numero;', 'N°' or 'N°;' ?
http://codereview.appspot.com/4553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
If I understand well, there's no need anymore for manual beams in
cross-staff cases ?
If so, I suggest you remove the manual beams from
input/regression/beam-collision-cross-staff.ly.
You should also remove the knownissues in keyboard.itely and the last
part of changes.tely's entry.
Thanks,
New patch set with Carl's ideas.
I don't know if replacement-alist should be defined by default.
Nor if '' is a good escape character. I chose it because it's quicker
to type on a french keyboard than '@'.
Bertrand.
http://codereview.appspot.com/4553056/
Carl's suggestions done !
Bertrand
http://codereview.appspot.com/4536068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Thanks, 'tis done.
http://codereview.appspot.com/4536068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
longest-church-rest is the longest rest displayed in church rests.
One may want to only print a whole rest in a breve measure but print
breve and longa rests in a church rest.
But I agree with you, it can be changed for the min value of
usable-duration-logs.
You're right for
Nitpicks done :
duration-log-list changed for usable-duration-logs (Thanks Carl !)
Whitespaces and tabs removed.
Bertrand
http://codereview.appspot.com/4536068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Reviewers: ,
Message:
A feature that helps text typesetting.
Bertrand
Description:
New alist to replace special characters.
Please review this at http://codereview.appspot.com/4553056/
Affected files:
A input/regression/markup-special-characters-shorthands.ly
M lily/text-interface.cc
M
This prints every character with its shorthand, but works bad because of
'\t', '\v' and '\n' :
\version 2.15.0
\include special-characters.ly
#(define-markup-list-command (show-special-characters layout props) ()
(interpret-markup-list layout props
(1) You can do it using \override #'(replacement-string-max-length . 0)
But I agree, there's a problem with backslashes.
(2) What if we define something like \tz when we want 'ꜩ' and just
write tz when no ligature is needed ? This isn' t so constraining.
(3) I know, this is another change to
Yes.
Knowing this, I suggest we keep whitespaces, punctuation, quotes and
word dividers (with some small changes).
There's still something that bothers me : isn't there some special
characters that you can't do with you keyboard ?
Even on linux I can't type some symbols like ſ or • without
...definitely not user-friendly!
I totally agree it's better to type in UTF and that's what I always did
with LilyPond. But this REALLY wastes time when we type several symbols
and ligatures.
Making this easier should be the OS's job.
I'll think more about this and make another patch set.
Ok, I worked hard on this and did a brand new patch :
http://codereview.appspot.com/4536068/
http://codereview.appspot.com/4543055/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
Just one regtest change :
in multi-measure-rest.ly, the two longas of the third measure are
tranformed into a maxima (as expected).
Regards,
Bertrand
Description:
Adds longas, maximas and non-standard tweaks to MultiMeasureRest
Please review this at
This name is nice and generic, which is good. Bit it has no
information content
as far as I can see. Can we make it more explicit by changing either
the name
(to something like usable-duration-logs) or the description (to
something like
List of duration-logs that can be used in
I applied it to the more recent git HEAD without any problem.
By maxima, I mean the glyph rests.M3.
I chose to use maximas because they are easier to read than two longas
with many space in between.
In such cases, this is mandatory :
{ \compressFullBarRests \time 4/1 R\longa*10 }
Sorry, I misread your first sentence. Forget the first line of my
previous post.
http://codereview.appspot.com/4536068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I was also wondering : shall we add another exception for half rests ?
I always found this disturbing to have a whole rest in 2/4.
I know this is what traditional editors do, but...
If we do so, then it would be better and cleaner to make an alist of
durations instead of this mess.
And add a
I know these rules. They will always be LilyPond's default behavior.
What I meant is if someone want to change this (for contemporary music
or anything else), it doesn't have to be difficult to do.
If we want to create a non-standard capability, it would seem to me
that the
user-settable
Reviewers: ,
Message:
Longas are now handled in multi-measure rests.
Regards,
Bertrand
Description:
Handles longa in MultiMeasureRest
Please review this at http://codereview.appspot.com/4543055/
Affected files:
M lily/multi-measure-rest-engraver.cc
M lily/multi-measure-rest.cc
M
I don't know if this is a joke, so I answer to David's question :
of course there is no jump between the 256th and the 257th !
Refer to this message to see before/after :
http://lists.gnu.org/archive/html/lilypond-devel/2011-05/msg00150.html
http://codereview.appspot.com/4518052/
http://codereview.appspot.com/4518052/diff/2002/mf/feta-braces.mf
File mf/feta-braces.mf (right):
http://codereview.appspot.com/4518052/diff/2002/mf/feta-braces.mf#newcode151
mf/feta-braces.mf:151: fatten := 1 + fatten_factor - min ( number *
fatten_factor / 256, fatten_factor);
Thanks !
Hum...
:)
Thanks ! This works great. Updated.
http://codereview.appspot.com/4518052/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: carl.d.sorensen_gmail.com,
Message:
Thanks for the review !
Patch updated.
I don't know if there's a better way to solve this issue.
As big braces look good, I decided to limit the changes to the smallest
ones.
Description:
Fattens the 256 first braces.
Please review this at
http://codereview.appspot.com/4518052/diff/2002/mf/feta-braces.mf
File mf/feta-braces.mf (right):
http://codereview.appspot.com/4518052/diff/2002/mf/feta-braces.mf#newcode150
mf/feta-braces.mf:150: save fatten;
That's what I thought at first. Then I saw save number; line 129, so I
decided to
Reviewers: ,
Message:
This fixes issue 1605. Keith's patch takes the \ bug into account. But
this bug also occures with simple markups, so I assume this hasn't to be
fixed.
Description:
Fix issue 1605
PDF metadata for titles now handle unclosed parentheses.
Please review this at
I made another patch here :
http://codereview.appspot.com/4377054/
http://codereview.appspot.com/4382052/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Mistake : this produces the right output when we have title = \a, but
PDF metadata is wrong and only shows a. I'll include \\ in my next
update of the patch.
http://codereview.appspot.com/4377054/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Done. I don't know if this is the correct place for ps-quote.
http://codereview.appspot.com/4377054/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Besides, I noticed two special markups :
\markup \n and \markup \t
What is their use ? I know \n stands for UNIX carriage return and \t
stands for tab.
But here...
By the way, this doesn't cause any problem with metadata.
http://codereview.appspot.com/4377054/
How ? output-ps is dependant of framework-ps... When I move it to
output-ps, it doesn't work.
Thanks !
Bertrand
http://codereview.appspot.com/4377054/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
I added a line to the test. And I don't think we need to do something
about newlines.
http://codereview.appspot.com/4377054/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
Small patch that takes new grobs in account :
Accidental suggestions, dynamics, ligatures and spanned trills.
Regards,
Bertrand
Description:
Add some polyphonically directed grobs
Accidental suggestions, dynamics, ligatures and spanned trills added to
Reviewers: ,
Message:
A few nitpicks.
Description:
Autobeam nitpicks (following Carl's fix).
Please review this at http://codereview.appspot.com/4385050/
Affected files:
M scm/time-signature-settings.scm
Index: scm/time-signature-settings.scm
diff --git a/scm/time-signature-settings.scm
Of course, I agree that we should get rid of the two-pass algorithm. But
it's really tricky to do it the clean way :o\
As the issues I pointed out need deep changes, I think the two-pass
algorithm is better than nothing.
For the moment, we can also avoid these issues by displaying footnotes
There is still a vertical spacing bug in the footnotes :
\markup {
\footnote e e
\footnote e ef
}
There should be a fixed distance between the baseline and the number.
For the thin space, I meant in-text words and numbers :
Cromorne ²
Which is more elegant than :
Cromorne ²
or
Cromorne²
Hi Mike,
Nice job, as usual !
However, I noticed some obvious problems. You probably already know
them.
Here, the padding :
\markup {
\footnote b c
\footnote e f
}
Here, the horizontal space between markup and number :
\markup {
\footnote d e
\footnote f g
}
Also : why are in-text
http://codereview.appspot.com/4237059/diff/1/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
http://codereview.appspot.com/4237059/diff/1/scm/define-markup-commands.scm#newcode159
scm/define-markup-commands.scm:159: (markup #:fill-line
I suggest you move this
New patch here : http://codereview.appspot.com/4213042
http://codereview.appspot.com/4167063/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
New patch with Neil's changes.
http://codereview.appspot.com/4182056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
I meant : we can't use this to do a footnote when in a markup or
markuplines.
Something like :
\markuplines { bla bla bla \footnote { Oh yes ? } bla bla bla }
I know lilypond-book is the best solution for this issue. But it would
be easier if LilyPond had a native support of these features.
:p
Great job !
There's no word to thank you enough !
Thanks thanks thanks,
Bertrand
http://codereview.appspot.com/4167063/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Wow, nice job Mike !
I am also currently trying to solve this issue.
With Scheme only I managed to do a good solution for endnotes.
I have some suggestions for your work :
* There should be more space between separator line and footnotes.
* Maybe a smaller separator, like LaTeX does. line-width
Reviewers: carl.d.sorensen_gmail.com,
Message:
A few questions.
http://codereview.appspot.com/4182056/diff/1/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
http://codereview.appspot.com/4182056/diff/1/scm/define-markup-commands.scm#newcode994
Changes done !
It is more clean now.
I'm not sure if the commands are in the right categories.
I also noticed numerous commands have @code instead of @var and vice
versa in their descriptions. Center-align's args or fill-line's
line-width for example.
Should I do a small patch to fix these ?
Maybe add \pattern to the changelog ?
http://codereview.appspot.com/4182056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Update on http://code.google.com/p/lilypond/issues/detail?id=1517
http://codereview.appspot.com/4172047/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Yes, sorry...
I made a new codereview issue : http://codereview.appspot.com/4182056/
...(currently reading the Contributor's Guide again)...
http://codereview.appspot.com/4172047/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
You might search through the issues list for issues with the label Frog.
Those are intended to be tasks that those with only limited LilyPond
development experience can tackle.
:o) What a wonderful organization ! And GOP hasn't started yet !
I'll do my best on these issues !
BTW, I have
101 - 154 of 154 matches
Mail list logo
