lilypond-devel
[Top][All Lists]
Advanced

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

What's up with grob property "skyline-quantizing" ?


From: David Kastrup
Subject: What's up with grob property "skyline-quantizing" ?
Date: Thu, 02 Aug 2018 23:02:33 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

This property is being used in lily/slur.cc in

MAKE_SCHEME_CALLBACK (Slur, vertical_skylines, 1);
SCM
Slur::vertical_skylines (SCM smob)
{
  Grob *me = unsmob<Grob> (smob);
  vector<Box> boxes;

  if (!me)
    return Skyline_pair (boxes, X_AXIS).smobbed_copy ();

  Bezier curve = Slur::get_curve (me);
  vsize box_count = robust_scm2vsize (me->get_property ("skyline-quantizing"), 
10);
  for (vsize i = 0; i < box_count; i++)
    {
      Box b;
      b.add_point (curve.curve_point (i * 1.0 / box_count));
      b.add_point (curve.curve_point ((i + 1) * 1.0 / box_count));
      boxes.push_back (b);
    }

  return Skyline_pair (boxes, X_AXIS).smobbed_copy ();
}


It was introduced in

commit 19520fd5bbd221ca1d35011d7710e233c92a44b0
Author: Mike Solomon <address@hidden>
Date:   Wed Dec 28 09:15:41 2011 +0100

    Adds vertical skylines to slurs.
    
    This assures that objects with an outside staff priority higher than
    that of slurs are placed directly above the slur at their horizontal
    position instead of above the slur's extrema in a given direction.
    
    This is done by giving slurs vertical skylines that are the integral of
    their curve.  Because the axis-group-interface automatically uses
    vertical-skylines, no extra check for this property has to be added.

(I am unable to find the issue in the tracker via either commit id or
commit title but that might be due to my inability to operate the search
box properly).

However, all of its definitions were removed again in

commit 28f3294954eff1f263d3b2e3de1c520f4d2fbdfc
Author: Mike Solomon <address@hidden>
Date:   Mon Aug 27 23:47:04 2012 +0200

    Improvements in vertical skyline approximations (issue 2148).
    
    The file stencil-integral.cc provides a suite of functions that
    traverse a stencil and do linear approximations of its components.
    These are then turned into boxes that are passed to the Skyline
    constructor. This approximation is used for several vertical skylines
    including those of VerticalAxisGroup and System. As a result of these
    more accurate approximations, vertical spacing is more snug between
    grobs.
    
    Additionally, in axis-group-interface.cc, skylines of grobs are no
    longer compared to a monolithic axis-group skyline but rather all
    of the component skylines of the axis-group, allowing grobs to
    be fit under other ones if there is space instead of always shifted over.
    
    Two new python scripts allow to visualize the position of skylines.
    
    All other changes provide functions that allow for better debugging
    of Skylines, better approximations of grobs via skylines, and changes
    to the measurement of distance between grobs via the new Skyline API.
    
    This results in a significant time increase in score compilation for
    objects with complex skylines such as all text grobs.  For orchestral
    scores, the increase is not as steep.


It is still being used, however, even though it has become impossible to
set it.  More exactly, its hard-coded fallback value is being used.

Should we stick with that and just drop the name of the property
altogether?  It does not seem like it has been missed all that much...

-- 
David Kastrup



reply via email to

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