MText Rotation Not Being Read about acadsharp HOT 6 CLOSED

In the Dwg Reader there is this line:

//X-axis dir 3BD 11 Apparently the text x-axis vector. (Why not just a rotation?) ACAD maintains it as a unit vector.
mtext.AlignmentPoint = this._objectReader.Read3BitDouble();

So I'm guessing that the rotation is calculated using the AlignmentPoint and the InsertPoint.

For the Dxf we need to detect if the angle is provided or not, and then calculate the AlignmentPoint (which it should be renamed as a vector) or the angle depending on which one is provided.

from acadsharp.

That is exactly the information that I need. Confirmed that the AligmentPoint and InsertPoint were both properly set to determine the angle.

Since the angle is determined If this is the case, is there any time that MText.Rotation is actually used? I see it has DxfCodeValue(50) attribute so I'm presuming that it is read at some point, but I feel like whoever uses this library needs to determine which value to use.

In this case, do we add any "helper" methods (or property) like MText.Get2dRotation and MText.Set2dRotation on the class to ease the use of this or do we just leave it up to the Library consumer to determine which to use (AligmentPoint and InsertPoint vs Rotation)?

I'm willing to do this if I have a better understanding if/when the Rotation DXF code is used.

I deal with 2D DWGs regularly so I forgot this was probably done this way to calculate the rotation in 3 dimensions...

from acadsharp.

It seems that the DWG works only with the AlignmentPoint because checking the documentation the rotation is not read at any point, so for DWG when AlignmentPoint is set, the Rotation automatically should get it's value.

For DXF it seems that you have both options, but I presume that both values must be coherent with each other, if not, Autocad just picks the last value read:
Documentation: "A group code 50 (rotation angle in radians) passed as DXF input is converted to the equivalent direction vector (if both a code 50 and codes 11, 21, 31 are passed, the last one wins). This is provided as a convenience for conversions from text objects"

For me the best way to approach this issue would be to to modify the { get; set; } for the Rotation and the AlignmentPoint being this last one a normalized vector:

First scenario:
The costumer/reader sets the Rotation, the set calculates the new AlignmentPoint and changes the value so both of them are coherent with each other.

Second scenario:
The costumer/reader sets the AlignmentPoint, the set calculates the new Rotation angle and sets the new value.

This way both values are always linked and they will "make sense" at any moment.

This is the solution that I propose but I accept any ideas or alternatives.

from acadsharp.

IMPORTANT NOTE:
I've notice that the common fields for TextEntity and MText have the same text in the xml documentation, so for MText the documentation is not valid and needs to be updated, the branch linked to this issue will refactor this class.

from acadsharp.

Excellent. Thank you for digging into this. I agree that modifying the properties set methods is the best way. These are pretty high priority for me so I will go ahead and make a PR for this modification less the documentation.

from acadsharp.

PR created, feel free to push your branch to the PR's issue if you want, I'll give a second look before merging.

from acadsharp.