lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Getting the height of a system.


From: Joe Neeman
Subject: Re: Getting the height of a system.
Date: Wed, 07 Jun 2006 21:53:58 +1000

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 reason I didn't get a copy of my
mail back so I wasn't sure if it sent properly.

> 
> > 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 more functionality I would like to do though:

- tandem page/line breaking with page turns (done)
- tandem page/line breaking ignoring page turns (todo)
- tandem page/line breaking with fixed number of pages (todo)
- line, then page breaking ignoring page turns (todo)

I've tried to refactor the existing code so the other methods won't take
much code. Once I've done the last one, I can rip out the existing page
breaker. I'll post my code here before I do all that, though. It's quite
capable of peacefully coexisting with the current page breaker.

> 
> > +
> > +  if (scm_is_number (dy_scm))
> > +    {
> > +      Real dy = scm_to_double (dy_scm) * robust_scm2dir (me->get_property 
> > ("stacking-dir"), DOWN);
> > +      Real pos = 0;
> > +      for (vsize i = 0; i < all_grobs.size (); i++)
> > +   {
> > +     if (all_grobs[i] == ch)
> > +       return pos;
> > +     if (!Hara_kiri_group_spanner::has_interface (all_grobs[i])
> > +         || !Hara_kiri_group_spanner::request_suicide (all_grobs[i], 
> > start, end))
> > +       pos += dy;
> > +   }
> >      }
> > +  else
> 
> don't understand: aren't you missing a return? pos isn't used any further.
but it has a different value when we go through the loop again. I could
initialise pos to (-dy) and put the return at the end of the loop if it
would be clearer.

> 
> 
> > +  vsize start_brk = VPOS;
> > +  vsize end_brk = VPOS;
> 
> brk -> index
sure

> 
> > +
> > +  /* The only time a parent is allowed to affect its children's Y-offset 
> > is if
> > +     it has align-interface */
> > +  Grob *p = get_parent (Y_AXIS);
> 
> I think you know, but this happens in some other cases as well. Mostly 
> all grobs that support the positioning-done property.
I didn't know when that when I wrote the comment, though ;) I'll rewrite
the comment.

> 
> 
> > +  if (pure && a != Y_AXIS)
> > +    programming_error (_f ("tried to get pure X-offset"));
> 
> don't mark programming errors as translatable. They're supposed to be 
> read by programmers, not users.
sure

> > +      for (vsize i = 0; i < worth.size (); i++)
> > +   {
> > +     Item *it = dynamic_cast<Item*> (worth[i]);
> > +     if (it)
> > +       {
> > +         vsize col = Paper_column::get_rank (it->get_column ());
> > +         important_cols.resize (max (important_cols.size (), col+1));
> > +         important_cols[col] = 1;
> > +       }
> > +   }
> 
> This looks dodgy. The resize call may introduce uninitialized data. 
> Isn't it easier to sort the items-worth-living by column-rank and then 
> insert False for any spans that are skipped by items-worth-living?
Probably. I'll rethink this one.

> 
> Considering naming, I'd use important-column-ranks.
> 
> Please use "true" iso. "1".
OK

> 
> > +
> > +      /* 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 in duplicate elements in the axis-group-parent-Y after 
> line breaking.  Isn't it possible to handle this in any of the relevant 
> pure_XX functions?

I don't think so. For example, a BarNumber gets created and added to
System->object_alist_->elements. Since a mid-line BarNumber is
invisible, the original grob sucides in
Item::handle_prebroken_dependencies. By the time System->pure_extent
gets called, there are no live BarNumbers in the elements list, so none
of the pure_XX functions even get to see a BarNumber.

I suppose I could move the change into
Item::handle_prebroken_dependencies -- if we want to suicide an original
grob but the broken pieces are still potentially visible, add them to
the Y-axis-parent. Would that be better?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]