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
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
PyX-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyx-devel
