QCAD

Patch to fix scaled PG SVG text export: Text Alignment and Text Size.

$ patch -p0 < PG-TextAlignSize.patch

In the latest development version, scaling has been implemented by adjusting the width / height attributes of the SVG root tag.

I do not know the exact specifics of what your are doing. But if you just export 1:1 and let the SVG viewer do the scaling, this will lead to very very faint lines in the viewer, because *everything* will be scaled the *same*.

Yes, we thought about that. Line weights are not scaled (respectively scaled inversely). That's the same behavior as for printing and PDF output.

The reasoning behind this is that the coordinates in the output file are important for some use cases, so scaling the coordinates is not a good option.
If the user would want scaled coordinates, he would have to scale his drawing using Modify - Scale.

So, why a scale factor in svg export at all? It will be mostly useless then, except for drawings of objects about the size of the screen or the paper. Possibly, its just a convenience anyways, just click the "svg" button with defaults already adjusted or choose a value from a dropdown, Very convenient. Instead of : Scale with "s-z", enter a value, adjust dimensions sizes in "drawing preferences", only then export.

If you care about coordinates, export 1:1 and set the width and height of the svg to 100% instead of some pyhsical distance and only the viewport to the real extensions. Then the viewer will adjust the drawing to fit on the screen/paper/frame, with very often, very faint lines (if drawing a 30m tall building and 0.25 stroke, about 1/4/100 mm thin), of course...

I would prefer real scaling in the exporter - the work is already done. Real coordinates and fit to screen/paper at the same time can be achieved nevertheless, very cheaply.

So, why a scale factor in svg export at all?

Our use case for scaling is as follows:
- We use SVG drawings for the figures in our publications (e.g. our QCAD book / e-book). Each SVG figure is displayed at a fixed size, for example 60mm x 40mm. This size corresponds to the width / height attributes of the SVG root tag.
- Through the scale factor of the SVG exporter, we can control that size and for example publish a 6m x 4m drawing as 60mm x 40mm figure in the book.

The coordinates are crucial for any further processing / analysis of the SVG file (some users even use SVG as bridge to computer controlled machines).
If the coordinates are affected by scaling, the original geometry / accuracy of the entities is essentially lost.

Can you please explain in more detail what the down side is if scaling is done through width / height attributes for your use case?

My use case is exactly the same as yours: I want to publish drawings on paper and on screen. I consider the SVG exporters a best effort kind of tool - a trade off in visual appearance, accuracy, editability, filesize etc. It will only ever be /so/ close to the CAD drawing. I want to use SVG on screen, and I use apache fop/batik to process SVG into png - as an alternative for screen - and pdf for paper.

When QCAD exports always 1:1, and only sets width and height of the SVG root element, to let the svg viewer/renderer do the scaling, this will badly affect the stroke widths of the paths. Sadly "vector-effect 'non-scaling-stroke'" (see http://www.w3.org/TR/2004/WD-SVG12-20041027/vectoreffects.html) is not at all widely implemented (only on the iphone, afaik).

As my drawings are larger than the paper (which is very common with CAD, I suppose), lines become unacceptably faint eg. exported 1:20. The SVG then is no longer the representation of a CAD drawing, where stroke widths carry certain meaning and are limited to certain weights. In such a scaled drawing, one has to calculate /real/ coordinates by dividing by the scale factor though and correcting for units. Just like in your example, that uses a scale of 1:100 for the book. You'd have to draw with a stroke of 25 to get a stroke of 0.25 in the book.

So this would lead, in the best effort way, and especially for convenience of the user, to do the scaling not in the viewer, but in the exporter, that will resize entities while preserving stroke-width, to make the SVG look almost indistinguishable from a CAD drawing.

As for the other use case: If SVG units shall be the same as CAD units, shouldn't this be exported without scale then? I can only guess as to why one wants to have a scale then nevertheless: and that is, because it will not fit on paper, not?

The workaround would be, to set width and height of the SVG root to "100%" instead of real units. Then the frame, into which the SVG is loaded will determine the pyhsical size of the drawing. If the frame is the exact size of the CAD drawing, this will result in no loss of original geometry. See http://www.w3.org/TR/SVG/coords.html

The only thing that is lost is the name of the unit. At the moment, I do not know how to preserve that. Can this be communicated outside of the file, or in a comment: "units = mm; bbox = 6000x4000", eg? As a convenience, the size of the frame would be added, even though it can be calulated from the viewbox.

I hope I am clear. Sorry for the long rant. I have only little to say, but I think, that the SVG exporter should produce something, that closely resembles a CAD drawing, even when using a scale, in a best effort way. I understand that scaling can be done in QCAD before exporting, and later undone, but the convenience of how its done in BETA is a feature to good to be abolished. SVG export in QCAD is best on the market I'd say and will justify the expense of buing it in itself.

QCAD Beta 2 has SVG Export with scaling based on width / height and stable line weight / line patterns. I would appreciate if you could try it and then let me know if / why that is not sufficient for your use case.

Eventually, we might have to provide even more options for SVG output to make these things configurable.

Andrew, I did now try SVG PG export with the new Beta2 and everything so far looks perfectly fine. I see that you now instead of shrinking entities bolden the strokes. One little remaining thing is taken care of with attached patch: dasharrays on strokes should now no longer be scaled, or they will become *very* large when exporting eg 1:20. The patch also makes it so, that gaps are doubled in size, because otherwise they are eaten by the round linecaps in SVG. Please notice that I changed the way the pattern string is created.

I reworked the patch, after noticing, that in vertical dimensions the text gets written horizontally:

- use half the stroke width to broaden gaps in dasharrays,
- use the commented code to rotate text on dimensions.

Seems to me that's rather a problem with the line weight then the gap width. Current code segment:

SvgExporterPG.prototype.writeStyleAttribute = function(additionalStyles) {
  ...
  // no pattern scaling 
  //p.scale(this.getPatternFactor());
  //p.scale(1 / this.scale);
  ...
  var len = Math.abs(p.getDashLengthAt(i));
  // divide length by 4
  len /= 4;
  ...
  // do the conversion
  len = this.convert(len);

Attachment shows exported dashed lines (PG export), QCAD compared with Inkscape, scale 1:20, line weights corrected manually.

SVG PG export is always 1:1, only display size is set in the file, all scaling is done in the viewer - possibly line widths are out of proportion because the PG exporter delegates setting the width to the pure SVG exporter, which does not know about that. Below snippet produces acceptable results, 1:1 and 1:N, except for lines width 0.7, where the dummy "pf" attribute shows a strange value:

    // ...
    if (!continuous) {
        p.scale(this.getPatternFactor());
        var num = p.getNumDashes();
        var str = [];
        for ( var i = 0; i < num; ++i) {
            var len = Math.abs(p.getDashLengthAt(i));
            str.push(len);
        }
        additionalStyles += "stroke-dasharray:" + str.join(",");
        additionalStyles += ";pf:" + this.getPatternFactor();
    }
 
    this.scale = 1.0;
    SvgExporter.prototype.writeStyleAttribute.call(this, additionalStyles);

Please ignore above snippet, it produces incorrect results. I gave it another try; See attached patch. This time the result looks promising. Thinking it through, I guess it does the right thing. Of course PG exported SVG will never have the fidelity of pure SVG export, eg. a dashed line may end in a gap instead of a dash.

ok, looks good to me, thanks!

To some degree, even the lines ending with a gap shortcoming can be fixed/reduced with the dash-offset thing, at least it looks fine in the LinesPG.dxf rendering and one of my scaled drawings:

        // does more harm than good?
// some elliptic arcs dont produce a length...
        if (isShape(this.shape) && isFinite(this.shape.getLength())) {
            var length = this.shape.getLength();
            if (isNaN(this.offset)) {
// negative value here!
                this.offset = -this.getPatternOffset(length, p);
            } else {
// when will that be used?
                var num = Math.ceil(this.offset / p.getPatternLength());
                this.offset -= num * p.getPatternLength();
            }
            additionalStyles += ";stroke-dashoffset:" + this.offset;
        }

Another episode in this long story, a suggestion worded as a patch, again with rotated dimensions rotated also in export PG, and still centered on their line. Thats what should work for me in production environment.

One more thought: Maybe scaling of line pattern needs to account the base unit, be it inches/meters/etc.

RUnit.convert(this.weight / 100.0 / this.scale, RS.Millimeter, this.svgUnit)