Makes sense. Then it could be fixed consistently as done with MTEXT.
![](/uploads/imported_avatars/upload/2cde590848b478d382d186ea9f7f6116_684703.jpg)
Posts made by uwesketch
-
RE: [Plugin] importDXFtext
-
RE: [Plugin] importDXFtext
@tig said:
I got to the bottom of this !
It did process all of the TEXT but then it wasn't adding the 3d-text geometry !!
Now it's fixed...I tested v4.3 re TEXT: IT IS BACK
Great!
And the position and rotation of TEXT is very precise.
Funny, that two TEXTs ("Sunnenberg" and "Rinderweidweg") are slightly off (only by a 1/4 of the font height).
In below screen shots, green are TEXTs that are precisely positioned, red marked the two longer TEXTs that are a bit shifted. I think it can be ignored, but still wanted to let you know.
-
RE: [Plugin] importDXFtext
I tested v4.2: better again
TEXTs are still not imported, the console output is a bit different now, but in Sketchup there are no TEXT groups created. Only 25 MTEXT and 225 ATEXT groups.
I am testing btw with SketchUp 2022. DXFImport v3.4 is running on SketchUp 2021.
console output of importing "map with Isocontours TEXT.dxf":
Making 74 TEXT Entities...
74 : 0
Making 25 MTEXT Entities...
25 : 0
Making 436 ATTRIBUTE TEXT Entities...
225 : 211Rotation testing (dxf issues with special chars.dxf):
Here the 3DText objects that were far off in the lat version, are now closer again, but still not fully correct:
It seems the attachment point for rotation is not read correctly:In below screen shots, black is the unrotated text from v3.4, green is where it should be according to the DXF definition, red is where the import is placed.
Looks like all are attachment point issues, except the "Masse am Bau:" which is shifted down since version 3.4.
-
RE: [Plugin] importDXFtext
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.0Yes, 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. -
RE: [Plugin] importDXFtext
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"
? -
RE: [Plugin] importDXFtext
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? -
RE: [Plugin] importDXFtext
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
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.
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.
-
RE: [Plugin] importDXFtext
@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.
-
RE: [Plugin] importDXFtext
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:
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?
-
RE: [Plugin] importDXFtext
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...
... -
RE: [Plugin] importDXFtext
@tig said:
Thanks for the feedback.
Perhaps I need to locate it first, then rotate about that point...
I'll investigate... code-71Yes, 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. -
RE: [Plugin] importDXFtext
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 rightWhat 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.
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.
-
RE: [Plugin] importDXFtext
@tig said:
The
2.88\A15
is therefore equal to2.88⁵
I can trap for that, but are there any other decimal parts e.g. 2.88³ ??I see that \A is a DXF alignment code, where 1 is btm, 2 is center, 3 is top
The part after that is the formatted string - e.g. 5
It also has a trailing ; that needs stripping....I have created an additional test case (see attached dxf file) with the following dxf script:
\A1;Nische für späteren \A1;{\fArial|b1|i1|c0|p34;17\fArial|b1|i1|c0|p34;\A1{\H.66x;\Ssuper;normal}\A1{\H.36x;\Sscript;small}} DuscheneinbauBut I think this is really pushing it.
I think a formatting command starts with a "" and ends with a ";"
- The \H..x; command indicates the text height as a factor.
- The \S...; command is the superscript. The text to superscript starts right after the "S" until the ";".
- The \Ax; command can also be written without the ending ; as it takes only one parameter.
- curled brackets {} are to limit a command to the block inside the curled brackets.
The import looks like this:
It should look like this:
-
RE: [Plugin] importDXFtext
Looks very nice! Thanks.
This numbering format with the "mm" number shown superscripted only shows a whole number, no decimals in the superscript.
But in theory there could be also more than one digit/character superscript.I have attached another dxf which is as received. It contains a map and isocontours with a lot of text. Here you see, that rotating the text along the contours would be very helpful.
The coordinate system is the Swiss coordinate system LV95.
The origin is 2'677'085 m west and 1'237'410 m south of the lower left corner.I have another similar file which is in 3D. But I think the 2D is good to start with.
-
RE: [Plugin] TT_Lib²
As I had the ruby console open at startup of sketchup, I saw the following warning message during initialization of TT lib latest version 2.12.3:
C;/Users/xxx/AppData/Roaming/SketchUp/SketchUp 2022/SketchUp/Plugins/TT_Lib2/win32.rb;12; [b]warning; Win32API is deprecated after Ruby 1.9.1; use fiddle directly instead[/b]
Probably unimportant, but just wanted to mention.
-
RE: [Plugin] importDXFtext
Thanks a lot.
After installing the Plugin, the version text still says 3.4, so I first thought the install did not work. But all fine.
Yes, I have more dxf files. What should they ideally contain?
-
'Orange': Leading space: confirm it works
-
'blue': works for the minus sign.
Tested as well with other chars like: °"*='^`
But these are still placed down at the bottom. -
'green': works nicely
-
'brown': Superscripts. I see no difference yet.
The MText contains for instance the following value string in the dxf:
\A1;{\fArial|b0|i0|c0|p34;2.88\fArial|b0|i0|c0|p34;\A1{\H.66x;\S5^ ;}}
The imported result of this is:
2.88\A15
I think correctly interpreted is the follwoing part:
\A1;{\fArial|b0|i0|c0|p34;2.88\fArial|b0|i0|c0|p34;.....}But the part \A1{\H.66x;\S5^ ;} is generating the string \A15
I think that the dxf code \H.66x;\S....^ means: by a factor 0.66 of font height shift the string starting after /S upwards (^)-
'components': I would prefer if the 3D-text is created as a component, not a group. The description (not the name) of the component could then contain the text used in the 3D-text. If someone wants to recreate the 3DText manually, only the description has to be copy/pasted into a new 3DText.
If the text would also be used as the instance name, The text would be easily recognizable as well in the outliner. But this is just an option.
The component name (definition) can stay as it is now. -
'Rotated MText': would it be easier, if only a rotation around the z-axis would be considered? I think the rotation angle and the position of the "attach" or "center" point is an attribute in the dxf of the MText.
For me this would be enough, as I import dxf text only for 2D drawings. -
'Purple': Line breaks.
I am not sure, but I thought in dxf there is kind of a column width defined for the MText Codes. Could this be used to estimate the number of characters that fit into the width? For instance assuming an average character in a text is half as wide as high.
Example: if the width of the box is 1500mm and the font height is 250mm, then we can place around 12 chars into the box before doing a line break.
Forget the MTEXTBEGIN and MTEXTEND, I thought this defines the width of the mtext box. -
'Dimensions':
I agree it is not trivial. I was thinking about a pragmatic implementation like: -
get the type of dimension as linear or radial. If the dxf contains a type we cannot map in SketchUp, then ignore it and just import the text as is done today.
-
get the insertion/definition points. But do not try to attach the dimension to an entity.
For a radial dimension, just create a small circle (for type diameter) or arc (for type radius) at the definition point and attach it to the SketchUp radial dimension. Once the dimension is created, delete the circle/arc. -
get the text to be used. (do not let Sketchup set the text)
-
try to figure out the arrow style (none, point, open arrow, closed arrow, dash). If nothing matching is found in the dxf, just use the default arrow style from SketchUp.
-
get the distance of the dimension line (linear) or text (radial) from the definition point(s). I would start with only dimensions in the XY plane. (2D).
(I will try to find out how these dimensions can be drwan using ruby in the general case. In the SketchUp UI I think it is limited to 6 variants: either the dimension measures the X, Y, Z coordinate or the length of the projection on the XY, XZ or YZ plane)
-
-
RE: [Plugin] importDXFtext
I have now compared a few files we receive regularly and a lot of the imported text looks fine.
I have compiled below a list of differences and have created a dxf showing these, so that you can readily reproduce the cases. (The dxf file is attached at the end.)The color indications below give the link to the pictures.
The post is a bit lengthy. But for some points I think it took me more time to document than it will take to implement the change in the plugin
Btw, the print screens were done in Trimble connect where I uploaded the dxf file and the skp file with the imported text.Let me know what you think.
- Currently the 3D-text are all groups. Could instead components be created? Then put the text into the instance name and description (in case too long). Like this we can see the original text in the outliner and component list
-
(Orange marked) it seems that a leading space is not respected. For instance for m², the dxf contains " m".
If I create a 3D-text for " m" manually in SketchUp, this is converted into 3D-text component for "m", but the origin of the component is positioned to the left of the bounding box.
So creating SketchUp 3D-texts as components should solve the issue, if the origin is used to place the 3D text at the position as defined in the dxf. -
(blue marked) a minus sign (dash) as a value of a block Attribute definition is placed too low compared to the text beside it.
See DUMMY_561, which contains a value being a dash "-".
The issue here is, that SketchUp creates a boundingbox around the minus sign and the origin of the created component is on the lower left corner minus sign.
So the minus sign is placed too low.
Possible solution: always add an M at the end or beginning (when aligned right) of the string for 3D-text.
Then shift the origin of the 3d-Text component along the Y-axis to the lower left corner of the M. Then delete the M from the generated 3D text. -
(green marked) some 3D-Texts are positioned a bit too high.
Reason is, that they contain a p, y, j or g and then the lower end of 3D-text bounding box is not on the writing base line.
Currently the lowest point of the letter is positioned on the writing base line of normal text - meaning too high.
This could be corrected by shifting the 3D-text box a bit down. Or if 3D-text components are created, then shift the origin a bit up.
- (brown marked) dxf superscript and subscript commands are not recognized.
Superscripts are used in architetural drawings to indicate the mm number.
"20 superscript 5" means 20.5cm, "2.92 superscript 5" means 2.925m
Does UTF-8 have codes for superscripts which can be used? For example U+2075 (8309) is the unicode number for superscript 5.
See https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts
Alternatively a separate 3D-text could be created for the superscript signs like:
Make the superscript or subscript number half the height of the normal text and shift by half a font height up or down. Like this it does not get above or below normal text.
- (purple marked)** add a line break in the 3D Text** so it gets not wider than indicated in the dxf file. Use the MTEXTBEGIN and MTEXTEND definition of the dxf? (assuming this defines the width of the MText box.
2nd example: (I think this is a bit tricky to implement):
- (grey marked) create SketchUp dimensions from DXF dimensions.
Use only the begin and end point and the position of the line from the dxf.
For the arrow head, just try to figure it out from the dxf and use the Sketchup model default, if in the dxf we cannot find the three possibilities given in SketchUp.
For texts with a line to a point like heights, create a dimension where the line is not offset from the starting point and choose text position "start outside" and no arrow head or a dot.
Or create a radius dimension and type in the text and choose an arrow or point as arrow head.
Set the dimension text in SketchUp to what the MText in dxf indicates.
-
(red marked) MText rotated: currently MText that is rotated is not rotated during import. Can this be done?
Currently dimension texts are also always imported as horizontal as they are MTEXTs. Could one rotate the dimension text to be along the dimension lines?
However, if dimensions are imported as such in SketchUp, then this is not important anymore.Btw, text that comes from a block attribute is rotated correctly already.
-
RE: [Plugin] importDXFtext
@tig said:
Thanks for the testing and reports.
I've added a 'fall-back' case to the code if the DXF is no formed to ACAD's normal standards, so the PluginStore's version now has that...thanks, will download and install and run.
-
RE: [Plugin] importDXFtext
Hi TIG
now that the import is flowing through nicely, I looked at the import result a bit closer.
I found a few minor issues, which would be nice, if they could be resolved.
However, as it takes a bit of time to create a case so you can easily reproduce it, I wanted to ask beforehand, if you will have time and interest to look into it.