QCAD Bugtracker

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category QCAD (main)
  • Assigned To
    Andrew
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version Development
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: QCAD Bugtracker
Opened by Peter - 26.08.2011
Last edited by Andrew - 07.10.2011

FS#194 - SVG PG export scale text

Text scaling in PG SVG exporter is missing just two small additions: These attributes are not taken care of by now:

font-size, dy

Just use the current value times scale: eg 2.5 * 0.1 to have a scale of 1:10. Looks good here.

Closed by  Andrew
07.10.2011 11:49
Reason for closing:  Fixed
Additional comments about closing:  

Moved some things to  FS#300 

Peter commented on 27.08.2011 07:56

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

$ patch -p0 < PG-TextAlignSize.patch
Admin
Andrew commented on 13.09.2011 12:48

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

Peter commented on 13.09.2011 15:00

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*.

Admin
Andrew commented on 13.09.2011 16:24

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.

Peter commented on 13.09.2011 21:52

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.

Admin
Andrew commented on 14.09.2011 09:42
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?

Peter commented on 14.09.2011 12:34

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.

Admin
Andrew commented on 19.09.2011 21:16

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.

Peter commented on 26.09.2011 11:03

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.

Peter commented on 26.09.2011 12:40

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.

Anonymous Submitter commented on 29.09.2011 07:45

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.

Peter commented on 29.09.2011 19:04

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);
Peter commented on 30.09.2011 07:19

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.

Anonymous Submitter commented on 30.09.2011 07:28

ok, looks good to me, thanks!

Peter commented on 30.09.2011 08:31

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;
        }
Peter commented on 30.09.2011 10:06

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.

Peter commented on 01.10.2011 11:16

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)

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing