Re: [frogs] Re: tablature: ties and harmonics (issue1669041)

[Marc Hohl]

Carl Sorensen schrieb:
> On 6/30/10 1:48 AM, "Marc Hohl" <address@hidden> 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