Joe Neeman schreef:
Looks good. small question: why is pure-relevant coming in from Scheme
C++ seems more applicable? It's not a user serviceable part, is it?
Just because the Y-XX-conversions and pure-Y-XX lists are in scheme, and
I thought it was nicer not to make them public, but to provide
On Thu, 2006-06-08 at 17:18 +0200, Han-Wen Nienhuys wrote:
> Joe Neeman schreef:
> > On Thu, 2006-06-08 at 09:05 +1000, Joe Neeman wrote:
> >> Anyway, here's another try. Same ChangeLog as before
> >
> > After your last email, I've removed the changes to
> > Item::handle_prebroken_dependencies and
Joe Neeman schreef:
On Thu, 2006-06-08 at 09:05 +1000, Joe Neeman wrote:
Anyway, here's another try. Same ChangeLog as before
After your last email, I've removed the changes to
Item::handle_prebroken_dependencies and changed axis-group-interface.cc.
I'm only attaching the part of axis-group-in
On Thu, 2006-06-08 at 09:05 +1000, Joe Neeman wrote:
> Anyway, here's another try. Same ChangeLog as before
After your last email, I've removed the changes to
Item::handle_prebroken_dependencies and changed axis-group-interface.cc.
I'm only attaching the part of axis-group-interface.cc with the mo
Anyway, here's another try. Same ChangeLog as before
Index: ChangeLog
===
RCS file: /sources/lilypond/lilypond/ChangeLog,v
retrieving revision 1.5101
diff -u -r1.5101 ChangeLog
--- ChangeLog 7 Jun 2006 22:01:13 - 1.5101
+++ ChangeL
Joe Neeman schreef:
make web still works and there are no detected formatting changes.
Very very cool. Does this complete the optimal pagebreaking, or does the
dynamic programming part need more work now?
I revisited the algorithm a few weeks ago, so it should be fairly clean.
There is some mo
Joe Neeman schreef:
+ /* if we end up suiciding, our Y-axis-parent won't get the correct
+Y-extent unless we add our child to it */
+ Grob *p = unsmob_grob (get_object ("axis-group-parent-Y"));
+ if (p)
+ Axis_group_interface::add_element (p, dolly);
This will result
On Wed, 2006-06-07 at 10:25 +0200, Han-Wen Nienhuys wrote:
> Joe Neeman schreef:
> > Did my previous mail make it to the list? I never saw it... but anyway,
> > here's an update
>
> sorry, it was on my todo list, but your patch got caught up in other stuff.
That's fine, it's just that for some re
Joe Neeman schreef:
Did my previous mail make it to the list? I never saw it... but anyway,
here's an update
sorry, it was on my todo list, but your patch got caught up in other stuff.
make web still works and there are no detected formatting changes.
Very very cool. Does this complete the
Did my previous mail make it to the list? I never saw it... but anyway,
here's an update
On Mon, 2006-05-22 at 20:58 +1000, Joe Neeman wrote:
> On Mon, 2006-05-22 at 10:57 +0200, Han-Wen Nienhuys wrote:
> >
> > Does this patch already work for determining system heights, or is just
> > the begin
On Mon, 2006-05-22 at 20:58 +1000, Joe Neeman wrote:
> On Mon, 2006-05-22 at 10:57 +0200, Han-Wen Nienhuys wrote:
> > Joe Neeman schreef:
> > >> In that case, you could get the approximate height of one broken system
> > >> in logarithmic time.
> > >>
> > > Here's a first attempt at doing this. It
On Mon, 2006-05-22 at 10:57 +0200, Han-Wen Nienhuys wrote:
> Joe Neeman schreef:
> >> In that case, you could get the approximate height of one broken system
> >> in logarithmic time.
> >>
> > Here's a first attempt at doing this. It isn't complete or well-tested
> > yet. I add 4 grob properties
>
Joe Neeman schreef:
In that case, you could get the approximate height of one broken system
in logarithmic time.
Here's a first attempt at doing this. It isn't complete or well-tested
yet. I add 4 grob properties
>
Y-extent-safe
Y-offset-safe
default-Y-extent-is-safe
default-Y-offset-is-safe
On Mon, 2006-05-15 at 12:20 +0200, Han-Wen Nienhuys wrote:
> Perhaps you could even compute for each VerticalAxisGroup the range of
> column ranks where it would disappear, and use that information add a
> method to compute the approximate height of an alignment spanner, where
> you explicitly c
On Mon, 2006-05-15 at 12:20 +0200, Han-Wen Nienhuys wrote:
> Joe Neeman schreef:
> > There is actually another possibility that I've only just thought of so
> > it's
> > pretty half-baked:
> > Add an approximate-Y-extent to each grob that
> > 1) leaves the grob constant (in particular no caching)
Joe Neeman schreef:
I think this could be even more expensive because my page breaker looks at a
_lot_ of different line breaking configurations. On the score I have been
using for coverage tests (Haydn op 76, no 3, 1st violin part), the page
breaker tests more than 4000 different line breaking
On Sun, 14 May 2006 20:40, Han-Wen Nienhuys wrote:
> Joe Neeman schreef:
> > We discussed this a bit a long time ago but I'm getting close to actually
> > implementing something so I thought I'd bring it up again.
> >
> > Getting the Y-extent of a system is potentially destructive, causing all
> >
Han-Wen Nienhuys schreef:
3) for each possible system, using the original grobs,
- work out the Y-extent
- restore () every grob in that system
The advantage is that we avoid fiddling around with the object_alist_
because this clone is never used -- it exists only to save the state
of
Joe Neeman schreef:
We discussed this a bit a long time ago but I'm getting close to actually
implementing something so I thought I'd bring it up again.
Getting the Y-extent of a system is potentially destructive, causing all sorts
of non-undoable caching and possibly suiciding of grobs. So I
We discussed this a bit a long time ago but I'm getting close to actually
implementing something so I thought I'd bring it up again.
Getting the Y-extent of a system is potentially destructive, causing all sorts
of non-undoable caching and possibly suiciding of grobs. So I need to do make
a cop
20 matches
Mail list logo
