Convert DXF to SVG with normalized viewBox

[crane]

Good day, community,
I am encountering an issue related to large values when converting a DXF file to an SVG format using the dwg2svg.bat tool.

In my input1.dxf file all values are in meters, but the unit is unset (None).

When I run the conversion with

Code: Select all

dwg2svg.bat -o "_out_g.svg" -g -f "input1.dxf"

, the output SVG file contains all elements, but the image is very tiny. The resulting _out_g.svg file starts like this

Code: Select all

<svg width="59.6102" height="63.7185" viewBox="148836.3471 -172593.4875 59.6102 63.7185" ...>

(Please take a look at the starting point of the viewBox)

When I specify the real unit explicitly by running

Code: Select all

dwg2svg.bat -o "_out_g_m.svg" -g -u m -f "input1.dxf"

the image becomes huge (as expected), but I have an issue with large x/y numbers for texts - they are not visible at all.
The _out_g_m.svg file starts with

Code: Select all

<svg width="59610.2445mm" height="63718.5mm" viewBox="148836347.1 -172593487.5 59610.2445 63718.5" ...">

And, one of the text elements looks like this:

Code: Select all

<text x="0" dx="0" y="0" dy="0.3" font-family="ARIAL.TTF" font-size="420" line-height="1.1" fill="#000000" transform="translate(148852681,172557294.3) translate(0,0.3) scale(1,-1)" text-anchor="start">Opp: 9.66 m²</text>

In "help"-section QCAD suggests me to use the scale-parameter to avoid large values and I did:

Code: Select all

dwg2svg.bat -o "_out_g_m_s.svg" -u m -g -s "1:200" -f "input1.dxf"

While this does scale the width and height, it doesn't seem to affect the viewBox, and the large x/y values remain unchanged, causing the text to remain invisible.

Code: Select all

<svg width="298.0512mm" height="318.5925mm" viewBox="148836347.1 -172593487.5 59610.2445 63718.5" ...>

Code: Select all

<text x="0" dx="0" y="0" dy="0.3" font-family="ARIAL.TTF" font-size="420" line-height="1.1" fill="#000000" transform="translate(148852681,172557294.3) translate(0,0.3) scale(1,-1)" text-anchor="start">Opp: 9.66 m²</text>

Having a correct unit and accurate numbers is highly important for me. It would be really awkward to use meter values as millimeters in the SVG.

Ideally, I would like to shift all coordinates by the number of the viewBox's starting point, and set the viewBox to start at simply 0 0. This way, the text’s transform would be more manageable -`translate(16333.9, 36193.2)...`, much better for me and, probably, for browsers.

Could anyone offer guidance on how to adjust the viewBox correctly if possible, or please suggest how to deal with it?

Windows 11, QCAD 3.31.1 pro

[CVH]

Hi,

Not a SVG specialist, I have to break this down in my own way.
For the second attempt you refer to the "help"-section of QCAD. Can you specify where?
In the 'Quick SVG Export' I read:
Exports the current drawing to an SVG file. While the SVG format is not ideal for storing CAD data, ...

DXF drawing: Unit = 'None' | Paper Unit = 'mm' | LL or Lower left corner (148836.3471, 172529.769) | Size = 59.61024451 wide by 63.7185 high.

To SVG as is:
- While LLx is a perfect match, LLy is not.
- LLy is negated because SVG origin is Top Left.
- Size is a perfect match.

Typically QCAD does not convert drawings from or to unit 'None' and the viewbox + sizes are 1:1 ... Except LLy to a minor degree then.

To SVG as meters: Converted to mm Why mm?
Default SVG unit is said to be pixels.
Perhaps because of the drawing paper unit.

Does size matter? ... SVG or 'Scalable Vector' means that the final displayed size doesn't really matter.
I have seen the same with QCAD action buttons icons. These SVG files may be huge while a button is typically 20-30 pixels.


Example Text entity: Text = "Opp: 9.66 m²" | Height = 0.3 | Position (148852.681, 172557.2943) | Alignment = Left Base
It seems that:
- The text is created at (0, 0.3), in SVG that is 0.3 down.
Reading from left to right then 'start' is Left or zero, Base is lower or down.
- Moved to (148852681, 172557294.3) in mm.
- Moved 0.3 up
- Mirrored over the X-axis because SVG origin is Top Left.

But what I fail to understand is font-size="420"
If that is seen as mm then it would be 40% too large because the text height is 0.3m or 300mm.


On scaled with a 1:200 factor:
Here is explained that width= and height= are the scaled representation of the viewBox.
The scaling is thus incorporated relative while all data remains the same ... 'Scalable'.


You are using the -g switch to preserve as much of the original geometry as possible.
Because there seems to be something with the multiple transformed text:
What does not using transformations for text entities with switch -no-text-transforms do for the output?


On: Normalized viewbox.
Would a translation to (0,0) not break with 'preserving as much of the original geometry as possible' ?
Or break with: "Having a correct unit and accurate numbers is highly important for me." ?


Side note (NL):
Ongeveer in de aangeduide richting en inderdaad op pakweg 228 km afstand ligt Beauvais (F).
Alleen begrijp ik niet waarom dat deze stad in Frankrijk overeen moet komen met de tekening oorsprong.

Regards,
CVH

[crane]

Hi CVH,

Thank you for the quick response.

For the second attempt you refer to the "help"-section of QCAD. Can you specify where?
In the 'Quick SVG Export' I read
I assume that 'Quick SVG Export' is a part of QCAD's GUI, but I am using dwg2svg.bat tool (as a part of automated DXF processing service).

If you run dwg2svg.bat -h in your terminal, you will get:

Code: Select all

...
Points:    If neither -c nor -x is given, points are not exported.
SVG Units: SVG only supports the following CAD units: mm, cm, in.
           - Unsupported Metric drawing units are converted to Millimeters.
           - Unsupported Imperial drawing units are converted to Inches.
           Use -s to scale and avoid large values.
Margins:   Margin values have to be specified in the (converted) SVG unit.

Examples:
Adjust page, set all margins to 1.5, export points as circles with radius 0.5:
dwg2svg.bat -a -e 1.5 -c 0.5 file.dwg

Set scale factor to '1:200':
dwg2svg.bat -s 1:200 file.dwg

As you mentioned, the size of the drawing is 59.61024451 wide by 63.7185 high. The problem is that these numbers are in Meters, but treated as millimeters.
I need the SVG file for rendering a drawing in a browser. If I convert as is, the width and the height properties of the SVG will be the same 59.61024451 by 63.7185. As far as SVG unit is always the millimeter, I have a confusion.
That's why while converting I'm mentioning the real unit - Meter, then QCAD adjusts width/height and the viewBox. And all good except Chrome browser fails to render texts.

I have tried -no-text-transforms, it moves coordinates from transform-prop to x/y props - yeah, looks better, but the text rendering issue is still there.

Regarding accurate numbers — I understand that preserving the original values without any changes is the most accurate form of conversion. However, what matters most to me is maintaining the same geometry: same size, same positioning, and overall layout consistency.
If QCAD can make texts browser-friendly without normalizing the viewBox, that's perfectly fine. If it shifts coordinates by the starting point to reduce large numbers and improve browser rendering of texts — that’s also fine.

Side note(NL):
Sorry, ik kan niet op je opmerking reageren omdat de tekening niet van mij is.

[CVH]

I assume that 'Quick SVG Export' is a part of QCAD's GUI, but I am using dwg2svg.bat tool (as a part of automated DXF processing service).

Internally the conversion to SVG relies on the same libraries.
dwg2svg.bat starts QCAD without GUI and executes the script file: scripts\Pro\Tools\Dwg2Svg\Dwg2Svg.js.
Depending the -g switch that initiates a SvgExporter or SvgExporterPG exporter.
Nothing really different than when using the GUI commands.

If you run dwg2svg.bat -h in your terminal, you will get:

I have always struggled with running QCAD Command Line Tools (Win7 32bit, Windows UAC, Windows Defender, ....)
But I manage that now when required for replicating an issue.

Why converted to mm is solved.
As stated only 'mm', 'cm' and 'in' are supported. (Found this page on SVG units)
And all unsupported metric drawing units are converted to 'mm'.
Accurate numbers is not the issue, "Having a correct unit" is not supported for SVG.

Seemingly: -u cm , -u "cm" , -unit=cm or -unit="cm" is not accepted.
(Assumed to scale things up when 'None' is treated as screen units = pixels)

• Warning: Drawing unit 'cm' is not supported by SVG. SVG unit is set to 'mm'.

Specifying mm is accepted and produces a larger image at the client side.
From the above link: 1mm ≅ 3.7795px or user units.
About 3.5 and less than 4 times larger seems to match with what I see on a Browser page.

'None' >> 17mm / 25.4 * 92DPI = 61.6px and 18mm / 25.4 * 92DPI = 65.2px roughly equates to 59.6102 by 63.7185 unnamed units.
The match is even better using 'mm' because of the measurement taken on screen (+/-1mm).


Starting to think that the catch is at the client side.
An image that is about 60m wide would required 60k mm times 3.78 pixels/mm or over 200k pixels to display.
That is an extremely wide display.
Just thinking out loud based on the resulting images on screen.

To confirm that I ran the conversion with: dwg2svg.bat -o "_out_4mm.svg" -g -s 4 -u mm -f "input1.dxf"
Expected to fill my Browser page or nearly 1000px high and thus confirmed, and with visible text.

_out_4mm.svg

(129.3 KiB) Downloaded 383 times

Note that the text of Block '$LEGENDRCT' and '$TITLE_BLOCK' are missing.

What I fail to understand is again font-size="0.42"
A factor 1000 I can understand but where is the scale factor 4 in this equation.
Nonetheless the text seems to be sized OK on a Browser page for several scaled tests.

+40% is probably explained by QCAD height = height of capital 'A' vs SVG height is that of the lower case.
What we can read in the above link about 'Font-Relative' doesn't explain much or is not very promising.

With -s 1000 I get a picture that is also 59610.2445 by 63718.5mm but then WITH visible text.
And yes, this is off-course huge and if it was supported then it would produce the same in 'meters'.

I presume that it must be possible to display that scaled in a parent frame or so?

Scaled UP and font-size="0.42" always looks good.
There might be a bug to report for the export with font-size="420", for unit 'cm' and Block text.

Regards,
CVH

[crane]

Seemingly: -u cm , -u "cm" , -unit=cm or -unit="cm" is not accepted.
(Assumed to scale things up when 'None' is treated as screen units = pixels)
Warning: Drawing unit 'cm' is not supported by SVG. SVG unit is set to 'mm'.

SVG in 'mm' is fine. At the same time, specifying in my case "-u m" is important for my web app to calculate, for example, width between walls (selected by user).

Starting to think that the catch is at the client side.
An image that is about 60m wide would required 60k mm times 3.78 pixels/mm or over 200k pixels to display.
That is an extremely wide display.

60k display is not necessary, in a web-page it is rendered inside of a reasonable size container with "width: 100%; height: 100%" styles, so the drawing auto-scales down to the size of the container. But even when the drawing is "downscaled" it still must have correct numbers in width and height, so I can calculate distances or areas (of custom polygons).

I presume that it must be possible to display that scaled in a parent frame or so?

Exactly

With -s 1000 I get a picture that is also 59610.2445 by 63718.5mm but then WITH visible text.
And yes, this is off-course huge and if it was supported then it would produce the same in 'meters'.

Looks like a quick and easy solution, thank you! Width & height are fine, texts are visible. The only theoretical issue is precision (for my web app calculations) because of viewBox's end point "59.6102 63.7185". But I hope I can fix it with "-decimals=7" for my input1.dxf file.

For Plan B, I'm still considering normalizing the viewbox with shifting all the coordinates in the custom export-functions of SvgExporterPG.

[CVH]

Hi,

In construction related we typically use cm.
7 decimal digits for values in meters would be an unrealistic precision of 0.1µm.
No wall or other construction detail is that precise.

specifying in my case "-u m" is important for my web app to calculate, for example, width between walls

Meters is simply not supported by SVG.
While specifying cm fails your best option is mm otherwise Drawing Unit 'None' is treated as pixels.
The given unit is used to convert your drawing before export what fails for 'm' and displaying text in a Browser.
Then font-size="420" seems perfectly correct as 1000 times 0.3m +40%.

With: dwg2svg.bat -o "_out_1000mm.svg" -g -s 1000 -u mm -f "input1.dxf"
We get a viewBox in meters and a scaled canvas in mm.
Values are then in meters and things are displayed 1000 times larger.
Then font-size="0.42" also seems perfectly correct as 0.3m +40%.


I noted that the text of Block '$LEGENDRCT' and '$TITLE_BLOCK' were missing.
This is incorrect as these strings exists in the SVG but are not visible at first sight.

As example: text 'Lokaal categorie groep' of Block '$LEGENDRCT'
Text Height is 90 (drawing units) for a capital 'A', +40% would be 126.
The Block Reference is inserted at scale 0.01 => Text Height 0.9 or 1.26 for SVG.
Similar as the initial example the text is created at 90 down but not translated up because the alignment is Left Top.
The difference sits in the font-size: Not 90 or 126, instead the scaled font-size 1.26 is used.
Translated (148874.4176,172563.4261) to counteract the huge internal Block offset at scale 0.01 and Y is negated.

The real issue is that this SVG text item is scaled again in a group transformation making it 100 times smaller.

Code: Select all

            <!-- Text: Lokaal categorie groep -->
            <g transform="scale(0.01,0.01)">
                <text x="0" dx="0" y="0" dy="90" font-family="ARIAL.TTF" font-size="1.26" line-height="1.1" fill="#ff0000" transform="translate(148874.4176,172563.4261) scale(1,-1)" text-anchor="start">Lokaal categorie groep</text>
            </g>

There are other issues with this '1000mm' export.
Of Block Reference '$LEGENDRCT' I can only see the Hatches and the Polylines around them.
And of '$TITLE_BLOCK' I can only see the outer Polyline.
Text in these two Blocks is treated differently, only those in '$TITLE_BLOCK' are visible but too small.
Investigation is pending.


The drawing itself has issues too:
- The content of Block '$LEGENDRCT' is defined extremely far from the Block origin.
- The outer polyline of the building exists twice, one on layer '090_BOUWLAAGOPPER' and one on '10_TOTALE_VERDIEPINGSOPPER'.
- Besides 26 empty text in Model_Space there are also 26 Zero-length line segments on layer 'LOCCARD'.
Typically at the insertion point of a reference to Block '$LCANCHOR'.

Regards,
CVH

[CVH]

Update:
Failing for an alternative unit 'cm' is traced back to a typo, see Bug Report FS#2659

Other investigations still pending.
I can already have the correct sized and positioned text for Block '$TITLE_BLOCK' with not applying the scale twice ... Manually Edit.

Regards,
CVH

[CVH]

Update:

With some manual tweaking I got a corrected output.
Nevertheless a large representation because we are limited to 'mm'.

Inkscape view at 1% = minimum

_out_1000mm_rev2.png (148.6 KiB) Viewed 21195 times

Not opting for switch -no-text-transforms it seems that text from scaled Block content is scaled twice.

In revision 1 I counteracted the font-size scaling and positioning in absolute for text items of the Block '$TITLE_BLOCK'.
The scaling is also applied for a group per entity.
Clearing only this had not the required result because the 'translate' values were also scaled.

I then applied the same method on the text items of Block '$LEGENDRCT'.
A quick fix with loosing 2 decimal digits for the 'translate' values.
At least all text is now visible and positioned (almost) correct inside the viewBox.

_out_1000mm_rev2.svg

Proof of concept

(129.25 KiB) Downloaded 349 times

With this knowledge it is perhaps possible to understand what fails for an export using unit 'm':
dwg2svg.bat -o "_out_g_m.svg" -g -u m -f "input1.dxf"
But it might simply be the font size that is too large to render at the client side.

Regards,
CVH