) __
Is there any way to do this in Lilypond (without using fully manual
line breaking)? If not, what would be involved in implementing it?
Ideally, the reminder would only appear if the following lyric
extender were longer than some user-specified minimum.
David Feuer
On 3/9/07, Mats Bengtsson [EMAIL PROTECTED] wrote in
bug-lilypond (top-posting reversed):
Nick Mengham wrote:
I down loaded the win XP version of Lilypond all it does is make a rather
ordinary notated scale in PDF. It seem a very large file to do that. Is there
some thing else I should be
Forget everything I said. I made a stupid error.
David
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
than the user-set
vocal-shortest-duration-space. That way, the text would be fairly
tight in faster parts, as it is now in all parts, and looser in slower
parts.
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org
I forgot to send this to the list the first time.
-- Forwarded message --
From: David Feuer [EMAIL PROTECTED]
Date: Oct 1, 2006 1:03 PM
Subject: Re: Scheme State
To: Ralph Little [EMAIL PROTECTED]
On 9/29/06, Ralph Little [EMAIL PROTECTED] wrote:
I could set aside some
Forgot to send this to the list the first time.
-- Forwarded message --
From: David Feuer [EMAIL PROTECTED]
Date: Oct 1, 2006 1:06 PM
Subject: Re: Scheme State
To: Ralph Little [EMAIL PROTECTED]
On 10/1/06, David Feuer [EMAIL PROTECTED] wrote:
Probably a better
question
On 5/4/06, Johannes Schindelin [EMAIL PROTECTED] wrote:
Hi,
On Wed, 3 May 2006, David Feuer wrote:
If we're looking to measure small changes, area of union minus area of
intersection, divided by the area of the union, would probably be
good.
If a really nasty bug creeps in, which makes
On 5/4/06, David Feuer [EMAIL PROTECTED] wrote:
Hm hm... Dividing by the area of the union is bad. Maybe divide by
the area of the old ones?
Wait a sec I'm not sure dividing by the area of the union is
really bad. Getting a value near 1 somewhere should be plenty to flag
the file
On 5/4/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
Johannes Schindelin wrote:
No. A perfect match would be 1. Which means that file should _not_ be
flagged.
well whatever. I think it is wise to do a division, if only to get a
scale-free measure.
I'll think about it a bit more, but
On 5/3/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
Mats Bengtsson schreef:
Following the ideas of other alignments in LilyPond, you could let the
offset be represented by a tuple (X offset and Y offset), where 0 means
center, -1 is left/lower edge, +1 is right/top edge.
Note that the
On 5/2/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
There are various ways of comparing numbers. The point is that you need
to know which pairs of numbers/rectangles/etc. to compare. For that, you
need to get the elements in a canonical order, and that *must* be done
with discrete
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
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
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
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
to be considered significant and what kinds you want to be
considered insignificant.
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
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 ...
it should take geometry and appearance into account, ie. where the
symbols end up
On 4/27/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
Frankly, I'm a bit mystified why you're spending so much time on
building the ultimate postscript backend. The backend is not a
performance bottleneck. If you think the current PS code is inefficient,
then you should have a look at the rest
Once a stencil has been wrapped in another stencil, is its bounding
box ever used? I suspect that while a new stencil is built from one
or more existing stencils, it shouldn't contain those stencils in
their entirety.
Update on thoughts for the PostScript part of a redesigned backend system:
-
Sorry... My last message had an entirely inappropriate subject line.
David
Update on thoughts for the PostScript part of a redesigned backend system:
- Stop using postscript coordinate translation altogether. This will
increase the space needed to represent coordinates, but
- Optionally
On 4/27/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
the bbox isn't used, but it's no problem, since the child bbox isn't
stored, just the expression.
Oh, I missed that.
Frankly, I'm a bit mystified why you're spending so much time on
building the ultimate postscript backend. The backend
On 4/27/06, Werner LEMBERG [EMAIL PROTECTED] wrote:
:-) It seems I have a special talent for that. I've even found a bug
in MetaFont...
A bug in MetaFont Are there bounties on those?
David
___
lilypond-devel mailing list
looks powerful enough.
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
sure it's
sophisticated enough to make a UTF-8 CMap, and I think GhostScript
might come with one, though I'm not sure.
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On 4/17/06, Cameron Horsburgh [EMAIL PROTECTED] wrote:
For example the example given puts the relevant line in one long line:
\set StaffGroup.systemStartDelimiterHierarchy
= #'(SystemStartSquare (SystemStartBracket a (SystemStartSquare b)) d)
Even small examples will wrap, making
On 4/16/06, Johannes Schindelin [EMAIL PROTECTED] wrote:
And BTW, Lily's PostScript code's main purpose is to produce something
which Ghostscript turns into a PDF. So, the PostScript does not have to
adher strictly to the specs, but to what Ghostscript understands.
Next month, if all goes
On 4/16/06, Erlend Aasland [EMAIL PROTECTED] wrote:
Hi David,
The two dash functions (draw_dashed_{line,slur}) set the dash pattern with
setdash, but they forget to reset it (so the output looks a bit weird after
the first dashed line has been drawn). The attached patch will fix this, but
I have too much schoolwork to do, so I won't be able to work on
LilyPond for about a month. When I return I'd like to try refactoring
the output system, if that's not been done yet.
David
___
lilypond-devel mailing list
lilypond-devel@gnu.org
On 4/14/06, Carl D. Sorensen [EMAIL PROTECTED] wrote:
Actually, complex numbers are nothing more than 2-D vectors, but in the
real-imaginary plane rather than the x-y plane. In fact, when we use
complex numbers, we draw them in a plane indistinguishable from x-y
(real is x, imaginary is y).
On 4/14/06, Carl D. Sorensen [EMAIL PROTECTED] wrote:
After reviewing what the scheme code would look like if we used complex
numbers, and thinking about the benefits of having nice names for data
types and procedures, I think I agree that we ought to have our own
coordinate pair type and
I've read some more about Postscript fonts (ugh), and I don't really
understand why we use fonts the way we do. Using a CIDFont without a
CMap is just gross. I think if we set the fonts up a bit better, we
should be able to use xyshow rather than glyphshow, which is
infinitely prettier. Also,
On 4/13/06, Jan Nieuwenhuizen [EMAIL PROTECTED] wrote:
David Feuer writes:
In C++ we have Offset, which has a number of complex_* functions. We
also have complex-to-offset and use offset pairs in SCM, but I do not
know if we have any such functions in SCM.
I don't either.
Does scm/guile
I haven't written the code yet, but I have, conceptually at least,
completely solved the problem of unfilled rounded polygons in both
PostScript and SVG. The key is to use the outline as a clipping path,
and create path that coincides with it everywhere except perhaps at
the corners which is
On 4/12/06, Geoff Horton [EMAIL PROTECTED] wrote:
Do you mean this one:
http://upload.wikimedia.org/wikipedia/en/7/79/Oldbassclef.png ?
Yes. If I create one in Metafont, would it be hard to add to the progam?
I'm not a LilyPond expert, so I'll pass this on to the list, but I
would expect it
On 4/12/06, Jan Nieuwenhuizen [EMAIL PROTECTED] wrote:
Ok, I'll add an assert in the c++ code and remove the parameter to match
your next polygon scheme code.
I'm not sure where you'll add it. The code in lookup.cc always calls
the scheme function with filled?=#t
I would suggest that the
On 4/12/06, Jan Nieuwenhuizen [EMAIL PROTECTED] wrote:
Indeed; no need for an assert. But in that case ... found it
define-markup-command.scm:
(define-markup-command (triangle layout props filled) (boolean?)
A triangle, filled or not
we use it to draw `white' triangles for chords...
On 4/12/06, Jan Nieuwenhuizen [EMAIL PROTECTED] wrote:
David Feuer writes:
The easiest way to keep this working the same as it does now is to
name my new functions filled-polygon and retain the old (really
simple) polygon drawers in the backends.
Hmm. I'd much rather just have a simple
them as a separate module, should vectors
be pairs (convenient), or should they be SRFI 9 records (pretty)?
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
I should have mentioned that I don't know yet how C++ code interacts
with SRFI 9 records, if that's feasible at all. I'm sure C++ can
interact with native Guile records, but I'm not sure I really want to
deal with those.
David
___
lilypond-devel
On 4/11/06, Geoff Horton [EMAIL PROTECTED] wrote:
But what if a person wants to refer to a Scheme variable (as in the
point-and-click example)? I agree it's far from ideal, but I think
switching to auto-quoting arguments would break more than it solves.
Probably the best thing would be to
.
Having now looked at a little more of the code, I don't think a PLT
port would be feasible right now. If at a later date the
functionality provided by C++ and Scheme are sufficiently separated,
or most of the functionality of the C++ code gets shifted over to
Scheme, it might become reasonable.
David
the
rounding radius vary smoothly with the angle, using the exact
specified radius only for 90 degree corners. I haven't experimented
with it yet, but I have a couple of ideas for how it might vary.
David Feuer
(define (polygon points radius)
(let ((pointlist (vector-list points)))
(format
On 4/4/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
top-post fixed
David Feuer wrote:
Why are properties set by default in the bottom context? I think it
would make more sense to do what Postscript does with dictionaries and
set them by default in the lowest context that has those
On 4/7/06, Joe Neeman [EMAIL PROTECTED] wrote:
In constrained-breaking, I use the square of the force rather than its
absolute value -- I made the change for precisely this reason.
The sum of absolute values will generally be more stable than the sum
of squares, or so the stat books say.
On 4/7/06, Joe Neeman [EMAIL PROTECTED] wrote:
I think they have to be. In the page-turning case, if G is much smaller than
F, the penalties for a bad turn get ignored. Conversely, if G is too big, we
sacrifice nice spacing. I hadn't actually thought of this before, but it
looks like this
Is there an option I can pass to LilyPond to get it to print out
representations of its stencils? I see code for something like that,
but I don't see how to activate it.
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http
On 4/7/06, Joe Neeman [EMAIL PROTECTED] wrote:
I don't think TeX has to deal with this problem because each paragraph is
self-contained. In LilyPond, every line affects every other line. (This is
just an initial reaction. It might change after I read the TeXbook.)
Therefore penalties in TeX
Also index entries using the word blank rather than empty.
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Does it really make sense to have a separate bug-lilypond list?
David
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
to deal with the contents.
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On 4/6/06, David Feuer [EMAIL PROTECTED] wrote:
2. The more I read the code and think about it, the more I think
stencil interpretation should be pushed to the back end and written in
Scheme.
Put this another way: instead of having the common stencil code drive
the backends, the backends
On 4/6/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
David Feuer wrote:
The way I understand it, Lilypond constructs a stencil to represent an
object, and the largest stencils (lines? pages?) are then interpreted
to produce output. I suggest that the back ends should get the
stencils
On 4/6/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
David Feuer wrote:
I don't see it. stencil-interpret.cc seems neither particularly
complex nor particularly efficient. Speaking of which, all the Scheme
code heavily overuses lists. Guile provides records and structures
(I'm not sure
I forgot that R5RS Scheme supports delay and force. These might make
things a bit simpler.
David
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On 4/6/06, David Feuer [EMAIL PROTECTED] wrote:
I forgot that R5RS Scheme supports delay and force. These might make
things a bit simpler.
Yeah... We still need to set up the coroutines ourselves, but delay
and force should take care of the thunks for us. We need to be sure
to lose track
Sorry I've been thinking aloud on the list.
My proposal can be simplified more: no need for a round robin for the
pages when there's one for the stencils. Different master outputters
can have different interfaces, so EPS output may get different
interfaces than the PS and TeX ones. Suppose for
On 4/6/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
I don't understand. The entire \book is formatted in one a global
processing step, since page breaking is a global optimization There is
no such thing as formatting the first page.
Okay. My ideas are a little imprecise, particularly the
On 4/6/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
It doesn't happen like this. For technical reasons, it's not possible to
have more than one backend active: some parts, in particular the text
handling, has to do different things depending on the backend(s) active.
If you don't think that
def
I'll send a patch in a few minutes.
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
I think this patch should fix it.
Changelog:
* music-drawing-routines.ps (draw_round_box): removed testing artifact.
(draw_circle): Hopefully fixed regression.
Improved documentation for several procedures.
David Feuer
fix.diff
Description: Binary data
Patch now has directory names.
David Feuer
newpatchdir.diff
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
I should note that this patch probably has bugs.
David
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
program. Obviously this
would be loads of work, and I don't even know if it would be feasible,
but that's what I'm thinking.
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
What's the rationale behind the division into C++ and Scheme? I don't
quite see why Lilypond uses C++ and Guile rather than using a serious
Scheme implementation (like PLT) and working to shift code from C++
over to Scheme.
David
___
lilypond-devel
Lilypond draws beams as polygons. The polygon code (in lookup.cc) is
hairy, and probably slow. It'd be much easier and faster to make
beams trapezoids. More generally, from reading the comments on the
polygon code, I get the feeling it might be best to get rid of it
altogether. I'm looking
convinced that the right goal is to make the engraving algorithms so
good that tweaking is rarely necessary, but to make the tweaking
system as elegant as possible.
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org
On 4/4/06, Pedro Kröger [EMAIL PROTECTED] wrote:
Paul Scott [EMAIL PROTECTED] writes:
It's simple. Scheme code will probably never run as fast as C++.
Unless, of couse, one uses a scheme compiler that can generate fast
code, like bigloo [1].
Or a Scheme system like PLT that uses JIT
On 4/4/06, Geoff Horton [EMAIL PROTECTED] wrote:
After upgrading to 2.8.1, I notice that the .pdf files produced are
considerable larger, on the order of about 5 to 10 times the size
formerly produced. This has a detrimental effect on my ability to
store and distribute, so much that I
, and
implementations like PLT provide lots of object-oriented kinds of
things if you're into that. What I'd really like to see is more
functional (in the FP sense) management of Stencils. set!s make me
nervous.
David Feuer
___
lilypond-devel mailing list
Why are properties set by default in the bottom context? I think it
would make more sense to do what Postscript does with dictionaries and
set them by default in the lowest context that has those properties.
David Feuer
___
lilypond-devel mailing
While I'm at it, the Scheme and Postscript polygon drawers are only
ever called with the filled parameter true, so please get rid of that
parameter.
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman
On 4/4/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
we don't do level 1 anyway. I think that glyphshow is L2.
You're right! So I can remove the level 1 emulation code I put in for
selectfont. And we should change the PostScript comment at the top of
music-drawing-routines.ps to indicate
Does anyone actually set /testing to test round boxes anymore, or is
that a historical artifact? I've already fixed it (in a recent patch)
so it doesn't waste time, but it's still wasting (a bit of) space and
making the code less pretty.
David Feuer
On 4/4/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
David Feuer wrote:
music-drawing-routines.ps to indicate level 2. I really don't have
the time to set myself up to compile the LilyPond sources. Could you
setting yourself is actually very easy nowadays, at least if you're
running
of it myself. Let me know.
David Feuer
macro.diff
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
The attached patch stops LilyPond from compulsively gsave/grestoring
everything. It changes some procedures so they don't need
gsave/grestore, and it adds gsave/grestore and translate to the ones
that do. Do you think I should put the gsave/grestore back into
draw_polygon, or is it okay as is?
: if something actually uses this,
it should be implemented using draw_round_box, rather than
duplicating all the code.)
* Removed print_letter (print_glyphs is now simple enough not to need a helper)
David Feuer
diff -u --strip-trailing-cr original/framework-ps.scm latest/framework-ps.scm
+% it's possible to eliminate the coordinate variables by doing [ /Rect [ 7 3
+% roll It is, however, kind of ugly. Another possibility, probably better,
is
+% to put the [ and ] into the other side, so this procedure will take an
array.
+% Yet another is to make pdfmark take its
much about PostScript. I write it with
the reference up on my screen, and fonts are one of the parts I
understand least. If I get a chance, I'll ask the Ghostscript people
about it.
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
the lines of the staff and all the clefs at once. You get
the idea.
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Grr I forgot to delete the euclidean_length procedure from
music-drawing-routines.ps. It is no longer used.
David
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
When might I expect feedback on the new patch?
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On 3/31/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
According to the Postscript reference, selectfont can be used with CID
resources as well as regular fonts. Unfortunately, I can't make the
utf-8 regression test work either with or without my changes, so I
can't be sure I got this
- move to the right by ggeo.x_offset - place another glyph.
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On 3/28/06, Werner LEMBERG [EMAIL PROTECTED] wrote:
- (if cid?
- /CIDFont findresource
- findfont)
I don't understand this? How are CID resources supposed to be
loaded now?
According to the Postscript reference, selectfont can be used with
changed to formats.
David Feuer
pschanges.diff
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On 3/29/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
David Feuer wrote:
to go. Basic question: should drawing procedures all start at the
current point (they don't now)? Should they all start at (0,0) (they
don't now)? Or should some start one place and some another place,
with some
On 3/28/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
David Feuer wrote:
thanks for you patch. CAn you have a second look; there are some style
issues
Sure. I can't deal with them right now, but I'll try to fix them up
this evening.
I'd like
to know if it might be possible to make
It looks like my email client messed up the lines on the patches I
sent in. I'm trying again with a different one. Hope this works. I
also attached the patches, just in case. Note: I'm pretty sure these
changes won't break CID fonts, but it'd be a good idea to double check
that.
David Feuer
I made some changes to the Postscript backend, making the output more
readable (especially for text), around 10% shorter, and, at least in theory,
also faster to interpret. These changes are just a start, but I hope they
help. I'd like to know if it might be possible to make the backend work
I sent this some hours ago, but haven't seen it yet. Is the mailing list
broken, or just really slow?
Original message:
I made some changes to the Postscript backend, making the output more readable
(especially for text), around 10% shorter, and, at least in theory, also faster
to interpret.
of the manual.
Thanks for your consideration,
David Feuer
_
On the road to retirement? Check out MSN Life Events for advice on how to
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
of the manual.
Thanks for your consideration,
David Feuer
_
FREE pop-up blocking with the new MSN Toolbar get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01
93 matches
Mail list logo
