| Re: [frogs] Re: tablature: ties and harmonics (issue1669041) |
[ Thread Index |
Date Index
| More lilynet.net/frogs Archives
]
Carl Sorensen schrieb:
On 6/30/10 1:48 AM, "Marc Hohl" <marc@xxxxxxxxxx> wrote:
Carl Sorensen schrieb:
[...]
http://codereview.appspot.com/1669041/diff/26001/27004#newcode130
scm/define-grob-properties.scm:130: (bracket-width ,number? "Width of
the harmonic angle bracket.")
Why do we need bracket-width? Why can't we just use the pre-existing
width property?
Hm, Neil proposed to use a more descriptive name for this property, IIUC.
Done.
Well, if we want to have this be part of the parenthesis-interface, then we
may want to go ahead with bracket-width.
Ok, done.
[...]
If instead of making the whiteout and the stencil different stencils, we
combined them, then parenthesize-stencil would work great. But this might
not be possible if we need to have the stencil and the whiteout on separate
layers. As an alternative, parenthesize-stencil could be modified to take
white-padding as an argument. There's nothing that says we can't modify
scm/stencil.scm so that it works better for tablature. It's much better,
IMO, to have one general-purpose piece of code than to have two separate
special-purpose code chunks.
So I tried to extend the parenthesize-stencil function in scm/stencil.scm.
It compiles without error, but the regression file is cluttered up.
Can you tell me what you mean by "the regression file is cluttered up"? Can
you tell me which examples fail the regression test for graphical output?
(The changes that indicate different amounts of memory don't bother me a
bit).
Oh, sorry, I meant the newly introduced
input/regression/tablature-tie-harmonic.ly.
With the patch set before, it worked as expected, now the angle brackets
surround
invisible fret numbers again, and after line breaks, the harmonic
brackets overlap
the parentheses construct (while erasing the fret number :-( )
I feel that this is not the right approach, either. I still don't understand
why I have to shift the TabNoteHead #'layer at all. As far as I see it,
HarmonicParenthesesItem #'stencils is a list of stencils, containing the
left and the right angle bracket, which are placed either side of the
TabNoteHead #'stencil. So the order in which the stancils are placed
should not change anything at all, but if the TabNoteHead #'stencil is set
*before* the HarmonicParenthesesItem #'stencils, it seems that some
whitespace occurs between the angle brackets, overriding the
already placed TabNoteHead.
Have you looked at the list of stencils created by
parenthesis-item::calc-parentehesis-stencils grob
and
map stencil-whiteout (parenthesis-item::calc-parentehesis-stencils grob) to
see how they differ?
Sometimes lists get reversed during LilyPond processing. Perhaps this is
happening to this list. You might see what happens if you reverse the list
of stencils....
I think I understand now - Neil has given me the clue to this.
[...]
Furthermore, I have a bad feeling to misuse your time reviewing my patch
for error seeking issues, but I am stuck here.
I don't view it as a misuse of time. But right now I'm very busy, so I may
not get to it very quickly....
Thanks for your kind words - you do a great job in motivating frustrated
people like me ;-)
I like the general idea of
not defining the same functionality over and over again, but on the
other hand,
the parenthesize-stencil function in scm/stencil.scm does not seem to
be used anywhere else ...
Parenthesize-stencil will be used for the new chord namer, so we need to
keep it in stencil.scm and keep the current functionality.
Ok.
Thank you
Marc
---
----
Join the Frogs!