Re: [PATCH] no-outline-stencil backend property

[David Kastrup]

Knut Petersen <address@hidden> writes:

> Am 24.01.2017 um 14:49 schrieb David Kastrup:
>>
>>>> What a steaming heap of something. So your code would likely have
>>>> worked in LilyPond 2.16. I think it would make sense to create a new
>>>> type of stencil expression explicitly intended to bypass
>>>> outlining. Probably by just containing _two_ stencils: one for
>>>> typesetting, one for outlining. That would make for a much more
>>>> transparent manner of programming things like that.
>>> There's no need for two stencils.
>> That's what you claim.  And then you use no-outline on your stencil,
> yes, here only expr_ is extended, it's still one stencil
>> and
>> use \with-dimension in order to stack this with another stencil that has
>> just a box outline (one that survives into both dimensions as well as
>> outline).  I still count two.
> Why should I use with-dimension? The original stencil and its dimensions
> are unchanged and will be used in the stencil interpreter. no-outline() hides
> the dimensions from the code in stencil-integral.cc, but they are still 
> present
> and the stencil interpreter uses them.

You wanted to use the equivalent of \with-dimensions #'(0 . 0) #'(0 . 0)
and the C++ code for no-outline delivers the equivalent of
\with-dimensions #'(+inf.0 . -inf.0) #'(+inf.0 . -inf.0) .

So you cannot use it in the described manner without stacking an empty
box on.  Which is pretty much the only stencil without ink but with an
outline.  So this contortion works only for putting a rectangular
outline onto the ink of some stencil, and even then, you need to juggle
with several expressions.

>>> I propose to include the attached code.
>> Which completely _drops_ any outline.  So if you want a different
>> outline, you need to combine this with some stencil that has an outline
>> but no ink.  How do you remove the ink from arbitrary stencils?  You
>> can't.  So you are tied down to use this trick in connection with
>> stencils that insist on having an outline but no ink.
>
> David, this is NO-outline code. It' not a
> fake-some-arbitrary-outline-stencil.

Well, that is my complaint, isn't it?

> Define a stencil as usual, color it, scale it, whatever else. Just
> mark a stencil x with x.no_outline();
>
> The result is:
>         -> the outline is completely ignored in stencil_traverser(),
> so no collisions are detected.

When skylines are involved.  What dimensions are used when skylines are
disabled?

>         -> the stencil is drawn in interpret_stencil_expression() as
> it would be drawn without the no_outline layer.

You'll find that the positioning of stencils with empty intervals as
their dimensions can be somewhat quirky.

> That's the intended use. It's probably much faster than the current
> solution with a transparent
> stencil, dimensions forced to zero and delayed evaluation. It is
> short, therefore easy to understand,
> and it is elegant.
>
>> Really, that makes little sense.
> Think again.

I did.  I don't see why we need a specific expression for providing a
null-stencil (rather than, say, a point-stencil) as the only permissable
and hardwired traversal expression when we can just make the
specification of the expression to be used for outlining explicit.

And I don't see what would be so terrible if you had to do the
equivalent of

no-outline-markup = \markup \with-outline "" \etc

(or the equivalent for a stencil) in order to get your \no-outline
function.

We have a function that makes some whiteout footprint by drawing a
string repeatedly.  What's wrong with being able to use that whiteout
footprint for positioning while using the actual (non-whiteout) stencil
for the actual placement?

-- 
David Kastrup