Re: [PyX-devel] [PATCH 2/2] arrow: make pos relative to the full arclength

[Joerg L. <jo...@us...>]

Hi Michael,

sorry - too much traveling last week.

On 14.05.12, Michael J Gruber wrote:
> Joerg Lehmann venit, vidit, dixit 13.05.2012 17:20:
> > Hi Michael,
> > 
> > Thanks for the patch. I am not sure, however, whether it really improves
> > the situation. In particular, I do not like the fact that varying the
> > pos argument at the beginning and end of the path does not move the
> > arrow at all. If I understand the intention of the change correctly, it
> > means that the arrow is always positioned at the end of the
> > constriction - as long as this is possible. Why is this desirable?
> 
> That means I have not made myself clear enough. Let me try again:
> 
> We do try to position the arrow head based on the "inward tip"
> (constriction center) since r3151, which can be considered the "middle
> of the head". 

I am not sure if I understand you correctly, but I would say no.

> I don't propose changing that. PATCH 1/2 only makes sure
> that the same positioning is applied to reversed heads, i.e.
> non-reversed and reversed are mirror symmetric with respect to (an axis
> through) the "middle of the head", i.e. the positioning center.

> The problem I'm trying to address with PATCH 2/2 is: An arrow head
> positioned with pos=0.5 ist not positioned at 0.5*arclen, e.g. a
> semicircle. It is positioned at 0.5*(arclen-constrictionlen).

But this patch changes the positioning of both heads again - so in fact
your two patches do change this.

> This becomes quite visible when you're trying to position arrow heads at
> various intermediate positions, but also when you try to line up arrow
> heads with other decorations (such as text) which are *really*
> positioned at pos*arclen (or relarclenpos*arclen, there's no consistent
> naming).

The naming is another issue - we should fix that. 

> In the example which I provided, notice how the position of the ("middle
> of the") arrow heads does not scale linearly with the radius of the
> circle, even though the pos argument is always the same.

I think, I see what you mean, but still the other solution also has
it's drawbacks - in particular the one I pointed out previously, namely
that it fixes the arrow position for a finite interval around pos<=1.

> It's the result of this principle:
> We calculate/restrict "admissible positions" so that 0 and 1 mean begin
> and end arrow, where an end arrow head has its tip lined up the end of
> the path, and a begin arrow has its constriction center lined up with
> the start of the path. That's why (1-0) has to mean
> (arclen-constrictionlen) which creates the other problems.

Yes.

> Basically, I would love (1-0) to mean arclen (patch 2/2), i.e.
> everything relative to full arclen, then a beginhead would have pos=0,
> and an endhead would be at pos=1-constrictionlen/arclen. Consequently, a
> head at pos=1 would have its constriction center ("middle") at the end
> of the path. This would require additional adjustments to the way we cut
> the path, though. Which is why I did the min/max thingy.

We would need to extend the path, which is rather tricky. But doing the
min/max thing is not a solution, IMHO.

Best,

        Jörg