feat(): originX start, end

[ShaMan123]

Supporting rtl means supporting originX start, end.
Consider a simple common use case.
I have a text object, my app is multi language and I want it to be 50px from the start (left or right depending on the direction)
This is why we need originX start, end.
The thing is we will need the parent's size for these calculation in case we are in rtl.
This is not the case in initialization of course. So I thought in case there is no parent ref (group/canvas) we use the object's size the resolve origin and then recalculate from the onAdded method of the parent.
This also means that we will need to recalculate position of objects once their ancestors resize.
Fortunately, now that group is a layout engine that is totally plausible. We're talking about a simple map/array containing these objects and an iteration each layout pass.
@asturur @mistriel thoughts?

[asturur]

So supporting RTL writing and layout i don't think they map on 1:1
There is not layout logic in fabric js, like saying i want this object to always be at 50 pixel from a particular side of the parent.
I really don't want to add more stuff in that direction for now.

This would be applied just for text, and i wish for the developer to assign origin left/right after inspecting the object by himself.

I m strictly convinced that we are feeding the library with too many option i want less of them or simpler one.

[ShaMan123]

That's my thought as a rtl developer.
I understand what you are saying.
It shouldn't be hard on the dev calculating the position

[mistriel]

I have faced this issue when tried to implemented objects alignment similar to what we have in other known editors (Align to left, right, center, top, etc) The main concern was that we need to identify each iText object to understand if its ltr or rtl to identify the start position. This is very tricky when it involves several mixed objects like iText and image as each object start is not consistent.

My 2 cents is that start & originX should not be affected by direction at all - they should stay always consistent with the current LTR first approach. It will make the difference only for the text direction when rendering the actual context.

WDYT ?

[ShaMan123]

My 2 cents is that start & originX should not be affected by direction at all - they should stay always consistent with the current LTR first approach. It will make the difference only for the text direction when rendering the actual context.

I didn't think about that. Now that I think about it I agree with you and perhaps I'll add that the parent gives the context. We can easily check object.group?.direction. I assume HTML spec works like that.

And regarding impl I think that adding this logic to the setCoords method is simple and correct. Canvas/Group call object's setCoords once an object is added. That's exactly what we need to position stuff to the right of the parent.

[mistriel]

Sounds good !

[ShaMan123]

Perhaps it is a separate thing from origin. WDYT?