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

[Michael J G. <mic...@us...>]

André Wobst venit, vidit, dixit 22.05.2012 10:10:
> Hi,
> 
> Am 22.05.2012 um 09:18 schrieb Joerg Lehmann:
>>> 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.
> 
> Jörg is right. We definitely don't do that. pos defines the position
> of the tip of the arrow. Originally before your patches. We really
> should stick at this simple rule.

Well, then please tell me what r3079 was about:


diff --git a/pyx/deco.py b/pyx/deco.py
index 3206627..9f11211 100644
--- a/pyx/deco.py
+++ b/pyx/deco.py
@@ -472,7 +472,7 @@ class arrow(deco, attr.attr):
             constrictionlen = self.size * 1 *
math.cos(math.radians(self.angle/2.0))
             arrowheadconstrictionlen = None

-        arclenfrombegin = self.pos * anormpath.arclen()
+        arclenfrombegin = constrictionlen + self.pos *
(anormpath.arclen() - constrictionlen)
         direction = self.reversed and -1 or 1
         arrowhead = _arrowhead(anormpath, arclenfrombegin, direction,
self.size, self.angle, arrowheadconstrictionlen)


This shifts the head by constrictionlen to the right, and the later
r3151 made the direction of the shift depend on "reversed".

I mean, I even uploaded those circular images where you can see it clearly.

>>> 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.
> 
> Really, I don't see where this creates any problem. It's simple and
> it's the right thing to do.

Again, please, look at the pictures again: There's currently no way to
position an arrow head visually in the middle of a path. And the
positions don't scale if you scale the path!

>>> 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.
> 
> Sorry, IMHO this whole discussion will not result in anything useful.
> 
> 
>> We would need to extend the path, which is rather tricky. But doing
>> the min/max thing is not a solution, IMHO.
> 
> 
> Don't even think about extending the path. This is an absolute no-go.
> (I do understand that Michael did try to not do this. But he did so
> by using some very obscure min/max thing. Absolutely bizarre. No, no,
> no. Never.)

I never suggested extending the path, and I never did it. You see, the
bizarre thing is that an arrow at pos=0 is not positioned in the same
way as an arrow at pos=1, *if* you agree that pos is supposed to be a
position relative to arclen. Calculating pos relative to
(arclen-constrictionlen) is what seems completely bizarre to me.

Let me repeat: a head at pos=0 is positioned differently (with respect
to the start point of the path) comapred to how a head at pos=1 is
positioned (with respect to the end of the point).

The difference between us is that you seem to care about begin and end
arrows mainly, while I care about mid arrows (also).

Michael