Re: hacky hack for bibliography
Le vendredi 22 janvier 2010 à 00:35 +, Graham Percival a écrit : > Does anybody object to this patch? Alternately, is anybody > willing to rewrite the GNUmakefile portion to make it like a real > makefile? I don't care too much for the makefile, but please fix the shebang of the Python script -- it should be the same as the ones of other Python scripts in scripts/build. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Use same fret-assignment code for FretBoards and TabStaff
In response to a request from Patrick Schmidt on the tablatures list, I became aware of the fact that we have two separate methods of finding strings and frets given notes -- one for the tab-note-heads-engraver and one for the fretboards-engraver. This didn't seem to me to be a very good situation, so I rewrote the code so that both engravers call the procedure specified in the context property noteToFretFunction to get frets and strings from notes. Please review the patch at http://codereview.appspot.com/186268/show Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: Centered Poet rolling of the paper 2.12.2 and 2.13.1
On 2010-01-11, Alexander Kobel wrote: > > The attached patch for fill-line (scm/define-markup-commands.scm) > should do the expected thing. > fill-line currently only considers the extents of the stencils, not > their position relative to the X-origin; with the patch, they are > shifted according to the first stencil argument. > > Sorry in advance for non-proper indentation, a probably non-proper > patch format, and not having in on Rietveld or something like this, > but to be honest, I don't want to take the time to bother with git's > functionality and a coding account setup right now. Thanks. Looks great! I cleaned up the indentation and pushed your patch. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
hacky hack for bibliography
Does anybody object to this patch? Alternately, is anybody
willing to rewrite the GNUmakefile portion to make it like a real
makefile?
Cheers,
- Graham
>From 5cee5fd0b10f4a6ed8f86de4591cda23bea1ec27 Mon Sep 17 00:00:00 2001
From: Graham Percival
Date: Fri, 22 Jan 2010 00:18:18 +
Subject: [PATCH] Build: hackily add bibliography.
This is quite yucky, but it's taken over an hour and frankly
nobody's complained that the bibliography has been broken for a
year, so I'm inclined just to go with this.
---
Documentation/GNUmakefile| 20 +++
Documentation/essay/literature.itely | 39 +-
scripts/build/html-to-texi.py| 94 ++
3 files changed, 140 insertions(+), 13 deletions(-)
create mode 100644 scripts/build/html-to-texi.py
diff --git a/Documentation/GNUmakefile b/Documentation/GNUmakefile
index 9592e54..d2a4eb2 100644
--- a/Documentation/GNUmakefile
+++ b/Documentation/GNUmakefile
@@ -100,6 +100,26 @@ $(outdir)/ROADMAP:
cp $(top-src-dir)/ROADMAP $(outdir)
$(outdir)/contributor.texi: $(outdir)/ROADMAP
+### bad hack for badly-integrated bibliography
+$(outdir)/engravingbib.itexi:
+ BSTINPUTS=$(src-dir)/essay $(buildscript-dir)/bib2html \
+ -o $(outdir)/colorado.html \
+ $(src-dir)/essay/colorado.bib
+ $(buildscript-dir)/html-to-texi \
+ < $(outdir)/colorado.html > $(outdir)/colorado.itexi
+ BSTINPUTS=$(src-dir)/essay $(buildscript-dir)/bib2html \
+ -o $(outdir)/computer-notation.html \
+ $(src-dir)/essay/computer-notation.bib
+ $(buildscript-dir)/html-to-texi \
+ < $(outdir)/computer-notation.html > $(outdir)/computer-notation.itexi
+ BSTINPUTS=$(src-dir)/essay $(buildscript-dir)/bib2html \
+ -o $(outdir)/engravingbib.html \
+ $(src-dir)/essay/engravingbib.bib
+ $(buildscript-dir)/html-to-texi \
+ < $(outdir)/engravingbib.html > $(outdir)/engravingbib.itexi
+
+$(outdir)/essay.texi: $(outdir)/engravingbib.itexi
+
###
### Targets
diff --git a/Documentation/essay/literature.itely b/Documentation/essay/literature.itely
index 3479046..2ebc7a3 100644
--- a/Documentation/essay/literature.itely
+++ b/Documentation/essay/literature.itely
@@ -13,6 +13,17 @@
@node Literature list
@chapter Literature list
+FIXME: blah
+
+...@menu
+* Short literature list::
+* Long literature list::
+...@end menu
+
+...@node Short literature list
+...@section Short literature list
+
+
If you need to know more about music notation, here are some
interesting titles to read.
@@ -69,17 +80,19 @@ practices.
@end table
-The source archive includes a more elaborate b...@tex{} bibliography of
-over 100 entries in
-...@ifhtml
-...@ifset bigpage
-...@uref{../bibliography/index.html, the bibliography}.
-...@end ifset
-...@ifclear bigpage
-...@uref{../../bibliography/index.html, the bibliography}.
-...@end ifclear
-...@end ifhtml
-...@ifnothtml
-...@file{documentation/@/bibliography/}.
-...@end ifnothtml
+
+...@node Long literature list
+...@section Long literature list
+
+...@subheading Colorado
+
+...@include colorado.itexi
+
+...@subheading Computer notation
+
+...@include computer-notation.itexi
+
+...@subheading Engraving
+
+...@include engravingbib.itexi
diff --git a/scripts/build/html-to-texi.py b/scripts/build/html-to-texi.py
new file mode 100644
index 000..9635964
--- /dev/null
+++ b/scripts/build/html-to-texi.py
@@ -0,0 +1,94 @@
+#! /usr/bin/python
+
+import re
+import sys
+
+header = '''
+'''
+
+print header
+
+body = sys.stdin.read ()
+body = re.sub ('(?ms)', '', body)
+body = re.sub ('(?ms)\n*\s*', r'@ignore\n\...@end ignore', body)
+body = re.sub ('(?ms)(.*?)', r'@ref{\1,\2}', body)
+
+body = re.sub ('(?ms) *', r'@node \1 ', body)
+body = re.sub ('(?ms)(.*?)', r'@chapheading \1', body)
+body = re.sub ('(?ms)(.*?)', r'@unnumberedsec \1', body)
+#body = re.sub ('(?ms) *', '', body)
+#body = re.sub ('(?ms)(.*?)', r'@node \...@unnumberedsec \1', body)
+
+body = re.sub ('(?ms)]*src="*([^">]*)(.png|.jpeg)"*.*?>', r'@image{\1,,,\2}', body)
+body = re.sub ('\n*\s*\n*', r'@*\n', body)
+body = re.sub ('\n*]*>\s*\n*', r'@*\n', body)
+body = re.sub ('(?ms)(.*?)', r'@emph{\1}', body)
+body = re.sub ('(?ms)(.*?)', r'@quote{\1}', body)
+body = re.sub ('(?ms)(.*?)', r'@code{\1}', body)
+body = re.sub ('(?ms)(.*?)()', r'@item\n\1\n', body)
+body = re.sub ('(?ms)(.*?)()', r'@item\n\1\n\2', body)
+body = re.sub ('(?ms)(.*?)()', r'@item\n\1\n\2', body)
+body = re.sub ('(?ms)(.*?)()', r'@item\n\1\n\2', body)
+body = re.sub ('(?ms)(.*?)()', r'@item\n\1\n\2', body)
+body = re.sub ('(?ms)(.*?)()', r'@item\n\1\n\2', body)
+body = re.sub ('(?ms)(.*?)()', r'@item\n\1\n\2', body)
+body = re.sub ('(?ms)', r'@itemize', body)
+body = re.sub ('(?ms)', r'@end itemize', body)
+
+# added for the bib => bib2html => html2texinfo chain. -gp
+body = re.sub ('(?ms)', r'', body)
+body = re.sub ('(?ms)(.*?)()', r'', body)
+body = re.sub ('(?ms)', r'', body)
+body = re.sub ('(?ms)', r'', body)
+body = re.sub ('(?ms)', r'', body)
+
+body = re.sub ('(?ms)', r
Re: Avoid orphan/widow lines (issue190102)
Thanks, pushed.
On Thu, 2010-01-21 at 23:02 +, shinga...@gmail.com wrote:
> http://codereview.appspot.com/190102/diff/1/2
> File lily/constrained-breaking.cc (right):
>
> http://codereview.appspot.com/190102/diff/1/2#newcode529
> lily/constrained-breaking.cc:529: last_markup_line_ =
> to_boolean(last_scm);
> On 2010/01/21 20:45:06, joeneeman wrote:
> > space before (
>
> Done.
>
> http://codereview.appspot.com/190102/diff/1/2#newcode531
> lily/constrained-breaking.cc:531: first_markup_line_ =
> to_boolean(first_scm);
> On 2010/01/21 20:45:06, joeneeman wrote:
> > space before (
>
> Done.
>
> http://codereview.appspot.com/190102/diff/1/7
> File lily/paper-book.cc (right):
>
> http://codereview.appspot.com/190102/diff/1/7#newcode554
> lily/paper-book.cc:554: {
> On 2010/01/21 20:45:06, joeneeman wrote:
> > indentation should be
> > if (blah)
> >{
> > foo();
> >}
>
>
> Done.
>
> http://codereview.appspot.com/190102/diff/1/7#newcode558
> lily/paper-book.cc:558: ps->set_property
> ("first-markup-line", SCM_BOOL_F);
> On 2010/01/21 20:45:06, joeneeman wrote:
> > extra spaces?
>
> Done.
>
> http://codereview.appspot.com/190102/show
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoid orphan/widow lines (issue190102)
http://codereview.appspot.com/190102/diff/1/2
File lily/constrained-breaking.cc (right):
http://codereview.appspot.com/190102/diff/1/2#newcode529
lily/constrained-breaking.cc:529: last_markup_line_ =
to_boolean(last_scm);
On 2010/01/21 20:45:06, joeneeman wrote:
space before (
Done.
http://codereview.appspot.com/190102/diff/1/2#newcode531
lily/constrained-breaking.cc:531: first_markup_line_ =
to_boolean(first_scm);
On 2010/01/21 20:45:06, joeneeman wrote:
space before (
Done.
http://codereview.appspot.com/190102/diff/1/7
File lily/paper-book.cc (right):
http://codereview.appspot.com/190102/diff/1/7#newcode554
lily/paper-book.cc:554: {
On 2010/01/21 20:45:06, joeneeman wrote:
indentation should be
if (blah)
{
foo();
}
Done.
http://codereview.appspot.com/190102/diff/1/7#newcode558
lily/paper-book.cc:558: ps->set_property
("first-markup-line", SCM_BOOL_F);
On 2010/01/21 20:45:06, joeneeman wrote:
extra spaces?
Done.
http://codereview.appspot.com/190102/show
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: between-system-space or between-system-spacing ?
On Sun, 2010-01-17 at 04:50 -0800, -Eluze wrote: > i thinke there is a remainder from earlier versions in the notation > reference: > > 4.6.2 Changing spacing > > between-system-space = #0.1 > > should be replaced by > > between-system-spacing = #0.1 Thanks, fixed. Although it should be between-system-spacing = #'((space . 0.1) (padding . 0.0)) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoid orphan/widow lines (issue190102)
lgtm, modulo some more formatting nitpicking. If you fix the formatting
and mail me the patch, I'll push it.
Here it is.
--
Boris Shingarov
Work on Lilypond under grant from Sonus Paradisi / Jiri Zurek (Prague),
Czech Science Foundation, Project No. 401/09/0419
diff --git a/lily/constrained-breaking.cc b/lily/constrained-breaking.cc
index 2fead24..31d2cf0 100644
--- a/lily/constrained-breaking.cc
+++ b/lily/constrained-breaking.cc
@@ -525,4 +525,8 @@ Line_details::Line_details (Prob *pb, Output_def *paper)
title_ = to_boolean (pb->get_property ("is-title"));
compressed_lines_count_ = 1;
compressed_nontitle_lines_count_ = title_ ? 0 : 1;
+ SCM last_scm = pb->get_property ("last-markup-line");
+ last_markup_line_ = to_boolean (last_scm);
+ SCM first_scm = pb->get_property ("first-markup-line");
+ first_markup_line_ = to_boolean (first_scm);
}
diff --git a/lily/include/constrained-breaking.hh b/lily/include/constrained-breaking.hh
index bb8a1d0..f36ab74 100644
--- a/lily/include/constrained-breaking.hh
+++ b/lily/include/constrained-breaking.hh
@@ -52,6 +52,8 @@ struct Line_details {
class. */
int compressed_lines_count_;
int compressed_nontitle_lines_count_;
+ bool last_markup_line_;
+ bool first_markup_line_;
Line_details ()
{
@@ -71,6 +73,8 @@ struct Line_details {
title_ = false;
compressed_lines_count_ = 1;
compressed_nontitle_lines_count_ = 1;
+last_markup_line_ = false;
+first_markup_line_ = false;
}
Line_details (Prob *pb, Output_def *paper);
diff --git a/lily/include/page-breaking.hh b/lily/include/page-breaking.hh
index 2e5283d..d497d49 100644
--- a/lily/include/page-breaking.hh
+++ b/lily/include/page-breaking.hh
@@ -127,6 +127,7 @@ public:
bool too_few_lines (int line_count) const;
Real min_whitespace_at_top_of_page (Line_details const&) const;
Real min_whitespace_at_bottom_of_page (Line_details const&) const;
+ int orphan_penalty () const;
protected:
Paper_book *book_;
@@ -179,6 +180,7 @@ private:
int max_systems_per_page_;
int min_systems_per_page_;
vsize system_count_;
+ int orphan_penalty_;
vector current_configurations_;
vector current_chunks_;
diff --git a/lily/page-breaking.cc b/lily/page-breaking.cc
index e0a08c0..dc71659 100644
--- a/lily/page-breaking.cc
+++ b/lily/page-breaking.cc
@@ -174,6 +174,7 @@ Page_breaking::Page_breaking (Paper_book *pb, Break_predicate is_break)
systems_per_page_ = max (0, robust_scm2int (pb->paper_->c_variable ("systems-per-page"), 0));
max_systems_per_page_ = max (0, robust_scm2int (pb->paper_->c_variable ("max-systems-per-page"), 0));
min_systems_per_page_ = max (0, robust_scm2int (pb->paper_->c_variable ("min-systems-per-page"), 0));
+ orphan_penalty_ = robust_scm2int (pb->paper_->c_variable ("orphan-penalty"), 10);
if (systems_per_page_ && (max_systems_per_page_ || min_systems_per_page_))
{
@@ -1415,3 +1416,9 @@ Page_breaking::min_whitespace_at_bottom_of_page (Line_details const &line) const
// FIXME: take into account the height of the footer
return max (0.0, max (padding, min_distance + line.extent_[DOWN]));
}
+
+int
+Page_breaking::orphan_penalty () const
+{
+ return orphan_penalty_;
+}
diff --git a/lily/page-spacing.cc b/lily/page-spacing.cc
index 8919257..8dbf183 100644
--- a/lily/page-spacing.cc
+++ b/lily/page-spacing.cc
@@ -245,6 +245,18 @@ Page_spacer::calc_subproblem (vsize page, vsize line)
penalty += lines_[page_start-1].page_penalty_
+ (page % 2 == 0) ? lines_[page_start-1].turn_penalty_ : 0;
+ /* Deal with widow/orphan lines */
+ /* Last line of paragraph is first line on the new page */
+ if ((page_start > 0) &&
+ (page_start < lines_.size ()) &&
+ (lines_[page_start].last_markup_line_))
+ penalty += breaker_->orphan_penalty ();
+ /* First line of paragraph is last line on the previous page */
+ if ((page_start > 0) &&
+ (page_start < lines_.size ()) &&
+ (lines_[page_start-1].first_markup_line_))
+ penalty += breaker_->orphan_penalty ();
+
demerits += penalty;
if (demerits < cur.demerits_ || page_start == line)
{
diff --git a/lily/paper-book.cc b/lily/paper-book.cc
index 79896e6..f1ee2ec 100644
--- a/lily/paper-book.cc
+++ b/lily/paper-book.cc
@@ -516,15 +516,20 @@ Paper_book::get_system_specs ()
paper_->self_scm (),
page_properties,
scm_car (s));
- for (SCM list = texts ; scm_is_pair (list) ; list = scm_cdr (list))
+ Prob *ps;
+ SCM list;
+ for (list = texts ; scm_is_pair (list) ; list = scm_cdr (list))
{
SCM t = scm_car (list);
// TODO: init props
- Prob *ps = make_paper_system (SCM_EOL);
+ ps = make_paper_system (SCM_EOL);
ps->set_property ("page-break-permission",
ly_symbol2scm ("allow"));
ps->set_property ("page-turn-permission",
ly_symbol2scm ("allow"));
+ ps->set_property ("last-markup-line", SCM_BOOL_F);
+ ps->set_property ("
Re: Docs links in pdf version
On Thu, Jan 21, 2010 at 09:24:32PM +0100, Jean-Charles Malahieude wrote:
> Attending to a seminar about French typography, I've printed several
> pages of "notation.fr.pdf", and noticed something disturbing.
> -8<
> See also
>Notation Reference: Section A.8.1 [Font], page 458, [New dynamic
> marks], page 90, [Manual
> repeat marks], page 107, Section 1.8.3 [Fonts], page 187.
>Snippets: Section “Text” in Snippets.
>Internals Reference: Section “TextScript” in Internals Reference.
>Installed files: ‘scm/define-markup-commands.scm’.
> -8<
This is all expected.
> 1- I accept to see the "installed files" within simple quotes
> since each of them might be considered as a /single/ word;
> but why [Fonts] but “Text” and “TextScript” ?
Because [Fonts] is in the same manual, whereas "Text" (in
snippets) is in a different manual. Texinfo doesn't know what
page Text will be in that manual.
> 2- Since the name of the manual is mentioned in front of the line,
> would it be possible to avoid its multiple repeat, which become
> annoying as soon as there are more links?
No. At least, not without manually writing
@ref{foo}, @ruser{bar}
which would be too annoying for the doc writers.
> I can be of no help about this, it's just to notice.
There's a number of problems with the pdf output, but nobody cares
sufficiently to look into it. I have a list of another couple of
items, which I haven't even bothered to add to the issue tracker.
I'm currently trying to clear out all my "lilypond todo" lists
(I've found 3 text files so far, not counting all my paper lists),
so hopefully they'll migrate to the tracker in the next week or
so. I'll be adding them as "postponed", though.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enhancement: Page breaking to avoid widow lines
On Thu, 2010-01-21 at 13:51 -0500, Boris Shingarov wrote: > Quoting Joe Neeman : > > > Again, I'd suggest uploading patches to codereview.appspot.com, which > > provides nice formatting and makes it easy to have multiple reviewers. > > Ok, I've created Issue 190102 for this. > > One inconvenience that I see with the "upload.py" tool, is that I don't > see a way to specify the exact target of the diff -- i.e. which files > to run the diff against, or even make some tweaking to the diff > contents before submitting them. This is useful because the working > copy usually contains other, temporary, changes, that I do not want to > be submitted. In this particular case, there is the workaround for the > incorrect page height estimation, which got its way into the submitted > patch because upload.py just grabbed all the changes. I think the simplest way is to create a new git branch with only the changes you want to include. Since you'll want to create separate commits for separate issues anyway, it shouldn't be much extra trouble. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoid orphan/widow lines (issue190102)
lgtm, modulo some more formatting nitpicking. If you fix the formatting
and mail me the patch, I'll push it.
Also, in the future, please add lilypond-devel@gnu.org to the CC list (I
should have mentioned it, sorry).
http://codereview.appspot.com/190102/diff/1/2
File lily/constrained-breaking.cc (right):
http://codereview.appspot.com/190102/diff/1/2#newcode529
lily/constrained-breaking.cc:529: last_markup_line_ =
to_boolean(last_scm);
space before (
http://codereview.appspot.com/190102/diff/1/2#newcode531
lily/constrained-breaking.cc:531: first_markup_line_ =
to_boolean(first_scm);
space before (
http://codereview.appspot.com/190102/diff/1/7
File lily/paper-book.cc (right):
http://codereview.appspot.com/190102/diff/1/7#newcode554
lily/paper-book.cc:554: {
indentation should be
if (blah)
{
foo();
}
http://codereview.appspot.com/190102/diff/1/7#newcode558
lily/paper-book.cc:558: ps->set_property
("first-markup-line", SCM_BOOL_F);
extra spaces?
http://codereview.appspot.com/190102/show
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Docs links in pdf version
Hi all! Attending to a seminar about French typography, I've printed several pages of "notation.fr.pdf", and noticed something disturbing. I checked the English version, guessing it might be a problem with translations only, but it is not. Here is an example of page 189 of the notation manual: -8< See also Notation Reference: Section A.8.1 [Font], page 458, [New dynamic marks], page 90, [Manual repeat marks], page 107, Section 1.8.3 [Fonts], page 187. Snippets: Section “Text” in Snippets. Internals Reference: Section “TextScript” in Internals Reference. Installed files: ‘scm/define-markup-commands.scm’. -8< and how it appears in html : -8< See also Learning Manual: Moving objects. Notation Reference: Align, Text marks. Snippets: Text. Internals Reference: TextScript. Installed files: ‘scm/define-markup-commands.scm’. -8< Then I have several questions: 1- I accept to see the "installed files" within simple quotes since each of them might be considered as a /single/ word; but why [Fonts] but “Text” and “TextScript” ? 2- Since the name of the manual is mentioned in front of the line, would it be possible to avoid its multiple repeat, which become annoying as soon as there are more links? I can be of no help about this, it's just to notice. Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enhancement: Page breaking to avoid widow lines
Quoting Joe Neeman : Again, I'd suggest uploading patches to codereview.appspot.com, which provides nice formatting and makes it easy to have multiple reviewers. Ok, I've created Issue 190102 for this. One inconvenience that I see with the "upload.py" tool, is that I don't see a way to specify the exact target of the diff -- i.e. which files to run the diff against, or even make some tweaking to the diff contents before submitting them. This is useful because the working copy usually contains other, temporary, changes, that I do not want to be submitted. In this particular case, there is the workaround for the incorrect page height estimation, which got its way into the submitted patch because upload.py just grabbed all the changes. Use to_boolean Done. put this on two lines Done. false instead of 0 Done. (2) seems to be pretty important, no? If there is only one line then the current code will avoid placing it first or last on any page. Implemented. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch: issue #659
Marc Hohl wrote: Alexander Kobel schrieb: Marc Hohl wrote: Trevor Daniels schrieb: It is easy for a user to move the sign to the end of the staff lines with \once \override Score.BarLine #'extra-offset = #'(1 . 0) \once \override Score.SpanBar #'extra-offset = #'(1 . 0) [...] Would it make sense to provide another varsegno symbol which looks exactly as the one I have drawn, but has no positive witdh (to the right of the center)? This sounds more elegant than the tweak above, but I'm not sure if this alone is worth the effort of an additional symbol. Me, too. It still feels somewhat clumsy to do it in this way, but on the other hand - if it looks alright, one more sign in the font should not be a big problem. I just noticed that the 'extra-offset won't influence the spacing of the notes before the bar line. The better property to tweak should be the right-edge extra space, but this does not work if the line ends prematurely. (See the attached example.) Still, like Trevor I'm not sure why modifying the X-extent does not work - this should be the favourite option, theoretically equivalent to another glyph without positive width, right? Another idea: Is it possible to have a double bar line at the end of a line, and the segno bar line at the beginning of the next? What about ".S" doing this, as opposed to "S", or have an additional "||S" and "S||"? I must admit that I don't have lots of references for this symbol and its use. If this is a sensible default, there is no problem in defining ".S" just doing what you proposed. Can you do some investigations? As you posted the examples in the tracker, I think you are the most important source of informations here ;-) I don't really know if I saw the "||-before-break, S-after-break" combination, but I think it makes sense to offer it since coda parts are often seperated by double bar lines when the "default" segno sign is above them. I'll see what I can find in real examples. I don't think I have anything more at my place, though, so I'll have to look through the repertoire of my choir. (Again, I can't remember to have it seen in any non-Bosworth & Co. scores...) I'll give you feedback ASAP. Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Update program requirements.
On Wed, Jan 20, 2010 at 10:44 PM, Mark Polesky wrote: > Patrick McCarty wrote: >>> * New compiling requirements: >>> - GCC 4.0 >> Are you sure this is required? >> OpenBSD's gcc 3.3.5 apparently works okay with this patch: >> http://lists.gnu.org/archive/html/lilypond-devel/2009-12/msg00324.html > > I think Graham was suggesting that by updating the requirement, > we're not saying that older versions will fail, but rather that we > are no longer officially supporting them. GCC 3.3.5 is from 2004 > (http://gcc.gnu.org/viewcvs/tags/gcc_3_3_5_release/?view=log) and > there have been six major releases since then. GCC 4.0 came in > 2005, so it's not such a huge leap. I don't know what LilyPond's previous policy has been with regard to this. But it seems that by specifying a *minimum* version in configure, we are suggesting that earlier versions *will* fail (depending on the use case). > Besides, shouldn't GCC 3.3 users be upgrading anyway? Maybe. > Because of this, I wouldn't mind moving the requirement up to > 4.2.4, but there may be some issues I'm not aware of. Let me > know if there are. GUB uses 4.1.2 to compile LilyPond for certain platforms: http://github.com/janneke/gub/blob/master/gub/specs/gcc.py > Otherwise, what do you think? I think we need more feedback from others regarding GCC before taking action. The Guile and Ghostscript minimum versions are fine with me. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Working on scheme engravers
Eric Knapp wrote Thursday, January 21, 2010 2:36 AM My goal is to determine the fingering number and the string number Is there a way to determine the digit and string-number directly by name? It looks like the articulations are a list. Would it be possible to loop through the list and determine what each one is? Exactly. See how it is done for fretboards in scm/translation-functions.scm. The relevant section starts around line 291. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
