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.
D
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
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
n shortest notes, but never tighter 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
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
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 co
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 w
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 fl
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
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 quantitie
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:
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
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, 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
tially quite large, even if the difference of the location is
quite small.
I'm not convinced. What if you apply a slight blur to both images and
then subtract them?
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.
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 u
nds of changes you
want 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 4/30/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
David Feuer wrote:
> On 4/27/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
>
One of the major problems is that we don't have a reliable way to test
LilyPond automatically: the output is a PDF file, and changes i
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 res
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
lilypond-devel@g
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 b
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
>
> - Optio
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:
- S
of it yet, but it
certainly looks powerful enough.
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
te encodings
(the encoding is determined by the font). I'm pretty 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, ma
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, b
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/15/06, Carl D. Sorensen <[EMAIL PROTECTED]> wrote:
> As far as Lilypond is concerned, I don't think most of them _are_ vectors.
> The points I've used in developing stencils _have_ been points (e.g. bounding
> box corners) I guess in your work with ps, there may be more vector stuff.
> I
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
http://l
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, we
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
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 i
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 strok
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
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 maili
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
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.
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 chor
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
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 ex
ver to
Scheme, it might become reasonable.
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/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
bably be good to make 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-&
On 4/4/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> 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 contex
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
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
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 thi
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.
D
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 th
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
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 a
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
t
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, 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
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 t
On 4/6/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> They participate, in that their dimension fields are used for various
> computations. Simply said, a stencil is a combination of output format
> and a bbox.
Once a stencil is constructed, is it ever adjusted? That is, once the
stencil is
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
th
ons that produce output. When the back end can't look inside
the box, it can't figure out the best way to deal with the contents.
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
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
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
roke_and_fill }
{ stroke }
ifelse
} bind 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
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 e
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 prett
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 l
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/ma
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
ss, that's certainly possible in Scheme, 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
of the arc.
arct is a language level 2 feature, but it shouldn't be too hard to
emulate it in level 1 if need be (using arc).
I don't know SVG, but it should be possible to use the same technique there.
David Feuer
___
lilypond-devel mailing
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, s
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
ay music, engravers will have to make a judgement. I am
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
___
lilypo
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 thro
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 ma
a separate 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
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
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
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?
D
e what I think 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
2006-04-03 David Feuer <[EMAIL PROTECTED]>
* lilyponddefs.ps (set-ps-scale-to-lily-scale): Fixed code duplication.
* Cleaned up interfaces between PostScript and Scheme, and moved computations
from PostScript to Scheme:
* music-drawing-routines.ps
(*SF, stroke_and_fill): new proc
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
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
es, and
drew all 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
nt.
I don't actually know _too_ 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-de
> +% 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 coo
nused draw_box (note: 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 lat
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
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 s
hanged to selectfont
Hacked-up string-appends 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/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 referen
it to:
place glyph -> 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, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> hopefully, we can use inverse durations of rests as penalties to provide
> a somewhat sensible automatic line/page breaking.
I was thinking it'd be really good to try not to break sequences of
short notes. By the time the musician's eyes
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
&g
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 a
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 chec
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. Th
's
not a good sign that text shows up in the "advanced" section of the manual.
Thanks for your consideration,
David Feuer
_
FREE pop-up blocking with the new MSN Toolbar get
's
not a good sign that text shows up in the "advanced" section of the manual.
Thanks for your consideration,
David Feuer
_
On the road to retirement? Check out MSN Life Events for advice on how
100 matches
Mail list logo
