Re: Gets vertical skylines from grob stencils (issue 5626052)

[mike]

On Feb 10, 2012, at 3:05 PM, David Kastrup wrote:

> "address@hidden" <address@hidden> writes:
> 
>> On Feb 10, 2012, at 1:51 PM, David Kastrup wrote:
>> 
>>> David Kastrup <address@hidden> writes:
>>> 
>>>> David Kastrup <address@hidden> writes:
>>>> 
>>>>> Han-Wen Nienhuys <address@hidden> writes:
>>>>> 
>>>>>> Just a very quick look: I notice you're creating affine transform
>>>>>> matrices in Scheme. IMO, this seems an excellent candidate to
>>>>>> implement in C++ and expose through bindings, as the C++ matrices will
>>>>>> be better packed in memory, and should probably only be manipulated by
>>>>>> operations involving multiple floating point ops (add, multiply, etc.)
>>>>> 
>>>>> Stupid question: wasn't Cairo a dependency of LilyPond?  It should
>>>>> offer affine transforms as a builtin entity anyway, and it is
>>>>> conceivable that using those will play together smoothly with other
>>>>> rendering operations.
>>>> 
>>>> Cancel that: I was confusing this with Pango.
>>> 
>>> Well, uncancel the idea in itself: seems like it applies to Pango as
>>> well:
>> 
>> I've implemented all of the affine transformations in
>> stencil-integral.cc.  They're pretty simple, but they work and are
>> fast.
> 
> No disrespect intended, but if we do our text stencilling in Pango
> anyway,

The affine transformation code handles all stencils, including paths, shapes, 
arcs, named-glyphs (which use open type fonts), etc..

> it seems like we don't buy us any advantages by maintaining our
> own code for transformations, possibly needing to convert them into the
> Pango form when passing them on.

They do not currently do this.  I am of course open to using pango for these 
transformations if it can do them reliably for generic matrices (i.e. something 
not wedded to text) and you're sure that their API is stable.  However, for the 
purposes of this patch, they are very simple and straightforward (copied 
straight out of the svg specification) and they get the job done.  Check out 
line 120 of stencil-integral.cc.  That's the extent of the complexity.

> I immediately agree that it is a
> nuisance to first do the work of coding this, then do the work of
> replacing it again, then check that the replacement also works.  It
> would have been nicer if I had thought of this earlier.
> 

There is absolutely no problem at all - I would much rather use a stable and 
robust library if it's available.  However, the operations are so minimal and 
simple that the thought didn't even occur to me not to implement them myself 
(it's taking me longer to write this e-mail than it took me to write the code). 
 If you think that Pango can do the job of what's in stencil-integrate.cc, 
lemme know.  I don't see anything in the library that seems designed for this, 
but I of course could have missed something.

> But things like using SSE instruction sets for transforms have a place
> in Pango (where it is a fundamental operation) but would not be a
> reasonable fit of code complexity in LilyPond.  It may be a naive
> assumption without looking at the respective code, but I would at least
> hope that we can rely on the Pango stuff being in reasonable shape, and
> if it isn't, have people care about bug reports without needing to
> invest too much work of our own.

This paragraph is a bit over my head, but again, if you think I can sub in 
Pango for my affine transformations, lemme know where it is in pango & I'll get 
to it!

Cheers,
MS