Re: a proper whiteout function

[Paul Morris]

Ok, thanks for the feedback.  I went with "thickness" and 12 instead of 24 for 
angle-increments.  I've submitted a patch for review.

http://code.google.com/p/lilypond/issues/detail?id=4418&colspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary

-Paul___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Janek Warchoł]

Yeah, thickness would be good as well.

Thanks,
Janek

W dniu środa, 20 maja 2015 Carl Sorensen  napisał(a):

>
>
> On 5/19/15 10:37 PM, "Janek Warchoł"  > wrote:
>
> >
> >- I think "offset" should be renamed to "padding".  Throughout LilyPond,
> >offsets are used to measure distances and position, while padding is used
> >for ensuring there's enough whitespace around an object.
>
> I don't think it should be named "padding".  padding is spacing parameter;
> but the "offset" parameter doesn't affect spacing.
>
> I think "thickness" is better than "padding".  It defines the thickness of
> the whiteout border (and, by the this HTML class. Value is Great. We are
> loca, thicknesses are in staff spaces
> throughout lilypond).
>
> Thanks,
>
> Carl
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Carl Sorensen]

On 5/19/15 10:37 PM, "Janek Warchoł"  wrote:

>
>- I think "offset" should be renamed to "padding".  Throughout LilyPond,
>offsets are used to measure distances and position, while padding is used
>for ensuring there's enough whitespace around an object.

I don't think it should be named "padding".  padding is spacing parameter;
but the "offset" parameter doesn't affect spacing.

I think "thickness" is better than "padding".  It defines the thickness of
the whiteout border (and, by the way, thicknesses are in staff spaces
throughout lilypond).

Thanks,

Carl


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Janek Warchoł]

Hi Paul,

thanks a lot for doing this!  The result is quite impressive, i didn't
expect this approach to produce so nice whiteouts :)
I have just a couple cosmetic suggestions:
- I think "offset" should be renamed to "padding".  Throughout LilyPond,
offsets are used to measure distances and position, while padding is used
for ensuring there's enough whitespace around an object.
- I think the default value for angle-increments should be 8, or at most
12.  Yes, with smaller value the whiteouts will be less regular, but this
will be visible only with very high magnification, while the improvement in
performance/pdf size may be noticeable.

best,
Janek


2015-05-19 20:41 GMT-07:00 Paul Morris :

> Hi Carl, Wilbert, David N, Kieren, Abraham,
>
> Thanks for all the feedback and suggestions.  I’m attaching a new revision.
>
> - Original spacing is maintained.  Thanks David and Carl for the tips on
> how to do this.
>
> - Optional parameters, with fallback defaults, for offset, color,
> angle-increments, radial-increments.  I went with Carl’s suggestions, but
> made them optional.  The stencil argument now comes first.
>
> - Prevents zero or negative angle- and radial- increments that would cause
> an infinite loop.
>
> - First pass at a doc string based on Carl’s descriptions.
>
>
> Let me know what you think and then I’ll go ahead and submit a patch for
> review.  BTW, what’s a good default for offset?
>
> Cheers,
> -Paul
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Paul Morris]

Hi Carl, Wilbert, David N, Kieren, Abraham,

Thanks for all the feedback and suggestions.  I’m attaching a new revision.

- Original spacing is maintained.  Thanks David and Carl for the tips on how to 
do this.

- Optional parameters, with fallback defaults, for offset, color, 
angle-increments, radial-increments.  I went with Carl’s suggestions, but made 
them optional.  The stencil argument now comes first.

- Prevents zero or negative angle- and radial- increments that would cause an 
infinite loop.

- First pass at a doc string based on Carl’s descriptions.


Let me know what you think and then I’ll go ahead and submit a patch for 
review.  BTW, what’s a good default for offset?

Cheers,
-Paul



stencil-whiteout-outline2.ly
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[tisimst]

On Mon, May 18, 2015 at 9:03 AM, Kieren MacMillan [via Lilypond] <
ml-node+s1069038n176742...@n5.nabble.com> wrote:

> Hi Paul (et al.),
>
> > a more elegant approach would be to trace the outline of the stencil,
> but that’s beyond my skills
>
> Maybe someone out there can take up the challenge?  =)
>

This kind of thing is definitely possible, but I don't believe we have
access to curve data that comprise the outlines themselves from within the
current set of Scheme functions. Paul's solution may be the best we can do
without some lower C++ coding. Then again, perhaps I am just mistaken about
all this due to my ignorance of some core features/functions.

- Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/a-proper-whiteout-function-tp175593p176762.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Carl Sorensen]

On 5/18/15 1:59 AM, "Wilbert Berendsen"  wrote:

>Hi Paul,
>
>this looks very nice! One thing I notice is that the size of the
>objects changes, influencing the spacing. But that's probably easy to
>fix.

It should be very easy to fix.  Just get the extents of the original
stencil, and apply them to the final stencil.

Thanks,

Carl


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Carl Sorensen]

On 5/18/15 12:49 PM, "Carl Sorensen"  wrote:
>
>At any rate, there should probably be a user-specifiable way to change all
>three values that govern the performance, whether by context properties or
>by arguments.

As I think about it some more, perhaps the most logically-consistent set
of three properties is:

offset -- How big is the white outline in staff-spaces
radial-increments -- how many copies of the white stencil do we make on
our way out to offset
angle-increments -- how many copies of the white stencil do we make
between 0 and 2*pi

And should we have a color argument, as well?  Could we want to make the
outline some color other than white?

Thanks,

Carl



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Carl Sorensen]

On 5/18/15 12:04 PM, "Paul Morris"  wrote:

>> On May 17, 2015, at 7:48 PM, Carl Sorensen  wrote:
>> 
>> This is a nice implementation -- I didn't think it could be done!
>
>Thanks Carl!
>
>> I think
>> it should be made part of LilyPond, if the performance hit is not too
>>big.
>> It seems to create a lot of stencils, but maybe that is no problem.
>
>I wondered whether or not it should be part of LilyPond (with this
>implementation) but I¹ll be glad to submit it.   If there is a
>performance hit, it will at least be limited because it will likely not
>be used on that many stencils in any given score.

One more thing that ought to be considered.  Should offset be a context
property rather than an argument?  I'm not sure one way or the other, but
we probably should think about it.

On the one hand, it would be nice to do something like

\set Score.whiteoutOffset = #.3

On the other hand, it seems somewhat strange to have c whiteoutOffset
property associated with anything other than a Grob.  But you wouldn't
want to have to set a whiteoutOffset property for each Grob, so setting
the whiteout as part of the stencil property for the grob (as an argument)
seems the best way to go if you want to have Grob-by-Grob specific offsets.

Perhaps if you're going to do Grob-by-Grob specific offsets, there should
be all three parameters as arguments: offset, radius-increment, and
angle-copies  (names are not final yet, just an initial guess).

At any rate, there should probably be a user-specifiable way to change all
three values that govern the performance, whether by context properties or
by arguments.

Thanks,

Carl


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[David Nalesnik]

On Mon, May 18, 2015 at 1:14 PM, David Nalesnik 
wrote:

> Hi Paul,
>
> On Mon, May 18, 2015 at 1:10 PM, Paul Morris  wrote:
>
>> > On May 18, 2015, at 3:59 AM, Wilbert Berendsen  wrote:
>> >
>> > this looks very nice! One thing I notice is that the size of the
>> > objects changes, influencing the spacing. But that's probably easy to
>> > fix.
>>
>> Thanks!  Yes I noticed that horizontal spacing is increased since the
>> stencil is wider (but maybe not vertical spacing? at least not in my
>> limited observation...).  So yes there should be a way to adjust for this
>> so the spacing stays the same -- maybe as an option since one might want
>> either behavior depending on the case.
>>
>> Anyone have any thoughts on the best way to achieve such a spacing
>> adjustment?
>>  
>>
>
> Could you use ly:make-stencil with zeroed extent for the offset stencils?
>
>
Used in conjunction with ly:stencil-expr.

DN
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[David Nalesnik]

Hi Paul,

On Mon, May 18, 2015 at 1:10 PM, Paul Morris  wrote:

> > On May 18, 2015, at 3:59 AM, Wilbert Berendsen  wrote:
> >
> > this looks very nice! One thing I notice is that the size of the
> > objects changes, influencing the spacing. But that's probably easy to
> > fix.
>
> Thanks!  Yes I noticed that horizontal spacing is increased since the
> stencil is wider (but maybe not vertical spacing? at least not in my
> limited observation...).  So yes there should be a way to adjust for this
> so the spacing stays the same -- maybe as an option since one might want
> either behavior depending on the case.
>
> Anyone have any thoughts on the best way to achieve such a spacing
> adjustment?
>  
>

Could you use ly:make-stencil with zeroed extent for the offset stencils?

David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Paul Morris]

> On May 18, 2015, at 3:59 AM, Wilbert Berendsen  wrote:
> 
> this looks very nice! One thing I notice is that the size of the
> objects changes, influencing the spacing. But that's probably easy to
> fix.

Thanks!  Yes I noticed that horizontal spacing is increased since the stencil 
is wider (but maybe not vertical spacing? at least not in my limited 
observation...).  So yes there should be a way to adjust for this so the 
spacing stays the same -- maybe as an option since one might want either 
behavior depending on the case.

Anyone have any thoughts on the best way to achieve such a spacing adjustment?

-Paul
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Paul Morris]

> On May 17, 2015, at 7:48 PM, Carl Sorensen  wrote:
> 
> This is a nice implementation -- I didn't think it could be done!  

Thanks Carl!

> I think
> it should be made part of LilyPond, if the performance hit is not too big.
> It seems to create a lot of stencils, but maybe that is no problem.

I wondered whether or not it should be part of LilyPond (with this 
implementation) but I’ll be glad to submit it.   If there is a performance hit, 
it will at least be limited because it will likely not be used on that many 
stencils in any given score.

> I'd like to see a couple of changes.
> 
> 2pi-over-density should be changed to something like angle-increment.
> 2pi-over-density is the function used to calculate it; the meaning is
> really angle-increment.
> 
> And I think that in-fill-density should be changed radius-increment.

Those make sense to me.

> Then you could say that the function works by creating series of white
> stencils radially offset from the black stencil with angles from 0 to 2
> pi, at an increment of angle-increment, and with radii from
> radius-increment to offset.
> 
> At that point, we can understand how the function creates an outline.

That’s a nice description, thanks!

> Oh, and there should be some documentation that indicates that offset is
> in staff-spaces.

Yep.

> Thanks again for creating this!

Glad you like it!

-Paul



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Kieren MacMillan]

Hi Paul (et al.),

> I took Kieren up on his offer to sponsor a better whiteout stencil function.  
> It’s attached so that anyone can make use of it.

Thanks for doing this! Looking forward to seeing it in action “in the wild”.
If anyone is willing to co-sponsor this function with me, please contact me 
off-list and we can discuss the details.

> a more elegant approach would be to trace the outline of the stencil, but 
> that’s beyond my skills

Maybe someone out there can take up the challenge?  =)

> the results of this function are much better than the current 'white square' 
> option.

Agreed! I’ve already used it several times in the scores I’m currently working 
on, and the results are great.

Unexpectedly (and counterintuitively), there *are* certain circumstances — a 
specific list of which I’m still in the process of discovering and compiling — 
in which the regular [‘white square’] option is still superior to my eye. But 
it’s a huge benefit to have this new function, which is preferable (to my eye) 
in the vast majority of cases.

Thanks again,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Wilbert Berendsen]

Hi Paul,

this looks very nice! One thing I notice is that the size of the
objects changes, influencing the spacing. But that's probably easy to
fix.

-- 
Wilbert Berendsen
(http://www.wilbertberendsen.nl)


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Carl Sorensen]

On 5/17/15 5:18 PM, "Paul Morris"  wrote:

>> On Apr 28, 2015, at 11:57 AM, Kieren MacMillan
>> wrote:
>> 
>> What would be involved in making a real stencil whiteout function which
>>could be applicable to all grobs?
>
>Hi all,  I took Kieren up on his offer to sponsor a better whiteout
>stencil function.  It¹s attached so that anyone can make use of it.

Paul,

This is a nice implementation -- I didn't think it could be done!  I think
it should be made part of LilyPond, if the performance hit is not too big.
 It seems to create a lot of stencils, but maybe that is no problem.

I'd like to see a couple of changes.

2pi-over-density should be changed to something like angle-increment.
2pi-over-density is the function used to calculate it; the meaning is
really angle-increment.

And I think that in-fill-density should be changed radius-increment.

Then you could say that the function works by creating series of white
stencils radially offset from the black stencil with angles from 0 to 2
pi, at an increment of angle-increment, and with radii from
radius-increment to offset.

At that point, we can understand how the function creates an outline.

Oh, and there should be some documentation that indicates that offset is
in staff-spaces.

Thanks again for creating this!

Carl




___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Paul Morris]

> On Apr 28, 2015, at 11:57 AM, Kieren MacMillan 
>  wrote:
> 
> What would be involved in making a real stencil whiteout function which could 
> be applicable to all grobs?

Hi all,  I took Kieren up on his offer to sponsor a better whiteout stencil 
function.  It’s attached so that anyone can make use of it.

> 1. follow exactly the grob/glyph outline (i.e., not just a rectangle/box, as 
> currently implemented);

It produces a very close approximation of the stencil outline — not strictly 
exact but close enough that you probably won’t notice.  

> 2. include a parameter to set the thickness of the outline; and

You can set the thickness of the outline.

> 3. include a parameter to determine whether the whiteout was filled 
> throughout, or allowed “holes” inside (as per the grob/glyph outline).

It doesn’t offer this option.

I believe it should work with any glyph/stencil.  In the attached file there's 
one function that just deals with stencils and another that deals with grobs 
(overriding their stencil property).  

The function takes a “brute-force” approach and creates the white background by 
super-imposing/combining a bunch of white copies of the stencil behind it.  
Each copy is systematically offset to make a smooth outline and to fill in any 
gaps due to “holes” in the stencil.  Of course a more elegant approach would be 
to trace the outline of the stencil, but that’s beyond my skills, and the 
results of this function are much better than the current 'white square' option.

If you’re interested in the implementation you can see how it works by playing 
with lower values for “density” and higher for “in-fill-density” particularly 
with a larger outline offset.  These are two properties that can be used to 
“tune" the function, to find a good trade-off between efficiency and quality.  
I think I found pretty good default values for them.  

Cheers,
-Paul







stencil-whiteout-outline.ly
Description: Binary data



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Alexander Kobel]

On 04/29/2015 03:03 PM, Kieren MacMillan wrote:

Hi Francisco,


To achieve a whiteout that is useful for music, I think a thick
default 'middle' stroke in white on a lower layer would work.
See example.


YES! This is exactly the kind of thing I’m hoping for.


+1.


Do you think this “function” (bad choice of words here, I know) could be made 
to handle arbitrary [music] grobs, or would one always have to manually work 
through all 4 (?) steps of the process for each grob?


I guess Francisco's example was handmade in Inkscape or similar 
software, but it should be possible to automize it.
AFAIK, all output from Lilypond is laid out in Postscript first, which 
offers support for these operations (at least for text) - see the 
attached example and, e.g., the following page.

  http://paulbourke.net/dataformats/postscript/
The Postscript code for this is as follows:

%!PS-Adobe-3.0
/Times-Bold findfont 30 scalefont setfont

100 400 moveto
(Hello World!)
true charpath
5 setlinewidth
0.5 setgray
stroke

100 400 moveto
(Hello World!)
0 setgray
show

showpage

The main idea is to typeset the object/path/glyph/grob, you name it, 
twice: once in white, non-filled, with thick stroke, and once in the 
actual color. IIUC, this could be achieved by some stencil which is on 
top of the PS-output-stencil.
Unfortunately, I could not make it work with glyphshow, which is what is 
used for the embedded fonts (at least by Lilypond)...



Best,
Alexander


hello.ps
Description: PostScript document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Kieren MacMillan]

Hi Francisco,

> To achieve a whiteout that is useful for music, I think a thick
> default 'middle' stroke in white on a lower layer would work.
> See example.

YES! This is exactly the kind of thing I’m hoping for.

Do you think this “function” (bad choice of words here, I know) could be made 
to handle arbitrary [music] grobs, or would one always have to manually work 
through all 4 (?) steps of the process for each grob?

Thank you,
Kieren.



Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Francisco Vila]

2015-04-29 13:30 GMT+02:00 Alexander Kobel :
> A
> minute of googling brought me to the following page, which nicely shows some
> difficulties, and illustrates why it requires significant effort:
>   http://tavmjong.free.fr/blog/?p=1257

To achieve a whiteout that is useful for music, I think a thick
default 'middle' stroke in white on a lower layer would work. See
example.



-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Alexander Kobel]

On 04/29/2015 12:04 PM, Pierre Perol-Schneider wrote:

Hi Kieren, Hi Carl,

I don't think that a standard scaling will help in this case.
Here's an illustration of what could happened :

\markup {
   \combine
   \with-color #magenta
   \scale #'(1.2 . 1.2)
   \musicglyph #"clefs.G"
   \musicglyph #"clefs.G"
}

Whatever glyph re-centering, you'll never get a proper whiteout.
One has to define a specific scaling function that can "blows" the glyph
in order to get a bold one.


Correct. You need an offset (effectively a white stroke around all 
boundary curves) of whatever is rendered, and I think this should not be 
done with Lilypond inspecting the shape, but rather something on the 
lower level. A minute of googling brought me to the following page, 
which nicely shows some difficulties, and illustrates why it requires 
significant effort:

  http://tavmjong.free.fr/blog/?p=1257
I know that boldsymbol or something similar in LaTeX uses (used?) a 
bunch of copies of the same symbol with a slight translation each time, 
but that's 1. conceptually ugly and 2. prone to break for really thin 
lines, so I would not recommend to go this route.


I guess there might be a way to encode such a thing in PostScript? But 
even if there is a simple shortcut, I don't whether it can be applied to 
arbitrary stencils...



Best,
Alexander

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Pierre Perol-Schneider]

Just thinking...
Here's a rough path drawing that could do the job:

\version "2.19.19"

\markup {
  \combine
  \with-color #magenta
  \path #0.3 #'(
 (moveto   1.17   -0.50)
 (curveto   1.24   -0.53   1.33  -0.43   1.24  -0.36)
 (curveto   0.76   -0.07   0.82   0.57   1.49   0.62)
 (curveto   2.500.60   2.54  -0.65   1.77  -0.84)
 (curveto   0.89   -1.02   0.50  -0.54   0.35  -0.20)
 (curveto   0.260.00   0.07   0.63   1.18   1.77)
 (curveto   2.042.70   2.19   3.28   1.81   4.20)
 (curveto   1.634.62   1.52   4.71   1.49   4.76)
 (curveto   1.474.79   1.43   4.79   1.40   4.76)
 (curveto   1.094.51   0.84   4.15   0.82   3.70)
 (curveto   0.803.00   0.88   2.70   1.03   2.15)
 (curveto   1.351.00   1.48   0.51   1.69  -0.90)
 (curveto   1.93   -2.80   0.68  -2.44   0.57  -2.09)
 (curveto   1.30   -2.34   1.25  -1.07   0.49  -1.39)
 (curveto   0.32   -1.48   0.23  -1.61   0.28  -1.90)
 (curveto   0.39   -2.72   2.12  -3.04   1.85  -0.95)
 (curveto   1.620.70   1.52   0.90   1.21   2.10)
 (curveto   0.753.46   1.14   3.90   1.64   4.20)
 (curveto   1.863.49   1.70   3.05   1.10   2.31)
 (curveto   0.081.24   0.00   0.80   0.00   0.45)
 (curveto   0.00   -0.51   0.73  -1.20   1.72  -1.00)
 (curveto   2.98   -0.72   2.80   1.15   1.45   1.04)
 (curveto   0.500.95   0.52  -0.25   1.17  -0.50)
 )
  \translate #'(0.015 . 0)
  \musicglyph #"clefs.G"
}

Note: X translation is 0.5 * 'line thickness'

The "only" problem is to find a way to get all glyphs coordinates
automagically ...

Cheers,
Pierre


2015-04-29 12:04 GMT+02:00 Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com>:

> Hi Kieren, Hi Carl,
>
> I don't think that a standard scaling will help in this case.
> Here's an illustration of what could happened :
>
> \markup {
>   \combine
>   \with-color #magenta
>   \scale #'(1.2 . 1.2)
>   \musicglyph #"clefs.G"
>   \musicglyph #"clefs.G"
> }
>
> Whatever glyph re-centering, you'll never get a proper whiteout.
> One has to define a specific scaling function that can "blows" the glyph
> in order to get a bold one.
>
> Cheers,
> Pierre
>
>
>
> 2015-04-29 2:26 GMT+02:00 Kieren MacMillan 
> :
>
>> Hi Carl,
>>
>> >> 1. follow exactly the grob/glyph outline (i.e., not just a
>> rectangle/box,
>> >> as currently implemented);
>> >> 2. include a parameter to set the thickness of the outline; and
>> >> 3. include a parameter to determine whether the whiteout was filled
>> >> throughout, or allowed ³holes² inside (as per the grob/glyph outline).
>> >
>> > I think that doing all 3 things is virtually impossible, given my
>> > understanding of the current state of stencil handling.
>>
>> Okay. Thanks for the information.
>>
>> > I think that a stencil whiteout for simple stencils could be created by
>> > combining two stencils:
>> > 1) the original stencil
>> > 2) a scaled version of the original stencil, colored white, and placed
>> on
>> > a lower layer
>> > The amount of scaling would determine the thickness of the outline.
>> > There would be no way of dealing properly with holes.
>>
>> That might be sufficient for the vast majority of cases I’ve seen.
>> I’ll see if I can work out a quick Scheme function to accomplish what
>> you’ve suggested here.
>>
>> Thanks,
>> Kieren.
>> 
>>
>> Kieren MacMillan, composer
>> ‣ website: www.kierenmacmillan.info
>> ‣ email: i...@kierenmacmillan.info
>>
>>
>> ___
>> lilypond-user mailing list
>> lilypond-user@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>>
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Pierre Perol-Schneider]

Hi Kieren, Hi Carl,

I don't think that a standard scaling will help in this case.
Here's an illustration of what could happened :

\markup {
  \combine
  \with-color #magenta
  \scale #'(1.2 . 1.2)
  \musicglyph #"clefs.G"
  \musicglyph #"clefs.G"
}

Whatever glyph re-centering, you'll never get a proper whiteout.
One has to define a specific scaling function that can "blows" the glyph in
order to get a bold one.

Cheers,
Pierre


2015-04-29 2:26 GMT+02:00 Kieren MacMillan :

> Hi Carl,
>
> >> 1. follow exactly the grob/glyph outline (i.e., not just a
> rectangle/box,
> >> as currently implemented);
> >> 2. include a parameter to set the thickness of the outline; and
> >> 3. include a parameter to determine whether the whiteout was filled
> >> throughout, or allowed ³holes² inside (as per the grob/glyph outline).
> >
> > I think that doing all 3 things is virtually impossible, given my
> > understanding of the current state of stencil handling.
>
> Okay. Thanks for the information.
>
> > I think that a stencil whiteout for simple stencils could be created by
> > combining two stencils:
> > 1) the original stencil
> > 2) a scaled version of the original stencil, colored white, and placed on
> > a lower layer
> > The amount of scaling would determine the thickness of the outline.
> > There would be no way of dealing properly with holes.
>
> That might be sufficient for the vast majority of cases I’ve seen.
> I’ll see if I can work out a quick Scheme function to accomplish what
> you’ve suggested here.
>
> Thanks,
> Kieren.
> 
>
> Kieren MacMillan, composer
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Simon Albrecht]

Another example: it’s currently impossible to whiteout LyricHyphen – 
which would be nice in combination with SpanBar.


Yours, Simon

Am 29.04.2015 um 02:44 schrieb Kieren MacMillan:

Hi,

Forgive my ignorance, but could you just set the color of the grob to 
white?


No: I want a black grob with a white outline (“padding”), for 
“layering” purposes.


For reference, this is what happens with the current whiteout function:


I’m hoping to avoid the “boxy” look, which I find unattractive.

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info 
‣ email: i...@kierenmacmillan.info 



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[tyronicus]

Kieren MacMillan wrote
> No: I want a black grob with a white outline (“padding”), for “layering”
> purposes.

I see. That makes sense. Sorry I can't be of more help.



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/a-proper-whiteout-function-tp175593p175643.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Kieren MacMillan]

Hi,

> Forgive my ignorance, but could you just set the color of the grob to white?

No: I want a black grob with a white outline (“padding”), for “layering” 
purposes.

For reference, this is what happens with the current whiteout function:



I’m hoping to avoid the “boxy” look, which I find unattractive.

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Kieren MacMillan]

Hi Carl,

>> 1. follow exactly the grob/glyph outline (i.e., not just a rectangle/box,
>> as currently implemented);
>> 2. include a parameter to set the thickness of the outline; and
>> 3. include a parameter to determine whether the whiteout was filled
>> throughout, or allowed ³holes² inside (as per the grob/glyph outline).
> 
> I think that doing all 3 things is virtually impossible, given my
> understanding of the current state of stencil handling.

Okay. Thanks for the information.

> I think that a stencil whiteout for simple stencils could be created by
> combining two stencils:
> 1) the original stencil
> 2) a scaled version of the original stencil, colored white, and placed on
> a lower layer
> The amount of scaling would determine the thickness of the outline.
> There would be no way of dealing properly with holes.

That might be sufficient for the vast majority of cases I’ve seen.
I’ll see if I can work out a quick Scheme function to accomplish what you’ve 
suggested here.

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[tyronicus]

Kieren MacMillan wrote
> What would be involved in making a real stencil whiteout function which
> could be applicable to all grobs?
> 
> For it to Do The Right Thing™, I imagine it should:
> 1. follow exactly the grob/glyph outline (i.e., not just a rectangle/box,
> as currently implemented);
> 2. include a parameter to set the thickness of the outline; and
> 3. include a parameter to determine whether the whiteout was filled
> throughout, or allowed “holes” inside (as per the grob/glyph outline).

Forgive my ignorance, but could you just set the color of the grob to white?



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/a-proper-whiteout-function-tp175593p175638.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: a proper whiteout function

[Carl Sorensen]

On 4/28/15 8:57 AM, "Kieren MacMillan" 
wrote:

>Hi all,
>
>What would be involved in making a real stencil whiteout function which
>could be applicable to all grobs?
>
>For it to Do The Right Thing, I imagine it should:
>1. follow exactly the grob/glyph outline (i.e., not just a rectangle/box,
>as currently implemented);
>2. include a parameter to set the thickness of the outline; and
>3. include a parameter to determine whether the whiteout was filled
>throughout, or allowed ³holes² inside (as per the grob/glyph outline).

I think that doing all 3 things is virtually impossible, given my
understanding of the current state of stencil handling.  There are
multiple ways of creating stencils, and at this point there is no check
for how the stencil is created.  A stencil is a procedure for creating
some graphical output, along with the bounding box of the output.

I think that a stencil whiteout for simple stencils could be created by
combining two stencils:

1) the original stencil
2) a scaled version of the original stencil, colored white, and placed on
a lower layer

The amount of scaling would determine the thickness of the outline.

There would be no way of dealing properly with holes.

Composite stencils (e.g. lines of text/words) would not work with this
method.

To really do it correctly would require a redefinition of every stencil
procedure to include whiteout properties.  And I'm not even sure how some
of the stencils would have whiteouts defined (e.g. font glyphs).

Thanks,

Carl


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

a proper whiteout function

[Kieren MacMillan]

Hi all,

What would be involved in making a real stencil whiteout function which could 
be applicable to all grobs?

For it to Do The Right Thing™, I imagine it should:
1. follow exactly the grob/glyph outline (i.e., not just a rectangle/box, as 
currently implemented);
2. include a parameter to set the thickness of the outline; and
3. include a parameter to determine whether the whiteout was filled throughout, 
or allowed “holes” inside (as per the grob/glyph outline).

I’ve got a little sponsorship money available for this, if necessary.

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user