On Thursday 27 April 2006 16:08, Han-Wen Nienhuys wrote:
> Erik Sandberg schreef:
> > I have changed the definition to:
> > IMPLEMENT_LISTENER (Scm_listener, listener, (Stream_event *ev))
> > {
> > ...
> > }
> >
> > Your suggestion doesn't work well because of some magic inside the macro.
>
> Can't
Quote from upcoming docs; please fill in the .
Cheers,
- Graham
Some default settings (such as the definitions for
@code{\header{}s) are stored as @code{.ly} files. Other
settings (such as the definitions of markup commands) are
stored as @code{.scm} (Scheme) files. Further explanatio
Quote from upcoming docs; please fill in the and fix the lilypond
code. :)
Cheers,
- Graham
-
Even music expressions can be passed in. Note that since we
want an articulation attached to the second variable, we
must #.
pattern = #(define-music-function (parser location x y) (ly:
David Feuer schreef:
On 5/2/06, Johannes Schindelin <[EMAIL PROTECTED]> wrote:
If you have two different versions of LilyPond, the same object could be
subtly moved between the two. But if you measure the area of the overlap
area between old and new bbox, you have a pretty good idea how much th
David Feuer schreef:
On 5/2/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
You're relying on specifics of music notation, eg. existence of ledger
lines and bar lines. What do you do when there are just lyrics or chord
names, or when there are no barlines (unmetered music) or no noteheads
(clus
On 5/2/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
You're relying on specifics of music notation, eg. existence of ledger
lines and bar lines. What do you do when there are just lyrics or chord
names, or when there are no barlines (unmetered music) or no noteheads
(clusters).
I think a more
On 5/2/06, Johannes Schindelin <[EMAIL PROTECTED]> wrote:
If you have two different versions of LilyPond, the same object could be
subtly moved between the two. But if you measure the area of the overlap
area between old and new bbox, you have a pretty good idea how much the
result deviates from
Hi,
On Tue, 2 May 2006, David Feuer wrote:
> On 5/2/06, Johannes Schindelin <[EMAIL PROTECTED]> wrote:
>
> >
> > This is worse than what Han-Wen suggested. His suggestion is easy, makes
> > sense and would improve development. Why come up with other ideas?
>
> I don't understand what he means
On 5/2/06, Johannes Schindelin <[EMAIL PROTECTED]> wrote:
This is worse than what Han-Wen suggested. His suggestion is easy, makes
sense and would improve development. Why come up with other ideas?
I don't understand what he means by bbox overlap areas. Maybe that's
my problem?
David
Hi,
On Tue, 2 May 2006, David Feuer wrote:
> One possibility: Take all image elements (on a high level I guess
> this would be grobs, on a low level it'd be stencil pieces). Separate
> them by type (stems here, noteheads there; rectangles here, glyphs
> there), and within each type sort them by
Hi,
On Tue, 2 May 2006, David Feuer wrote:
> On 5/1/06, Johannes Schindelin <[EMAIL PROTECTED]> wrote:
>
> > You cannot just compare PNGs. The really important information is: where
> > is the object, not: what color is that pixel. Just think about the
> > consequences of a small adjustment of t
David Feuer schreef:
One possibility: Take all image elements (on a high level I guess
this would be grobs, on a low level it'd be stencil pieces). Separate
them by type (stems here, noteheads there; rectangles here, glyphs
there), and within each type sort them by left edge of bounding box,
bo
On 5/2/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
How will you deal with two images that have different sizes? What will
happen if the entire 2nd image is shifted vertically and horizontally by
two pixels. This typically gives a huge difference (all staff lines and
stems will no longer over
David Feuer schreef:
On 5/1/06, Johannes Schindelin <[EMAIL PROTECTED]> wrote:
You cannot just compare PNGs. The really important information is: where
is the object, not: what color is that pixel. Just think about the
consequences of a small adjustment of the position. The difference of the
PN
On 5/1/06, Johannes Schindelin <[EMAIL PROTECTED]> wrote:
You cannot just compare PNGs. The really important information is: where
is the object, not: what color is that pixel. Just think about the
consequences of a small adjustment of the position. The difference of the
PNGs is potentially quit
Graham Percival schreef:
On 2-May-06, at 5:52 AM, Han-Wen Nienhuys wrote:
Graham Percival schreef:
On 2-May-06, at 5:05 AM, Han-Wen Nienhuys wrote:
+++ lilypond/Documentation/user/GNUmakefileTue May 2 12:05:28 2006
-EXTRA_DIST_FILES= $(LATEX_FILES) $(IMAGES)
+EXTRA_DIST_FILES= $(LATEX_
On 2-May-06, at 5:52 AM, Han-Wen Nienhuys wrote:
Graham Percival schreef:
On 2-May-06, at 5:05 AM, Han-Wen Nienhuys wrote:
+++ lilypond/Documentation/user/GNUmakefileTue May 2 12:05:28
2006
-EXTRA_DIST_FILES= $(LATEX_FILES) $(IMAGES)
+EXTRA_DIST_FILES= $(LATEX_FILES) $(IMAGES) README.t
Graham Percival schreef:
On 2-May-06, at 5:05 AM, Han-Wen Nienhuys wrote:
+++ lilypond/Documentation/user/GNUmakefileTue May 2 12:05:28 2006
@@ -5,7 +5,7 @@
# todo: add latex.
DVI_FILES = $(TELY_FILES:%.tely=$(outdir)/%.dvi)
-EXTRA_DIST_FILES= $(LATEX_FILES) $(IMAGES)
+EXTRA_DIST_FILES
On 2-May-06, at 5:05 AM, Han-Wen Nienhuys wrote:
+++ lilypond/Documentation/user/GNUmakefile Tue May 2 12:05:28 2006
@@ -5,7 +5,7 @@
# todo: add latex.
DVI_FILES = $(TELY_FILES:%.tely=$(outdir)/%.dvi)
-EXTRA_DIST_FILES= $(LATEX_FILES) $(IMAGES)
+EXTRA_DIST_FILES= $(LATEX_FILES) $(IMAGES
David Feuer schreef:
On 5/1/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
Given that we haven't had anyone writing or modifying the backend in the
past 5 years, I doubt that there is much need for this.
I've been working on it ...
yes, but using your work as an argument for your work is a
20 matches
Mail list logo
