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

[André W. <wo...@us...>]

Dear Michael,

I'm sorry, could we please rewind the whole discussion. And let us not talk about code but about the way it should work.

To me, the current behavior is the correct (and only correct) one. Let me explain again, why I think so.

1. The arrow should be "part" of the path, i.e. the tip and the constriction point needs to be positioned on the path.

2. For pos == 0 the arrow should be at the beginning, either in the forward direction (reverse == 0) or backwards (reverse == 1). As it is a common use-case, pos == 0 and reverse == 1 is available as "barrow".

3. For pos == 1 the arrow should be at the beginning. Again, it can be reversed. pos == 1 and reverse == 0 is an "earrow".

4. Between those limits the pos argument should interpolate linearly. And yes, this means that for pos == 0.5 neighter the tip nor the constriction point of the arrow is at 0.5*arclen().

Do you agree to this functionality?

I do understand, that you might wonder about my solution to split the path to properly align the arrows. But this is a straight forward and elegant solution to work around the intrinsic problem, that pos interpolates on the range arclen-constrictionlen. It needs to be that way.

The interesting question is whether we can do what you want by adding another parameter or so. However, I don't see an obvious solution to it. Sure, we could add something like arclenfrombegin and arclenfromend like we did for the text decorators. But you don't really want that to position arrows at the circle.

You know what? I really think, that my suggestion in splitting the path is the most elegant solution you can ever achieve. Consider the case, where you want to draw the arrow at the "x-axis", i.e. at zero degree. You can do so at the moment by using earrow to get the tip on the line or barrow(reverse=0) to get the constriction point on the line. This is very unsteady and will always be.

I'll add some comment below, but don't mind.

Best,


André


Am 23.05.2012 um 17:18 schrieb Michael J Gruber:

> 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".

The point is that the arrow should always be part of the path, not extending it.

> 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!

What exactly is "in the middle of the path?" if you talk about it "visually"? To my mind it does not mean that the top nor the constriction point is at half of the arclen.

It looks a little strange, as you change the size of the circle here. Please fix the size of the circle and change the size of the arrow. This is geometrically identical. But look at the result. Both, the tip and the constriction point will move. Isn't it right that it works that way? I don't see something wrong in it.

>>>> 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.

And to me it is the other way around. "arclen-constrictionlen" clearly is the which is available for moving the arrow around.

> 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).

Sure, we position the arrow, not the tip of the arrow. We need to do so, as for pos=0 (and reverse=0) the constriction point is at the beginning of the path. What else should be it?

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

Well, to me an arrow is something like a text. It has some extend. If you center it, the text starts before half of the path and ends after half of the path.

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/