Re: Please remove docs tags from snippets
2009/7/24 Graham Percival gra...@percival-music.ca: On Thu, Jul 23, 2009 at 08:55:21PM -0600, Carl Sorensen wrote: Please remove the docs tags from the following snippets: Specifying context with beatGrouping Using beatLength and beatGrouping Copy those snippets (the two files from input/lsr/) into input/new/. Then either: In the meantime, I have removed the docs tag and added the version-specific tag instead. (one day or another, I'll go through all version-specific snippets and remove the ones that are no longer relevant) Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please remove docs tags from snippets
On Fri, Jul 24, 2009 at 08:36:50AM +0200, Valentin Villenave wrote: 2009/7/24 Graham Percival gra...@percival-music.ca: On Thu, Jul 23, 2009 at 08:55:21PM -0600, Carl Sorensen wrote: Please remove the docs tags from the following snippets: Specifying context with beatGrouping Using beatLength and beatGrouping Copy those snippets (the two files from input/lsr/) into input/new/. Then either: In the meantime, I have removed the docs tag and added the version-specific tag instead. (one day or another, I'll go through all version-specific snippets and remove the ones that are no longer relevant) Bad idea, since we eventually *will* be releasing another 2.12, and it wouldn't be a bad idea to update lsr in it. It's not worth changing them back now, but as a general rule, don't do this. Wait until LSR is updated to 2.14, then process all the input/new/ stuff at once. I also still maintain that version-specific is a silly tag, since *every* lilypond snippet is version-specific. It just makes more work for you in the long run. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: 'line' articulation
Hi Valentin, Greetings, here is how to achieve what you're looking for (it has been added to the documentation snippets as well, since this notation is indeed common): http://lsr.dsi.unimi.it/LSR/Item?id=620 Thanks for adding this to the snippets. Maybe I'll post a better explanation later. Anyway, wouldn't it be better to add this to the font? For example, if I have understood this correctly, your snippet can't scale the font-size according to global-staff-size at this moment. Also it would be nice if LilyPond could determine the right position (above or under the staff) automatically, like it does with other articulation scripts. Another point is the horizontal position: If the line is placed above the stem, it seems better to me to have both in one horizontal position (not centered above the NoteHead), though I can't recognize any clear conventions for it up to now. Regards, Michael ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: visualizing grob ancestry
Here's one way of doing it (from within a music block).
Very nice! Perhaps this can be wrapped into an even more convenient
function so that a user just have to say, for example,
\getAncestry { grob }
at the place where grobs have to be manipulated.
Definitely very useful stuff!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: visualizing grob ancestry
Werner LEMBERG wrote:
Very nice! Perhaps this can be wrapped into an even more convenient
function so that a user just have to say, for example,
\getAncestry { }
at the place where grobs have to be manipulated.
Definitely very useful stuff!
Werner,
I reformatted the output (slightly) to minimize duplicates. Do you
prefer this version or the earlier one?
- Mark
\version 2.13.2
#(define (grob-name grob)
(if (ly:grob? grob)
(assoc-ref (ly:grob-property grob 'meta) 'name)
#f))
#(define (get-ancestry grob)
(if (not (null? (ly:grob-parent grob X)))
(list (grob-name grob)
(get-ancestry (ly:grob-parent grob X))
(get-ancestry (ly:grob-parent grob Y)))
(grob-name grob)))
#(define (format-ancestry lst generation)
(string-append
(symbol-string (car lst))
\n
(let ((X-ancestry
(if (list? (cadr lst))
(format-ancestry (cadr lst) (1+ generation))
(symbol-string (cadr lst
(Y-ancestry
(if (list? (caddr lst))
(format-ancestry (caddr lst) (1+ generation))
(symbol-string (caddr lst)
(if (equal? X-ancestry Y-ancestry)
(string-append
(make-string (* generation 3) #\space)
X/Y:
(if (list? (cadr lst))
(format-ancestry (cadr lst) (+ generation 2))
(symbol-string (cadr lst)))
\n)
(string-append
(make-string (* generation 3) #\space)
X: X-ancestry \n
(make-string (* generation 3) #\space)
Y: Y-ancestry \n)
#(define (display-ancestry grob)
(display
(string-append
(make-string 36 #\-)
\n
(format-ancestry (get-ancestry grob) 0
\relative {
%\once \override NoteHead #'before-line-breaking = #display-ancestry
f
%\once \override Accidental #'before-line-breaking = #display-ancestry
\once \override Arpeggio #'before-line-breaking = #display-ancestry
f as c\arpeggio
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: 'line' articulation
2009/7/23 Michael Käppler xmichae...@web.de: Thanks for adding this to the snippets. Maybe I'll post a better explanation later. Anyway, wouldn't it be better to add this to the font? For a single vertical line, I suspect this would be overkill – Unless we officialy include it alongside the other articulation marks. Werner, thoughts? http://lsr.dsi.unimi.it/LSR/Item?id=620 For example, if I have understood this correctly, your snippet can't scale the font-size according to global-staff-size at this moment. Yes it can. Also it would be nice if LilyPond could determine the right position (above or under the staff) automatically, like it does with other articulation scripts. It does now (I've updated the snippet to demonstrate this). Another point is the horizontal position: If the line is placed above the stem, it seems better to me to have both in one horizontal position (not centered above the NoteHead), though I can't recognize any clear conventions for it up to now. I think this would be a terrible idea. All articulation marks are centered with the note head. As a musician, I'd be terribly confused if I were to suddently encounter an articulation mark that's centered with the stem. If anyone can find a proper (documented) name for this vertical line articulation, I think we could consider adding it to the default LilyPond distribution. 2009/7/23 Mark Polesky markpole...@yahoo.com: an hour and a half from request to snippet. Nice work. I also notice that you're silently adding old ideas from the mailing list into the LSR. I even noticed one of my own... http://lsr.dsi.unimi.it/LSR/Item?id=553 Actually, I'm not sure whether I added this particular one or Neil did :-) Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: visualizing grob ancestry
2009/7/24 Werner LEMBERG w...@gnu.org: Definitely very useful stuff! ... and it would be a shame to lose track of it :-) What do you guys would like to do with it? LSR? Docs? Anywhere else? Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: 'line' articulation
2009/7/24 Valentin Villenave v.villen...@gmail.com: Another point is the horizontal position: If the line is placed above the stem, it seems better to me to have both in one horizontal position (not centered above the NoteHead), though I can't recognize any clear conventions for it up to now. I think this would be a terrible idea. All articulation marks are centered with the note head. As a musician, I'd be terribly confused if I were to suddently encounter an articulation mark that's centered with the stem. It's not correct that articulations are always centered with the note head. See http://code.google.com/p/lilypond/issues/detail?id=218 and the examples attached there. This is precisely what toward-stem-shift was introduced for. :-) Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: visualizing grob ancestry
Valentin Villenave wrote: What do you guys would like to do with it? LSR? Docs? Anywhere else? In a weird way, I don't think either is appropriate. Sometimes I wish there was something like an LSRD (for developers). You know, snippets showing how to trace grob-parents, how to sort objects by specific properties, how to know when to use #'(0 . 1) and when to use #'(-0.5 . 0.5). These sorts of things. What's sorely lacking in my opinion is a good reference documentation for stuff like music-map, how to get a context from within a music- function, the difference between ly:font-design-size and ly:font-magnification, stuff like that. I'm learning all this stuff on my own but it's like swimming through JELL-O. In the dark. And I think there are a lot of useful functions that are totally undocumented (like make-sequential-music and its kin). Sometimes I'll find stuff totally accidentally, like lily-library.scm. I could help with this documenting some of this stuff, but out of the regular players, I probably understand these things the least. But really, my fancy trick for tracing grob-parents is so snippetish, it wouldn't really belong in the conventional documentation. I think there should be a Snippets List for Developers node on the Developers resources page. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: 'line' articulation
2009/7/24 Maximilian Albert maximilian.alb...@googlemail.com: It's not correct that articulations are always centered with the note head. See http://code.google.com/p/lilypond/issues/detail?id=218 and the examples attached there. This is precisely what toward-stem-shift was introduced for. :-) Indeed (i didn't remember this). Having seen these examples, I have to admit that it looks less ugly than I imagined. Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: visualizing grob ancestry
2009/7/24 Mark Polesky markpole...@yahoo.com: In a weird way, I don't think either is appropriate. Sometimes I wish there was something like an LSRD (for developers). You know, snippets showing how to trace grob-parents, how to sort objects by specific properties, how to know when to use #'(0 . 1) and when to use #'(-0.5 . 0.5). These sorts of things. What's sorely lacking in my opinion is a good reference documentation for stuff like music-map, how to get a context from within a music- function, the difference between ly:font-design-size and ly:font-magnification, stuff like that. I'm learning all this stuff on my own but it's like swimming through JELL-O. In the dark. And I think there are a lot of useful functions that are totally undocumented (like make-sequential-music and its kin). Sometimes I'll find stuff totally accidentally, like lily-library.scm. I can certainly see your point. But really, my fancy trick for tracing grob-parents is so snippetish, it wouldn't really belong in the conventional documentation. I think there should be a Snippets List for Developers node on the Developers resources page. May I invite you to add such snippets to the LSR, and tag it as devel for now? Then we'll able to gather only devel-tagged snippets on such a page. Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: pushing to git question
Mark Polesky wrote Friday, July 24, 2009 3:16 AM One wrinkle is that compiling and testing things with make doc is (at the moment) out of the question on the computer that I currently have access to. Which means that I can't definitively prove that my patches don't break anything, even though in some cases (like fixing typos) there shouldn't be a problem. It is possible to check the syntax of the texinfo docs under Windows by running the file through lilypond-book and texi2html, but this doesn't help with doc string edits. Let me know if you guys would rather have me skip the proofreading step for trivial patches, but until I hear otherwise, I'll continue to run them through -devel. Go ahead and push trivial changes to doc strings and the docs themselves. Code changes are a different matter and must be reviewed first. If a commit causes a problem the next person to build LP will either fix it if it is easily fixed or simply revert your change, so as long as the change is trivial no real harm is done. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: visualizing grob ancestry
On Thu, Jul 23, 2009 at 9:11 PM, Mark Poleskymarkpole...@yahoo.com wrote: Does a grob-type always have the same set of parent-types? Not necessarily; It often depends on how the context that the grob originates from is nested into the rest of the contexts. Check the source code for Grob::set_parent() calls. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New format for autobeaming rules
On 7/22/09 4:15 PM, joenee...@gmail.com joenee...@gmail.com wrote:
I think this is pretty much ready to commit
http://codereview.appspot.com/88155/diff/3101/4032
File lily/beam-scheme.cc (right):
http://codereview.appspot.com/88155/diff/3101/4032#newcode2
Line 2: beam-scheme.cc -- Retrieving beam settings
could you call this beam-grouping-scheme.cc or something like that?
beam-scheme sounds like it contains routines for manipulating Beam
grobs.
Changed to beam-setting-scheme.cc. Changed beam-grouping.hh to
beam-settings.hh.
http://codereview.appspot.com/88155/diff/3101/4032#newcode12
Line 12: LY_DEFINE (ly_beam_settings, ly:beam-settings,
is this function really necessary?
Probably not. Instead of ly_beam_settings(context) we can do
context-get_property(beamSettings); there's no error checking in the
current function. So I guess I'll drop it.
http://codereview.appspot.com/88155/diff/3101/4032#newcode49
Line 49: ly_grouping_rules(settings,time_signature,rule_type),
formatting
Fixed.
http://codereview.appspot.com/88155/diff/3101/4032#newcode61
Line 61: SCM settings = ly_beam_settings(context);
formatting
Fixed
http://codereview.appspot.com/88155
On 7/22/09 5:23 PM, n.putt...@gmail.com n.putt...@gmail.com wrote:
http://codereview.appspot.com/88155/diff/3101/4027
File input/new/grouping-beats.ly (right):
http://codereview.appspot.com/88155/diff/3101/4027#newcode7
Line 7: Beaming patterns may be altered with the @code{beatGrouping}
property:
new texidoc using \overrideBeamSettings
http://codereview.appspot.com/88155/diff/3101/4032
File lily/beam-scheme.cc (right):
http://codereview.appspot.com/88155/diff/3101/4032#newcode10
Line 10: #include beam-grouping.hh
swap
Fixed
http://codereview.appspot.com/88155/diff/3101/4032#newcode26
Line 26: @var{rule-type} in @var{context}.)
no context arg, doc settings
Fixed, 2 places (ly_grouping_rules and ly_beam_grouping).
http://codereview.appspot.com/88155/diff/3101/4032#newcode28
Line 28: LY_ASSERT_TYPE (ly_is_pair, time_signature, 2);
scm_is_pair
Fixed
http://codereview.appspot.com/88155/diff/3101/4032#newcode30
Line 30:
type check also for settings?
Settings needs a list? type check, and I haven't seen one available
in c++. It shouldn't segfault, because we do a pair check before we
use it.
I can't use a pair check for the argument, because '() is valid for
settings.
I could use pair_or_empty, but it doesn't exist, and when I tried to
add it to flower/include/guile-compatibility.hh, where all the rest of
the types are defined, it gave me errors.
I'll put a FIXME in.
So I'm not doing a type check for settings, at least right now.
http://codereview.appspot.com/88155/diff/3101/4032#newcode34
Line 34: ly_assoc_get ((scm_list_2 (time_signature, rule_type)),
excess parens
D'OH! I'm not in scheme anymore!
Fixed.
http://codereview.appspot.com/88155/diff/3101/4032#newcode43
Line 43: Return grouping for beams of @var{ beam-type} in
@var{beam-type}
Fixed
http://codereview.appspot.com/88155/diff/3101/4032#newcode45
Line 45: @var{rule-type} in @var{context}.)
no context arg, doc settings
Fixed
http://codereview.appspot.com/88155/diff/3101/4032#newcode46
Line 46: {
type checks?
Put in for time_signature, rule_type.
Can't do one for beam_type, because it needs to be pair-or-symbol,
and I couldn't figure out how to add it.
I don't think it would segfault, because it's not dereferenced.
I'll put a FIXME in.
http://codereview.appspot.com/88155/diff/3101/4032#newcode57
Line 57: {
LY_ASSERT_SMOB (Context, context, 1);
Added.
If you don't do this, then unsmob_context () will return NULL if this
function is passed invalid arguments, leading to a null dereference for
get_property (timeSignatureFraction) - segfault
Thanks for teaching me about this.
http://codereview.appspot.com/88155/diff/3101/4033
File lily/beaming-pattern.cc (right):
http://codereview.appspot.com/88155/diff/3101/4033#newcode18
Line 18: #include beam-grouping.hh
sort
OK, done
http://codereview.appspot.com/88155/diff/3101/4034
File lily/include/beam-grouping.hh (right):
http://codereview.appspot.com/88155/diff/3101/4034#newcode8
Line 8:
To prevent multiple includes:
#ifndef BEAM_GROUPING_HH
#define BEAM_GROUPING_HH
(+ line 14)
http://codereview.appspot.com/88155/diff/3101/4034#newcode14
Line 14:
#endif // BEAM_GROUPING_HH
OK, done.
http://codereview.appspot.com/88155/diff/3101/4035
File lily/measure-grouping-engraver.cc (right):
http://codereview.appspot.com/88155/diff/3101/4035#newcode14
Line 14: #include beam-grouping.hh
sort
When I try to sort, it breaks compile because SCM is not defined
when beam-grouping.hh is included.
The best thing to do would be to include the proper file to define
SCM if it hasn't already been loaded.
But I couldn't find the header file that defined SCM through git
grep. Do you know which file I need to include?
Re: visualizing grob ancestry
Le jeudi 23 juillet 2009 à 14:11 -0700, Mark Polesky a écrit : I assume that a comprehensive visual parent-web demonstrating all such relationships would be too convoluted to have any practical value, and too difficult to generate to even justify trying such a thing It might be doable to draw these graphs in a way that satisfies us with Graphviz. However, before attempting this, there might be other things to improve in the IR, but you know this better than me. 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] IR 3 Backend: More auto-sorting.
Okay to apply? - Mark 0001-IR-3-Backend-More-auto-sorting.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: 'line' articulation
Thanks for adding this to the snippets. Maybe I'll post a better explanation later. Anyway, wouldn't it be better to add this to the font? For a single vertical line, I suspect this would be overkill – Unless we officialy include it alongside the other articulation marks. Werner, thoughts? http://lsr.dsi.unimi.it/LSR/Item?id=620 I don't object to add it to the font, so please add it as a feature request. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: visualizing grob ancestry
I reformatted the output (slightly) to minimize duplicates. Do you prefer this version or the earlier one? The more compact solution is the better one. A minor nit: Please start the output with a newline: I get this on the TTY: Interpretation der Musik... Vorverarbeitung der grafischen Elemente... Arpeggio X: PaperColumn X/Y: System ... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please remove docs tags from snippets
2009/7/24 Graham Percival gra...@percival-music.ca: Bad idea, since we eventually *will* be releasing another 2.12, and it wouldn't be a bad idea to update lsr in it. It's not worth changing them back now, but as a general rule, don't do this. I'm not too bothered if this happens, since deleted snippets stick out like a sore thumb when running makelsr.py. It's easy enough to revert any changes for snippets which shouldn't be removed from the stable version. Since the situation with the tarball is resolved now, I'll do a 2.12 LSR update shortly. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] IR 3 Backend: More auto-sorting.
2009/7/24 Mark Polesky markpole...@yahoo.com: Okay to apply? Not quite: + (map ref-ify indentation + (sort whitespace/indentation + (map symbol-string + (hashq-ref iface-grob-table + (car interface) + '())) + ly:string-ci?) (reverse ifaces))) +(ifacedoc (sort missing ref-ify indentation +(map (lambda (iface) + (if (pair? iface) + (symbol-string (car iface)) + (ly:error (_ pair expected in doc ~s) name))) + ifaces) +ly:string-ci?)) Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Markup commands \left-brace and \right-brace
2009/7/23 Valentin Villenave v.villen...@gmail.com: do you want me to open a Started page in the tracker to keep track of this patch? Cheers for the offer, but I don't think it's necessary. Once I've dealt with Carl's comments on the latest patch, I think it'll be ready for pushing. Then we can decide what's going to happen with \lookup. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New format for autobeaming rules
2009/7/24 Carl Sorensen c_soren...@byu.edu:
type check also for settings?
Settings needs a list? type check, and I haven't seen one available
in c++. It shouldn't segfault, because we do a pair check before we
use it.
ly_is_list (which is a wrapper for scm_list_p) (but see below)
I can't use a pair check for the argument, because '() is valid for
settings.
I could use pair_or_empty, but it doesn't exist
You could use ly_cheap_is_list, which does exactly this.
, and when I tried to
add it to flower/include/guile-compatibility.hh, where all the rest of
the types are defined, it gave me errors.
You'd need to add it to lily-guile.hh. guile-compatibility.hh is for
compatibility with guile 1.6.
type checks?
Put in for time_signature, rule_type.
Can't do one for beam_type, because it needs to be pair-or-symbol,
and I couldn't figure out how to add it.
The long way:
Add this to lily-guile.hh,
inline bool ly_is_symbol_or_pair (SCM x) { return scm_is_symbol (x) ||
scm_is_pair (x); }
and this to init_func_doc () in function-documentation.cc,
ly_add_type_predicate ((void*) ly_is_symbol_or_pair, symbol or pair);
then you can use LY_ASSERT_TYPE with the new predicate:
LY_ASSERT_TYPE (ly_is_symbol_or_pair, beam_type, 4);
The shorter way (and better since this is unlikely to be used
elsewhere) is to do this:
SCM_ASSERT_TYPE (scm_is_symbol (beam_type) || scm_is_pair (beam_type),
beam_type, SCM_ARG4, __FUNCTION__, symbol or pair);
sort
But I couldn't find the header file that defined SCM through git
grep. Do you know which file I need to include?
I think it's libguile.h, which is included in lily-guile.hh.
The following works for me:
beam-setting-scheme.cc:
#include beam-settings.hh
#include context.hh
beam-settings.hh:
(inside #define)
#include lily-guile.hh
decided not to restore original setting?
I had decided to restore it in a different form. 1/8 beams are (6), which
is equivalent to (3) in (3 . 4). All shorter beams will be (1 1 1).
Ah, so it is. I'll get the hang of the new settings eventually. :)
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: SVG backend: On-the-fly conversion of Emmentaler/Aybabtu glyphs to paths
Reviewers: joeneeman, http://codereview.appspot.com/96083/diff/1/8 File lily/pango-font.cc (right): http://codereview.appspot.com/96083/diff/1/8#newcode351 Line 351: // options. On 2009/07/21 18:43:10, joeneeman wrote: Could you please have a look at this? (after applying this patch, if you prefer). The more special cases we add for different backends, the messier this gets. Hopefully the revised conditional tests look before. Thanks for pointing this out. http://codereview.appspot.com/96083/diff/1/9 File lily/text-interface.cc (right): http://codereview.appspot.com/96083/diff/1/9#newcode80 Line 80: if (ly_symbol2string (encoding) == latin1) On 2009/07/21 18:43:10, joeneeman wrote: isn't there some possibility that we will have an encoding other than latin1, fetaNumber or fetaDynamic? Yes, certainly. I created lists for the music font encodings and text font encodings (scm/font.scm) and the new code searches through the music font encoding list to look for a match. http://codereview.appspot.com/96083/diff/1/12 File scm/output-svg.scm (right): http://codereview.appspot.com/96083/diff/1/12#newcode184 Line 184: (make-regexp (string-append glyph-name=\( On 2009/07/21 18:43:10, joeneeman wrote: I think it would be helpful if you gave an example or 2 of the sort of string you expect to match here. I'm a bit worried also about the fact that you require the attributes to be in a specific order. The new code uses a generalized regular expression that will match a glyph element with attributes in any order. The code is slower now, I think due to the complexity of the new regular expression. It might be a better idea if I rewrite this in C++ eventually. Description: SVG backend: On-the-fly conversion of Emmentaler/Aybabtu glyphs to paths - An API change for the word_stencil () function. This serves to filter all Emmentaler/Aybabtu glyphs that pass through the text-interface. - As a result, the socket backend will only receive utf-8-string, and the svg, scm, and null backends will receive a combination of utf-8-string and glyph-string. The ps and eps backends remain unchanged. - The SVG fonts are found, cached, and used to extract the appropriate glyphs for the stencil in question. Please review this at http://codereview.appspot.com/96083 Affected files: M lily/font-metric-scheme.cc M lily/font-metric.cc M lily/include/font-metric.hh M lily/include/modified-font-metric.hh M lily/include/pango-font.hh M lily/modified-font-metric.cc M lily/pango-font.cc M lily/text-interface.cc M scm/font.scm M scm/framework-svg.scm M scm/lily-library.scm M scm/output-ps.scm M scm/output-svg.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] IR 3 Backend: More auto-sorting.
Neil Puttock wrote: Not quite: indentation whitespace/indentation missing ref-ify indentation Thanks, Neil. My editor does confusing things with tabs. I hate them. Who would object if I just started running tabs-spaces on the source docs? I think we should have a strict no-tabs rule. And I'm in good company: http://lists.gnu.org/archive/html/lilypond-devel/2009-04/msg00103.html I'm not kidding. I'll do it. I'm tired of tabs. In the meantime, I'll wait for someone to verify the revised patch. Thanks! - Mark 0001-IR-3-Backend-More-auto-sorting.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
I've uploaded the patch for review at http://codereview.appspot.com/97119 It's pretty huge, but many of the changes are just due to changes in the properties that control vertical spacing. Also, annotate-spacing is broken, but the fixes for that should be confined to scm/page.scm. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ppppp but no fffff
We all okay with this patch? Of course it's a new command and a syntax change; I don't know if that means some special process has to be taken; updating the parser, etc. I have no idea, actually. Let me know. Thanks. - Mark 0001-Add-dynamic-script-f-update-docs.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
I've uploaded the patch for review at http://codereview.appspot.com/97119 Since I don't understand the code at all, I've only a minor comment: Please use two spaces after a full stop in documentation strings for consistence. Thanks for your hard work! Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
tabs vs. spaces in source code
On Fri, Jul 24, 2009 at 06:15:31PM -0700, Mark Polesky wrote: Thanks, Neil. My editor does confusing things with tabs. I hate them. Who would object if I just started running tabs-spaces on the source docs? I think we should have a strict no-tabs rule. And I'm in good company: http://lists.gnu.org/archive/html/lilypond-devel/2009-04/msg00103.html If the programmers, particularly Han-Wen (who appears to already agree with this) decide to make it a standard, fine. This should also be mentioned in the CG, just like all the doc policy items. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tabs vs. spaces in source code
Graham Percival wrote: On Fri, Jul 24, 2009 at 06:15:31PM -0700, Mark Polesky wrote: Thanks, Neil. My editor does confusing things with tabs. I hate them. Who would object if I just started running tabs-spaces on the source docs? I think we should have a strict no-tabs rule. And I'm in good company: http://lists.gnu.org/archive/html/lilypond-devel/2009-04/msg00103.html If the programmers, particularly Han-Wen (who appears to already agree with this) decide to make it a standard, fine. This should also be mentioned in the CG, just like all the doc policy items. Han-Wen, do you want to make it official? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tabs vs. spaces in source code
On Fri, Jul 24, 2009 at 10:30:30PM -0700, Graham Percival wrote: On Fri, Jul 24, 2009 at 06:15:31PM -0700, Mark Polesky wrote: Thanks, Neil. My editor does confusing things with tabs. I hate them. Who would object if I just started running tabs-spaces on the source docs? I think we should have a strict no-tabs rule. And I'm in good company: http://lists.gnu.org/archive/html/lilypond-devel/2009-04/msg00103.html If the programmers, particularly Han-Wen (who appears to already agree with this) decide to make it a standard, fine. This should also be mentioned in the CG, just like all the doc policy items. This would be really great. Just a small modification to my .vimrc, and then I'm set. :-) Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
