[Plugin] importDXFtext

TIG

Here's v3.7
https://sketchucation.com/pluginstore?pln=importDXFtext
It now correctly rotates MTEXT [and all other text-types] - I might have messed up somewhere, please test...
Code 50 used by TEXT/ATEXT can be in MTEXT's definitions, but not in the examples provided, so we have to rely on codes 11/21 to work out the vector rotations about the Z, then the result is in radians not degrees !

I'll look at other outstanding issues when I can...

uwesketch

Since version 3.5 and higher another issue has sneaked in: TEXT objects are not imported anymore
(our main test file does not have text objects, so I did not realize it before)
There should be 74 TEXT ENTITIES imported from the attached file called
"map with Isocontours TEXT.dxf"
Currently the console output looks like this:


--------------------------------------------
importDXFtext
--------------------------------------------
DXF = 'D;\xxx\Sketchup\Import\dwgtest\map with Isocontours TEXT.dxf'
UNITS = 'm'

4 STYLES;
....

67 LAYERS;
....

0 TEXT ENTITIES;

25 MTEXT ENTITIES;
....

436 ATTRIBUTE TEXT ENTITIES;
....

Rotation
MText Rotation angle looks good. But the position is not right anymore. I assume the issue is that the wrong rotation (attachment) point is taken.
What I found in the ACAD documentation on MTEXT:

@unknownuser said:

MTEXT code 71: Attachment point:
Values mean: 1 = Top left; 2 = Top center; 3 = Top right
4 = Middle left; 5 = Middle center; 6 = Middle right
7 = Bottom left; 8 = Bottom center; 9 = Bottom right

What I found in the ACAD documentation on rotation angles and text points in relation to text justification:


MTEXT codes 10, 20, 30; x,y,z coord for Insertion point
MTEXT code 50; Rotation angle in radians
MTEXT codes 11,21,31; x, y, z coord of X-axis direction vector (in WCS)
                      A group code 50 (rotation angle in radians) passed as DXF input is converted 
                      to the equivalent direction vector ([u]if both a code 50 and codes 11, 21, 31 
                      are passed, the last one wins)[/u]. This is provided as a convenience for 
                      conversions from text objects
MTEXT code 71; Attachment point;
               Values are; 1 = Top left; 2 = Top center; 3 = Top right
                           4 = Middle left; 5 = Middle center; 6 = Middle right
                           7 = Bottom left; 8 = Bottom center; 9 = Bottom right

TEXT codes 10, 20, 30; x, y, z coord for First alignment point (in OCS)
TEXT code 50; Text rotation (optional; default = 0)
TEXT codes 11,21,31; x, y, z coord for Second alignment point (in OCS) (optional)
                     These values are meaningful only if the value of a 72 or 73 group is nonzero 
                     (if the justification is anything other than baseline/left)
TEXT code 72; Horizontal text justification type (optional, default = 0) integer codes 
              (not bit-coded)
              values are; 0 = Left; 1= Center; 2 = Right
                          3 = Aligned (if vertical alignment = 0)
                          4 = Middle (if vertical alignment = 0)
                          5 = Fit (if vertical alignment = 0)
              See the Group 72 and 73 integer codes table for clarification
TEXT code 73; Vertical text justification type (optional, default = 0); integer codes 
              (not bit-coded);
              values are; 0 = Baseline; 1 = Bottom; 2 = Middle; 3 = Top
              See the Group 72 and 73 integer codes table for clarification

A-TEXT codes 10, 20, 30; x,y,z coord for Text start point (in OCS)
A-TEXT code 50; Text rotation (optional; default = 0)
A-TEXT codes 11,21,31; x, y, z coord for Alignment point (in OCS) (optional)
                       Present only if 72 or 74 group is present and nonzero
A-TEXT code 72; Horizontal text justification type (optional; default = 0). See TEXT group codes
A-TEXT code 74; Vertical text justification type (optional; default = 0). See group code 73 in TEXT

Examples for Rotation issues with MTEXT.

Below cases are based on our dxf test file called "dxf issues with special chars.dxf":

The black text is the unrotated text produced from v3.4
The red text is the rotated text from v3.7
The green text is as it should be (taken from trimble viewer) using the indicated rotation point

Good examples are also in the file "map with Isocontours.dxf", for instance the texts "Rinderweidstrasse" and "Rindwerweidweg".
Below examples have the same black/green/red colouring.
Most rotated green and red texts to not overlap. Only unrotated and the rotated text "3" match.
DXF rotation issue 5 Rinderweidstrasse.png
DXF rotation issue 6 Rindwerweidweg.png

As **a further test, **the attached dxf "map with Isocontours TEXT.dxf" can be used. It contains mostly the same text as the previous sent file "map with Isocontours.dxf", just that most MTEXTs are TEXT. So when importing both in SketchUp, texts should be at the same position, except the descriptions of the isocontours, because these are shifted a bit.

Map with isocontours and texts using TEXT instead of MTEXT

TIG

Thanks for the feedback.
I'll investigate the TEXT missed out weirdness...
The rotation angle seems right but the attachment is off...
Perhaps I need to locate it first, then rotate about that point...
I'll investigate... code-71

uwesketch

@tig said:

Thanks for the feedback.
Perhaps I need to locate it first, then rotate about that point...
I'll investigate... code-71

Yes, angles are
I think so too, as 3D text cannot be created indicating the position. So the attachment point can be picked from the bounding box only in a second step. And then the attachment point is moved to the position indicated in the codes (10,20,30) and the rotation (around the attachment point) applied as indicated in codes (11,21,31) or code 50.

TIG

Here's v3.8
https://sketchucation.com/pluginstore?pln=importDXFtext
I corrected the stupid typo which was preventing TEXT being processed.
I think I've now sorted the text-group's rotation about its origin... please test and report if otherwise...

uwesketch

Whow, that was quick. I tested.

The TEXT is back, but the Block Attribute Text is now gone
For the file "dxf issues with special chars.dxf"
with version 3.4:

8 STYLES:
16 LAYERS:
0 TEXT ENTITIES:
11 MTEXT ENTITIES:
16 ATTRIBUTE TEXT ENTITIES:
...
Making 0 TEXT Entities...
Making 11 MTEXT Entities...
Making 16 ATTRIBUTE TEXT Entities...

with version 3.8:
8 DXF STYLES:
16 DXF LAYERS:
0 TEXT ENTITIES:
11 MTEXT ENTITIES:
16 ATTRIBUTE TEXT ENTITIES:
...
Making 0 TEXT Entities...
Making 11 MTEXT Entities...
...

For the file "map with Isocontours TEXT.dxf"
with version 3.4:
4 STYLES:
67 LAYERS:
74 TEXT ENTITIES:
25 MTEXT ENTITIES:
436 ATTRIBUTE TEXT ENTITIES:
...
Making 74 TEXT Entities...
Making 25 MTEXT Entities...
Making 436 ATTRIBUTE TEXT Entities...

with version 3.8:
4 DXF STYLES:
67 DXF LAYERS:
74 TEXT ENTITIES:
25 MTEXT ENTITIES:
436 ATTRIBUTE TEXT ENTITIES:
...
Making 74 TEXT Entities...
Making 25 MTEXT Entities...
...

TIG

Aargh!
I disabled the ATEXT for quicker testing...
But I thought I set it back on !!! typo !!!

Here's v3.9 that's fixed.
I also added different names for the types of DXF text used to make the groups [TEXT..., MTEXT..., ATEXT...], so it's easier to find the type etc...
https://sketchucation.com/pluginstore?pln=importDXFtext

uwesketch

No problem. Shit happens ,-) and for this I test

Another issue came now back.
The shift of the 3D-Text in case there are letters going beyond the writing base line:
Issue with letters going beyond the base line

The type of text is helpful. Could you also add the content of the text somewhere?
Then I could even search for a specific 3DText. It does not have to be the full text. Maybe the first 20 chars, so that the outliner does not yet get a horizontal scroll bar?
add 3DText value to group name

TIG

The -ve sign should move up ??
Weissputz has a downstanding 'p' again they should push up ??
I'll investigate...

uwesketch

@tig said:

The -ve sign should move up ??
Weissputz has a downstanding 'p' again they should push up ??
I'll investigate...

Yes, it worked in version 3.6. All nicely shifted up. Including characters like °'`^". They were shifted up to the top.

TIG

Investigating...

TIG

Here's v4.0
https://sketchucation.com/pluginstore?pln=importDXFtext
It fixes that text alignment glitch I just reintroduced !!

uwesketch

Much better. Thanks.

in the test file "dxf issues with special chars.dxf" there are now only two issues left.

The text "Knickarmmarkise" has the attachment point in the "middle center", but I think you take the point "left center". Therefore the text is shifted to the right. Can you implement the attachment point "middle center" / "right center"?
In below screen shot, green is the position where it should be, red the position produced by version v4.0
wrong attachment point.

The large text starting with "Masse am Bau:" is nicely aligned left, but it is shifted downwards by exactly one letter height. In version 3.4 (to which I compare version 4.0) this was correctly placed.
In below screen shot, green is the (correct) position from version 3.4, red the position produced by version 4.0.
text shifted by one letter height downwards

P.S. TEXT entities still not working properly:
version 4.0, says in the console, it is doing TEXT, but they are not created in SketchUp!
I get :
...
74 TEXT ENTITIES:
...
Making 74 TEXT Entities...
Making 25 MTEXT Entities...
Making 436 ATTRIBUTE TEXT Entities...
...

BUT: the TEXT entities are NOT CREATED in SketchUp.

TIG

The text "Knickarmmarkise" has the attachmentpoint [71] in the "middle right" - i.e. set to 6
Which is MR - the associated Ruby align assignment is flaky !
As it doesn't reset it properly I've rewritten that code - should work now...
Please check...

The alignment of the "Masse am..." text is more complex as its alignment is set to TR 3 and there are 2no \P characters in the string - equivalent to \n newline in Ruby - that splits the text-string into its 'lines'...
Please test as I'm not sure this update fixes it, because the number of lines in a string affect the overall group's height and sometimes this might mess up vertical alignment adjustments ??
If if does mess up, then I have to look at analyzing the string for \n and adjust any vertical alignment accordingly [using string.lines.count etc]

Here's v4.1
https://sketchucation.com/pluginstore?pln=importDXFtext

uwesketch

The "Knickarmmarkise" is now good and yes, the attachment point is 6, not 5.

But all other MTEXTs are now either a bit off or completely off.
It looks like that the higher the rotation angle the more off the text is placed.
The "SN Q4" texts are about 26meter off, the dimension value 17^5 is 23m off, the 1.24^5 dimension value is 34meter off. the "OK Mauer ca. 549.79" is about 6m off to the right.

The "Masse am Bau:" has not changed position compared to version 4.0.
BTW in version 3.4, 3.5, 3.6, etc it was correct. Can you not compare to the code of v3.4?

TIG

One step forward, one step back !

I'll investigate...

uwesketch

Thanks. Can you also look into why TEXTs are not created anymore in SketchUp, even though in the console it says that "Making .. TEXT Entities"
?

TIG

Another problem !

TIG

I'll look at the alignment issue shortly...

However, the current TEXT import does work for me, albeit with text pieces miles from the origin, making selecting / viewing / editing them very awkward [even with the help of the Outliner] - when using your TEXT dxf example - is this the issue you are referring to ?
e.g. the first piece of TEXT processed is -
X = 2677161.876174174 [42.25 miles from the origin] Y = 1237562.802 ... Text = "430287"

Also note that in that file several ATTRIBS also have no 'string' at all [code 1] - the omission is in the DXF file, not the ruby side...

uwesketch

Yes, it is the file called map with Isocontours TEXT.dxf.
I am running with v4.1
after the import finished, I see only 250 sub groups. 225 ATEXT and 25 MTEXT.
They are either called "ATEXT #..." or "MTEXT #...".
But there are no sub groups called "TEXT #..." in the outliner.

The first TEXT entry listed in the console is:

Layer = 01139
Color = 0
X = 2677161.876174174
Y = 1237562.802
Z = 0.0
Height = 0.9999999999999997
Text = 430287
Oblique = 15.0
Justification_H = 2
Justification_V = 2
Style = STANDARD
Rotation = 0.0

Yes, the origin is far off. This is the Swiss coordinate system LV95.

There are or instance two TEXT called Rinderweidstrasse and Rinderweidweg. These should be easily visible in Sketchup in the very top right of he imported group, but they do not exist.
(choose parallel projection, top view, then in the outliner select an ATEXT and then "yoom selection" in the context menu)
BTW, the first 12 MTEXT are in the bottom left corner of the group near the Origin, the other MTEXTs and the ATEXTs are in the top right corner of the group.