[dxf import] use 'mm' for default units and grid in the SVG document

[su_v]

Current DXF import assumes that the DXF file stores the coordinates/lengths in 'mm' (according to the information in the 'Help' tab of the import dialog).

It might be appropriate to set the document default units to 'mm' in the SVG document, and add a default grid using 'mm' as unit as well.

This would not change the scale of the imported objects because path data in the SVG file is always stored without units (i.e. in 'px' or SVG user units). It would however improve the user interface which then would use 'mm' as units for the rulers and show the same dimensions and (node) coordinates of the objects (in 'mm') as when opening the DXF file in a CAD application like for example QCad.

Most useful if automatic scaling to A4 is turned off on import.

[Alvin Penner (apenner)]

just a quick comment, not sure if the help instructions on this were sufficiently detailed. The default behaviour on import is to multiply all coordinates by the factor 90/25.4 to convert from mm to pixels at 90 dpi, so the imported result should hopefully be in pixels.

If you specify no automatic scaling, and use manual scale factor of 1, then this factor 90/25.4 will be applied to the coordinates.

[su_v (suv-lp)]

> If you specify no automatic scaling, and use manual scale factor of 1,
> then this factor 90/25.4 will be applied to the coordinates.

But still the rulers in 'mm' would be correct - they do not affect the size of the SVG paths (they use the same factor representing the 'px' units in 'mm', based on Inkscape's internal 90dpi).

Try it with the example files from bug #656899 (after resaving them in QCad):

1) open DXF file (automatic scaling off, scale factor 1)
2) change default units in 'Document Properties' to 'mm'
3) add a grid with 'mm' as units, x- and y-spacing 1.0, save as Inkscape SVG.
4) if you don't use a current development snapshot: reopen it making sure that it doesn't re-use an Inkscape window with an empty document (e.g. open it by double-clicking the file in the Explorer).

Now compare the dimensions and the node coordinates in the SVG file (which is displaying 'mm' in the rulers and the x/y, W/H fields in the select tool and node tool controls bar) to the coordinate origin and object position in QCad.

Attaching sample file (DXF imported with scale factor 1.0) and changed default units to 'mm' and new grid using 'mm': when opened in Inkscape the dimensions and grid correspond to how the file is displayed/scaled by default in QCad (using 'mm' as document units, too).

What's odd is that the SVG file resulting from the DXF import does not define 'height' and 'width' of the <svg> element in units but just says '100%'. This causes the SVG file to be not rendered at all (or with none of the objects visible) in other SVG renderers like Squiggle (Batik 1.7) or browsers like Firefox and Safari. As far as I understand, a viewBox attribute would be needed defining the size of '100%' in user units or an outer (HTML) element (like a <div>) defining its size when the SVG is embedded in webpage, but this might need further investigation.

[Alvin Penner (apenner)]

> dimensions and grid correspond to how the file is displayed/scaled by default in QCad
- cool, that is gratifying to see, I don't ever modify the default scale in Inkscape, so I had never attempted that

- with respect to the scaling of the <svg> element at 100%, that was done as an act of desperation because I could not come up with a better answer. The AutoCAD procedure for specifying the size of the document is so convoluted that I have never been able to figure it out, and in Inkscape ideally I would have preferred to read the existing size of the Inkscape document while importing the data, but I don't know how to do that from inside Python. There are Inkscape verbs for querying the size of objects but they are of no help as far as I can tell because they return only bounding boxes, not document size. So I was not able to come up with a meaningful definition of document size and used 100% only for lack of something better.

[su_v (suv-lp)]

> So I was not able to come up with a meaningful
> definition of document size and used 100% only
> for lack of something better.

Uneducated guess: maybe the DXF entities '$EXTMIN' and '$EXTMAX' could be used to set the document size (width/height attributes of the top-level <svg> element) if automatic scaling is off, either directly in mm (as do the default Inkscape templates e.g. for A4), or unitless (after applying the conversion from mm to Inkscape user units (px, based on 90dpi))? They seem to be used for absolute positioning anyway if the scale factor isn't 1.0 (but e.g. 10.0 or 100.0) - at least in some DXF files I found on my disk from earlier bug reports.

(Note: last time I had to deal with DXF and DWG files is years ago (I forgot what I used to know about the details) - this is just an guess after taking a quick look at the python script for dxf_input).

On the other hand you could set the size to the default A4 dimensions (in mm) explicitly - this seems to be how Inkscape (apparently unlike other SVG viewers) interprets the 100% of the width/height <svg> attributes anyway. Then the user can zoom to the drawing content and - if absolute distance to the coordinate system origin is not important - resize the page to the drawing content.

Ideally an offset between the coordinate origin and lower left corner of the page would be defined with a viewBox attribute, but the viewBox attribute is not yet fully supported by Inkscape (whereas widely used e.g. in SVG files from Openstreetmap or other GIS applications, afaiu).

The page size issue doesn't prevent from setting a metric unit (e.g. 'mm') for the default units though, nor for using it for the grid.

[Alvin Penner (apenner)]

yes, it is slowly coming back to me now...
- using $EXTMIN and $EXTMAX sounds like a good idea. I had used them for scaling purposes but had not considered them for the sizing of the <svg> element. I will take a look at that and try to do it.
- for some strange reason, QCad 2.1.3.2 does not use these variables, I mean it does not generate them on output, it uses something else like $PLIMMAX, but I think $EXTMIN is a good choice.

[su_v (suv-lp)]

The scale factor seems to do something odd: compare opening the attached document, using scale factor 1.0 and scale factor 10.0: the second one is far, far displaced from the origin in negative y-direction) - not really related to proportionally scaling the (miniscule) distance from the origin compared to scale factor 1.0 or how QCad displays the location of the file contents.

Doesn't seem to depend on '$EXTMIN' and '$EXTMAX' but related to the inverted coord system in the SVG file and how the scale factor is applied to the y-coordinates of the SVG path data and not to the coordinates as defined in the DXF source?

[su_v (suv-lp)]

- resave kin CQac
+ resave DXF file in QCad before opening in Inkscape

and use scale factor 1.0 and 2.0 for comparing ;)

[Alvin Penner (apenner)]

unfortunately, I am at a bit of a loss here. The format of the dxf file appears to be Release 12, so I cannot view it in Inkscape. When I load it into QCad 2.1.3.2 all I get is just 6 numbers, no contours, so it is somehow incompatible with QCad. When I load it into Voloview I can see the contours, but of course I cannot save it. So I cannot get this into Inkscape.

[su_v (suv-lp)]

What about this version? (opened in QCad, and immediately saved as DXF again)

[su_v (suv-lp)]

I'll try to find some more useful tests files...

[Alvin Penner (apenner)]

yes, this file is readable by both QCad and Inkscape. I gather that your QCad is slightly older than mine. Yours is dxflib 2.0.4.8 and mine is dxflib 2.1.2.0 in the dxf file.

This file displays quite reasonably if I use automatic scaling on import. The problem with automatic scaling is that one does not know what the scale factor is, so the file contains this factor as an svg:desc element which is:
C:\WINDOWS\Temp\topo-QCad.dxf - scale = 28.649385
When using automatic scaling, both the scale and the origin are specified using the EXTMIN and EXTMAX values.

If you use manual scaling then the origin will be far below the bottom of the page. Neither EXTMIN nor EXTMAX are used in this case. The reason was that I encountered some files previously that had outrageously large values for these parameters so I was not able to use them for manual scaling.

However, I think there may be a solution by allowing the choice of scale and the choice of origin to be two separate choices, not tied together as they currently are. In this case the origin is apparently chosen very well by the automatic scaling routine, but unfortunately one would like to specify the size scale manually (independently), in order to achieve proper engineering units, for example. So if I can solve the problem by making these into two separate choices, that would be fairly straightforward to implement.

[su_v (suv-lp)]

> for some strange reason, QCad 2.1.3.2 does not use these variables

QCad uses Paper space limits instead: see attached drawing - A1 Landscape with metric units. If Inkscape took those values (if present) it could set the page size accordingly, use 'mm' as default units and add a grid using 'mm' (with spacing '1mm').

IIRC correctly, AutoCAD knows 'Model space' (the drawing space similar to how we know it from Inkscape, but which can contain 2d and 3d data - $EXTMIN, $EXTMAX) and 'Paper space', like a plane or level/layer above the model space - always two-dimensional - where 'views' (aka View Ports) can be defined that act like windows to model space, each with a defined scale or extent or viewpoint for the part of the model space that is to be rendered within that window (view port). This allows easy layouting for plots (in paperspace, you define the paper size 1:1, add several view ports which can be resized and arranged as needed (e.g. floor plans, sections, details in a larger scale and a site plan, maybe a 3dview or perspective if the data in the model space is in 3d).

QCad on the other hand (at least the Community Edition 2.0.5.0 I'm using) seems to only know 'Paper space' - strictly 2d, one coordinate system (1:1), no drawing scale or other coordinate systems beside 'World'. CAD drawings can either be made 1:1 and the drawing scale defined at the time of printing (adds $PSVPSCALE), or use a drawing scale from the beginning to fit the contents inside the defined page size (QCad stores the paper size as limits, not as extents though: $PLIMMIN, $PLIMMAX).

[su_v (suv-lp)]

Retracting.