[Plugin] importDXFtext
-
Hi TIG
SketchUUp Ext. manger showed 3.2 after install. But I did not see the
line with**cp =**gents.add... in the code file.Agree, the fix is to be applied about 10 lines further up than what is reported in the console.
I think I also had crashes in Sketchup when working with mm.
Cool, you could find a work around!Downloaded and installed version 3.3. So far all good.
Will test later today and let you know. -
out of curiosity, not saying it is wrong or I would know why
Yesterday evening, for testing, I did the same change for make_atext as it stands in make_mtext and then it worked.For ***make_text ***and make_mtext you assigned the variable cp:
if string.tr(' ','').gsub(/\\P/,'')=="" string="" ***cp = gents.add_cpoint(ORIGIN)*** puts "Empty String = Cpoint" next #height=100.mm end#if ### bold=false;italic=false ### begin ### gents.add_3d_text(string,align,font,bold,italic,height,0.0,0.0,true,thick) if string && string !="" rescue Exception => ex puts ex ensure ### ? end next unless gp.valid? ***cp.erase! if cp && cp.valid?*** # we don't need a cpt inside text??
But for make_atext, you commented out the line causing errors:
if string.tr(' ','').gsub(/\\P/,'')=="" string="" ***gents.add_cpoint(ORIGIN)*** puts "Empty String = Cpoint" next end#if string=string.strip.gsub(/\\P/,"\n")### replace \P with \n ### bold=false;italic=false ### begin gents.add_3d_text(string,align,font,bold,italic,height,0.0,0.0,true,thick) if string && string !="" rescue Exception => ex puts ex ensure ### ? end next unless gp.valid? ***#cp.erase! if cp && cp.valid?*** # we don't need a cpt inside text??
-
It's possible to have an empty text string in ACAD Mtext etc, to trap for it I add a cpoint into the group containing the possible text - to ensure the group isn't prematurely deleted as there's no geometry made - at the end that cpoint is deleted to tidy up.
As it isn't needed in the Atxt, putting the # in front of the relevant line fixes the error message.The unrelated splat with tiny text from Atxt when using model-mm is trapped by forcing inches for Atxt height when import units are set to mm/cm...
-
Ok, Clear, makes sense.
I tested and it turns out, that AText is by a factor of 39 too small (100/2.54).
So if I have a MText or Text at position (x,y,z) = (100mm, 100mm, 0mm) then the MText is imported into SketchUp at the right position, but the AText being at the same position in DXF, ends up in SketchUp at (2.54mm,2.54mm,0mm).
Also the height of the Text is much smaller.I imported indicating units = meter.
Probably this is the reason why if choosing MilliMeter for import, it crashes, because a few mm divided by 39 is giving a too small text size.
-
So what is the outcome of this ?
Previously, for any type of ACAD text, you could specify a unit mm/cm/m/'/" and a matching factor was applied to the DXF's height/spacing etc [assuming it is initially stored in "].
In the newest version that adjustment still applies to Text & Mtext, but for Atext, where the text-height is often ~0.01", sometimes giving very tiny edges in the flat 3d-text characters, so I forced it to check if the unit is set to mm/cm, and if so it uses the DXF's " values instead...
So how should we fix this ? Forgetting the details of the coding itself... what do we need to check and change/keep... e.g. if it's Atext do we increase the height by x39 ? and them reduce if by the unit-factor ??
-
I checked again with version 3.2 (where I fixed the variable error by setting "cp = gents.add?...")
using units = meters: All works as expected. The MTexts, Texts and ATexts are all at the correct position and size in SketchUp.As soon as I import with "unites = mm" (which I think is not correct for this drawing), SketchUp crashes. So nothing new.
Somehow I think the Plugin works fine, just that it causes a crash, if units are choosen too small (user error).
Could we not define, that objects are not imported, if the resulting 3D text height is below a limit?
(I assume it is the too small 3D text size which brings Sketchup 2021 and 2022 to a crash)In the console or a dialog box, the number of skipped texts could be reported at the end of the import process.
I created in SketchUp a 3D text using the standard menu option:
The height of a 3D Text must be equal or bigger than 0.0254 mm(1/1000 inch). If you enter a smaller value, SketchUp gives an error message, saying the length entered is too small. (Probably Sketchup Team had these crashes as well and now there is a data entry validation) -
Here's v3.4
https://sketchucation.com/pluginstore?pln=importDXFtext
I've adjusted the code so that it partially reads the DXF file header before your choose the Units.
The resulting default in dialog should usually be accepted.
Now you cannot choose units less than the DXF's - which are often in inches - and if you try you are blocked.
However, you can choose units that are bigger, BUT you are warned about the discrepency Y|N... -
Thanks.
Tested version 3.4, with the same dxf file as before: unfortunatelyI do not even get the unit dialog:
Error: #<TypeError: wrong argument type nil (expected Array)>
C:/Program Files/SketchUp/SketchUp 2022/Tools/sketchup.rb:121:**ininputbox'** C:/Program Files/SketchUp/SketchUp 2022/Tools/sketchup.rb:121:in
inputbox'
C:/Users/Birgit/AppData/Roaming/SketchUp/SketchUp 2022/SketchUp/Plugins/importDXFtext/importDXFtext_code.rb:99:inget_units' C:/Users/Birgit/AppData/Roaming/SketchUp/SketchUp 2022/SketchUp/Plugins/importDXFtext/importDXFtext_code.rb:1880:in
new'
C:/Users/Birgit/AppData/Roaming/SketchUp/SketchUp 2022/SketchUp/Plugins/importDXFtext/importDXFtext_code.rb:1894:in `block in module:ImportDXFtext' -
Aaargh !
I'll republish the version asap... -
Here's v3.4 again
https://sketchucation.com/pluginstore?pln=importDXFtext
I think I've fixed the typo ?? -
Thanks a lot.
Still the same at the beginning.
Can it be, that the units list returned from the DXF is empty in certain cases?
After I tried with another dxf it worked. And from then on, the first dxf file also worked.Seems to me as if the array is not always initialized.
Other point: I have another dxf which the plugin now identifies being "inch". But this is not the correct unit. It must be meter. Are there multiple units in the file where you can look which unit is the right?
Error: #<TypeError: wrong argument type nil (expected Array)>
C:/Program Files/SketchUp/SketchUp 2021/Tools/sketchup.rb:121:ininputbox' C:/Program Files/SketchUp/SketchUp 2021/Tools/sketchup.rb:121:in
inputbox'
C:/Users/Birgit/AppData/Roaming/SketchUp/SketchUp 2021/SketchUp/Plugins/importDXFtext/importDXFtext_code.rb:99:inget_units' C:/Users/Birgit/AppData/Roaming/SketchUp/SketchUp 2021/SketchUp/Plugins/importDXFtext/importDXFtext_code.rb:1880:in
new'
C:/Users/Birgit/AppData/Roaming/SketchUp/SketchUp 2021/SketchUp/Plugins/importDXFtext/importDXFtext_code.rb:1894:in `block in module:ImportDXFtext' -
I've tried v3.4 with your very DXF and it works just fine !
Are you installing all of the contents from the RBZ and restarting SketchUp ?
I'll look at forcing the array better - since if seems to partially work !
Watch for a new update...A DXF has one header section - it tells us whether it's English or Metric, and then what the units are, so if it says it's 'inches' it is !
Look for $MEASUREMENT - 2 lines below - there are two choices - 0 is English, 1 is metric
Look for $INSUNITS - 2 lines below - various entries mean different units - e.g. 0=unitless, 1=inches, 2=feet, 3=miles, 4=mm, 5=cm, 6=m, 7=km -
Here's v3.4 again
https://sketchucation.com/pluginstore?pln=importDXFtext
I think I've fixed the array issues ??? -
yes, installed via extension manager and restarted SketchUp.
For the file block.dxf, which shows inch, but in fact should be meter, the entries are:
$MEASUREMENT
70
0
9
...
$INSUNITS
70
1
9for the dxf which causes a crash if loaded as the first file after opening SketchUp, I find:
$MEASUREMENT
70
0
0
...
But there is NO $INSUNITS in this file!What I find is a code without the $ sign:
INSUNITS
350
4CE6
3In a third file, which also works, I have:
$MEASUREMENT
70
0
9
...
$INSUNITS
70
6
9all files have as well Codes called $LUNITS and $AUNITS
$LUNITS
70
2
9
...
$AUNITS
70
0
9Hope this helps finding the cause for error message.
-
@tig said:
Here's v3.4 again
I think I've fixed the array issues ???Now it does not crash anymore when loading the file and I get:
The list of units is set to mm as a default:
when pressing ok, I get this warning:
When changing the units to something different than mm, I get:
Seems like the units found in the DXF file are "empty": []
With another file lke the block.dxf, I get as the default unit [inches]
-
I think I've trapped it...
The $ codes go in the header
$AUNITS sets units for angles.
$LUNITS sets units for coordinates.Out of curiosity, in the DXF file without the $ in front of INSUNITS is there a section below it starting 70 with a units code number in the line after that ?
If it's missing, it defaults to "/mm depending on the $MEASUREMENTS section... which I tried to fix in the array mess earlier...
The $INSUNITS [if it exists] itself seems to be linked to ACAD design-center blocks units - this seems to overwrite the $MEASUREMENTS section which itself sets English/Metric ["/mm]
Here's the updated version again !
-
After the INSUNITS without the $ in front, there is (it is almost at the end of the file (200 lines before EOF)):
INSUNITS
350
4CE6
3
LAYOUTDICT
350
4CE3
3
LWETCUNION
350
4CE5
3
PLOTSETDICT
350
4CE4
3
PSVPSCALE
350
4CEB
3
PUCSBASE
....with the previous version the behaviour was:
If I import the "no unit" file a second time, then the default unit is simply the one with which I imported the file before. Meaning the default unit is not initialized each time a file is chosen.now with the last version, it seems that the "no unit" file defaults to unit Inches.
If I import the file with meters, the warning says the default is inches and the import runs.
If I then import the same file again, the default unit correctly displays again inches and not meter, like before.Nice, thanks a lot.
-
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... -
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. -
Let me know... I can only say 'no'...
Advertisement