[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.
-
The TEXT is NOT imported for me.
Says 74 made, 0 failed.
But in the Outliner there's nothing ! a mystery...
Investigating... -
I got to the bottom of this !
It did process all of the TEXT but then it wasn't adding the 3d-text geometry !!
Another stupid temp-typo...
Now it's fixed...
Here's v4.3
https://sketchucation.com/pluginstore?pln=importDXFtextI'll look at the rotation reports next...
-
@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.
-
The dropped tail of the 'g' is causing the issue - it's fixable...
-
Makes sense. Then it could be fixed consistently as done with MTEXT.
-
Here's v4.4 which fixes the dropped letters, like 'g', affecting the text's insertion-point.
https://sketchucation.com/pluginstore?pln=importDXFtextPlease re-comment on the rotation/alignment issues you've previously raised, as recent changes might have had an influence...
-
TEXT is now all fine. Perfect!
In the same file there are as well some MTEXTs. (The blueish texts).
These MTEXTS are still shifted as soon as there is a rotation involved.
Later I will also send a report based on our other test file. -
Thanks, I'll investigate it all tomorrow...
-
I tested v4.4 with the testfile "dxf issues with special chars.dxf".
The displacement of rotated MTexts is the same as with v4.2 reported in this post:http://sketchucation.com/forums/viewtopic.php?f=323&t=23002&p=678093#p678060
-
Here's v4.5
I'm hopeful it addresses the alignment / rotation weirdness...
https://sketchucation.com/pluginstore?pln=importDXFtext
Please test and report back... -
The first test with the imported file "map with Isocontours TEXT.dxf" showed no differences to the dxf file anymore. Very nice!
Also the file "dxf issues with special chars.dxf" did not show position diffs due to rotation. But there is another issue, which I will report in a later post, as it does not have to do with rotation.
However I have another file called "map with Isocontours.dxf" where all text are MTEXTs. (see attachment)
99% are at the right position, but the imported text is slightly wider than the text in dxf.
I checked the dxf and saw, that these MTEXTs have a "width factor" of 0.84 defined. This factor pretty much explains the difference. It is defined on style level. The style is called "ERSTELLTER_STIL_1" and in code 41 you find the 0.84. I think the factor could be applied as well in SketchUp by using the "Scale feature".
Text scaling issue:
During import, this style is also read and the factor properly reported as WidthFactor, but it is not applied.
The console output is:2 DXF STYLES; Name = ERSTELLTER_STIL_1 Height = 0.0 WidthFactor = 0.84 Oblique = 0.0 Flipped = 0 FontFile = FontName = Arial Color = 256
In below screen shot, green is the DXF file, red the imported 3DText.
Only two MTEXTS are not right positioned:
It seems it has to do with the letters qpgjy, but this time it is shifted downwards.In below screen shots, green is the DXF file, red the imported 3DText.
-
Here's v4.6
https://sketchucation.com/pluginstore?pln=importDXFtext
I think it addresses the Mtext dropped string problem if there are certain dropped letters like 'g'.
The width-scaling should also now works. [Also the DXF Style 'Standard' is now applied more logically]
Some add string formatting with residual \A characters is also improved ?Please report back...
-
Sorry, took a bit longer this time.
I dislocated for the weekend and have to install version 4.5 and 4.6 on another PC.
Somehow I have the impression that v4.5 is perfect for TEXT, but 4.6 not anymore.
But let me test all files in details and come back. -
For v4.6 it seems to work OK with TEXT for me, but I welcome your insights / comments ...
In passing, I have now added the text's box-width to MTEXT, but currently do nothing with it.
Usually it's 0.0, but if the text-string is long it can have a dimension.
However using that to divide up and wrap the string using \n is fraught with issues - like how do we decide where to break etc... So I've left it along, for now... -
I think I found the issue regarding TEXT:
in v4.5 you take the font Arial Narrow, as indicated int he DXF "map with Isocontours TEXT.dxf".
In v4.6 you take the font Arial.
The screen shot below shows in green the original DXF, in black the text imported with v4.6
The text in grey above is a 3DText I created with font Arial. The text in grey at the bopttom is a 3DText I created with font Arial Narrow (same as when imported with v4.5.
Can you change that back for TEXT to how it worked in v4.5?
Oblique angle: Where we will always have a difference is the oblique angle. It is in this DXF 15° - see green text above. As there is no corresponding feature in SketchUp 3DText and the scale tool cannot be used, an approximation would be making the text italic. However italic has an obliquity angle of only 9°.
MTEXT in "map with Isocoutours.dxf" imported with v4.6:
This looks now perfect!MTEXTs and ATEXT in "dxf issues with special chars.dxf" imported with v4.6:
also here all looks very good. Great.
The "Nische für späteren Duscheneinbau is now as well shifted to the right height.
Also the text with "Masse am Bau:"text word wrap: Indeed, the next step would be to do the text word wrap. I have written down a few ideas. From a simple approximation to a luxury implementation.
Unfortunately I forgot to take the notes with me. So I can only send it next week.
But I remember the simple approach- Get the width of the box (BoxWidth) from code 41 not being empty/missing and not 0
- calculate an average character width (CharWidth). This is done by taking 2/3 of the letter height - which we know from the DXF.
- calculate the number of characters fitting into the width of the box:
NoOfChars = BoxWidth / CharWidth - Loop over each line in the MText (= \P delimited string) and wrap this line using some regexp or below piece of ruby:
BoxWidth= 660 CharHeight = 100 CharWidth = CharHeight * 2/3 NoOfChars = BoxWidth / CharWidth result = "" word_array = 'To be or not to be-that is longwordwise the question'.split(/\s/) line = word_array.shift word_array.each do |word| if (line + " " + word).length <= max_length line << " " + word elsif word.length > max_length result << line + "\n" unless line.empty? line = word else result << line + "\n" line = word end end result << line puts result
Maybe you can already do something with it and maybe it is even enough.
-
Thanks for the word-wrap ideas...
I had some similar ideas...
I'll investigate further...The 'Font' name is taken from the DXF text's entries [3] from Style 1000.
in ...TEXT.dxf 'Arial Narrow' is the font in the STYLE 'STANDARD'
It defaults to 'Arial' if the font is not available on your PC computer.
But 'Arial Narrow' should be available !?Although the ...TEXT.dxf includes that Font in a Style, it is not picked up in the file parsing...
But some other Fonts are e.g. 'Cadastra' and 'Univers'...
It's because the names 'Standard' & 'STANDARD' are used in the file in different lines...
Now trapped...Here's v4.7
https://sketchucation.com/pluginstore?pln=importDXFtext -
Well done. I looked at the "map with Isocontours TEXT.dxf" and now all fine!
The other imported dxf files are unchanged good.
Looking forward to see how the word wrapping works. -
Here's v4.8
https://sketchucation.com/pluginstore?pln=importDXFtext
MTEXT with overly long text strings, but with a predefined 'width-box', now get extra \n's added to split them into shorter strings.
Thanks for your ideas which helped me crystallize my code... -
Instead of assuming an average width of a character, we could also do it precisely without having to change the code sent earlier too much. Just create the 3Dtext for each line and word, get the width and then compare this with the BoxWidth. It takes now more time to calculate the word wrap.
boxwidth= 600 charheight = 100 result = "" word_array = 'To be or not to be-that is longwordwidest the question'.split(/\s/) line = word_array.shift word_array.each do |word| txt = line + " " + word group = Sketchup.active_model.entities.add_group group.entities.add_3d_text(txt, TextAlignLeft, "Arial Narrow",true, false, CharHeight, 0.0, 0, false, 0) txtwidth=group.bounds.width group.erase! group = Sketchup.active_model.entities.add_group group.entities.add_3d_text(word, TextAlignLeft, "Arial Narrow",true, false, charheight, 0.0, 0, false, 0) wordwidth=group.bounds.width group.erase! if txtwidth <= boxwidth line << " " + word elsif wordwidth > boxwidth result << line + "\n" unless line.empty? line = word else result << line + "\n" line = word end end result << line puts result
Advertisement