[final PATCH] Re: not-so-ancient flags

[Reinhold Kainhofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Samstag, 23. August 2008 schrieb Han-Wen Nienhuys:
> On Fri, Aug 22, 2008 at 3:14 PM, Reinhold Kainhofer
> > So, to summarize what you suggest:
> > - -) Stem 'flag property: Always a scheme function returning the complete
> > stencil; The default scheme function calls some C++ function, which does
> > exactly what we have in Stem::flag right now (i.e. lookup a glyph from
> > the font, using the 'flag-style property for the name).
> > - -) Stem 'flag-style property: The name of the style, used only by the
> > default 'flag function.
> > - -) C++ function Stem::calc_flag: Contains the current code for flags
> > will be called by the default function of Stem 'flag.
>
> Yes- this follows the principle of least surprise.

Okay, attached is the updated patch, which gives users full control about the 
flag generation. It uses the Stem grob properties as outlined above. 
I implemented both a C++ and a scheme function to create the flags. There is a 
slight performance advantage for the C++ function (for a file containing only 
10,000 unbeamed eighth notes it is 5 seconds faster with a runtime of a 
little over 3 minutes, see below), so I left the C++ function in, but also 
did the Scheme implementation, so that users can take the existing styles and 
modify them. With this patch we now have the proper basis to implement the 
straight flags style originally requested.

Here's what the patch does (from the git log message):

  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 -) Added the 'flag grob property to the stem: It's a function taking the
    stem grob and returning a stencil for the whole flag (including a possible
    grace slash). It uses the 'flag-style property with the exact same values
    as previously, so any existing score should still be working.
    The default is ly:stem::calc-flag (implemented in C++), but
    I also implemented the default styles (no-flag, normal-flag and
    mensural-flag) in Scheme, where the function default-flag also uses
    the 'flag-style grob property. Both (the flag creation in C++ and in
    Scheme) show practically the same performance[*], so we might get rid of
    one of them in the future. Flag creation using scheme can thus be enabled
    by
          \override Stem #'flag = #default-flag
    flag creation in C++ can be explicitly enabled by
          \override Stem #'flag = #ly:stem::calc-flag
    
 -) Implemented the default flag styles as scheme-functions, so that one can
    re-use them in one's own flag style functions. The default flags functions
    are implemented in a modular way, so one can easily create styles that
    adjust some aspects of the default flags. An example style implemented
    in the test is to use mirrored flags (i.e. flags always pointing
    left). This can be implemented by creating the flag for the opposite
    stem direction and rotating it by 180 degrees ;-)
    
 -) Added regression tests to check that the default flag styles all keep
    working.
    
 -) In the regression tests, I also added some custom styles: weighted-flag,
    where the flags are shown as one big black box and the "number" of flags
    is indicated by the height of the box. The other example is the
    mirrored-normal-flag style mentioned above (useful for tutorials about
    music notation to show that flags should *NOT* be printed to the left!)
    
The real motivation for this feature, namely straight flags (either
old-style with a large slant or modern-style with a much smaller slant),
is not yet implemented, but should not be too hard, using the
ly:round-filled-polygon function.
    
[*] We now have two ways to generate flags: One C++ implementation
(ly:stem::calc-flag) and one pure-Scheme implementation (default-flag).
Both require the same amount of memory and there is hardly any difference
in their runtime. For example, a file consisting of 10,000 eighth notes
(nothing else) needs ~1.5GB RAM and runs for a bit over 3 minutes here,
with the C++ implementation beating the Scheme implementation by mere
5 seconds:
In C++:
    real    3m9.133s
    user    3m4.896s

In Scheme:
    real    3m14.016s
    user    3m10.024s

  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Okay to push to master?

Cheers,
Reinhold

PS: What about the straight flags glyphs that we already designed? Should we 
simply drop that and do a pure Scheme implementation with all its drawbacks 
(no proper hinting, as pointed out by Werner in Bug #652)?
Werner, should the get_subpath function still be moved from parmesan-macros.mf 
to feta-macros.mf, even though it is not really required there?

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: address@hidden, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIuHhbTqjEwhXvPN0RAgLLAKDU27hViONsoCNluvtAK6OdCzFBewCg1RCQ
k5xw7RTw9XQxaZ/ZQ1M+J/4=
=PL5Q
-----END PGP SIGNATURE-----

0001-Change-flag-creation-to-use-the-flag-prop-function.patch
Description: Text Data