2D export to SVG

deerwood

Dear all, especially thomthom and Anssi,

thanks a lot for your tips. Now I actually can generate SVG from SketchUp 7 free using only open source GPL tools! See attached ZIP with SVG file (I'm not allowed to upload SVG files directly). The SVG itself should be directly viewable in Safari, Firefox and Opera, in the latter two you also can zoom into the picture and see, that there is no quality loss, because it is really vector format.

I installed the PDFCreator printer driver and printed from within SU to a PDF file with the mentioned "Use high accuracy HLR" checked. This option is indeed available in the free SU 7 (and also documented to be available there). The PDF already looked very good and was zoomable to any extent without quality loss.

Then I startet InkScape and just imported the PDF, which took a second or so. I saved in InkScape SVG (plain SVG is possible too). And voila!

Note that this just was a quick check. The SVG file contains a lot of clippath elements, that I believe might not really be neccessary and blow the file size up much more as the few lines are worth it. But then I just worked with all default settings. I'll try and see if I can get rid of unneccessary clip pathes.

How nice! Thanks again, best regards, deerwood

Four matches as SVG

deerwood

Dear all,

I investigated a little bit further into that clippath thing. With the help of Inkscape and my text editor (yes, SVG actually is XML, so you can work on it with text tools including scripts ) I removed all these clippathes and their references, which turned the SVG filesize down from 180 KB to 18 KB. The file still is valid SVG ... but I lost all face coloring and was left with just the edges. See attachement.

So it turned out, that it has to do with shading/coloring the faces and seems to be caused by the PDF printing/export already and not beeing the fault of the InkScape import.

To shade/color a face a colored rectangle covering the 2D bounding box of the face in question is given out. As that opaque rectangle is much too big and would either cover other parts of the drawing or show up in the wrong places that rectangle then is clipped ... leading to overly complicated clipping pathes.

In plain SVG one instead just would define filled polygons exactly covering the visible face parts (in Z-Order behind the related edges of the face). I believe, this would reduce SVG file size essentially compared to the clipping way. And filled polygons are available in PostScript too and thus in EPS/PDF.

Please note, I am not complaining here in any way, just reporting what I've found, so others are aware of it.

What I'm not sure about is: is that strange way coloring faces is the way SketchUp works, maybe only when printing? Or is that caused by the used PDFCreator printer driver?

If you want to do me a favour, can someone with the SU 7 PRO version please be so kind and directly export the "four_matches.skp" (found in an earlier post) to PDF and hand it over to me? Thanks in advance. I'll then report here the results of my further exploration.

Remember, one of my main reasons for having SVG out of SU is supporting wikipedia commons (respecively open a way for others to better support commons) and they ask for SVG not only because of it's scalability, but also for SVG typically beeing much less in file size than pixel formats (for diagrams and schematic drawings, photos etc. still are better off in JPG).

Again, thanks a lot, this is such a friendly and helpful forum, I'm happy to have found it.

Best regards, deerwood

four_matches_clean.zip

thomthom

I've attached a .zip with two pdfs. One is from SU's export function, and one is made using Adobe's PDF printer.

(p.s. You added the .skb, not the .skp file... )

matches.zip

thomthom

Just for kicks, here's an EPS, printed with a HP DesignJET PS driver.

epsprint.zip

deerwood

Dear thomthom,

thanks a lot for your support.

@thomthom said:

I've attached a .zip with two pdfs. One is from SU's export function, and one is made using Adobe's PDF printer.

(p.s. You added the .skb, not the .skp file... )

The SU Pro export (SUpdf.pdf inside your ZIP) is as perfect as it can be and produces a very nice SVG file, when imported into Inkscape, with all face shading and only ~22K filesize. All visible face parts are given out before/below the edges (in Z-order) as polygons, the polygon points are excactly in the corners of the 3D objects mapped to perspective 2D. After that follow all edge lines, partly overlapping the faces because of their thickness. This is almost identical to what a human would do, when drawing such a picture! See attachments.

Your exported PDF already shows that. It is almost uncompressed plain Postscript and can be inspected with text viewers. You'll see then essentially pathes constructed from MOVE_TO X,Y and LINE_TO X,Y. Inkscape just translates that into SVG syntax without hassles.

So the good news is: users of the SU 7 PRO version can generate nearly optimal SVG files easily.

The given "AdobePDF.pdf" obviously is in pixel format (I counted/estimated them: ~400 pixels or so not beeing white , PDF file size ~9KB). Maybe you didn't check that "Use high accuracy HLR" in the SU initial print dialog? Also, if you still wannna help, would you please check "Fit to page" and "Use model extents" in your print dialog? The EPS file you gave looks to me as pixel format too. I was not able to import it as vectors into Inkscape (though I had to pipe it through GhostScript 8.63 for conversion from EPS to PDF).

Oops/sorry for that SKB (what is that anyway)? You could open it?

Thanks a lot,
at least there is good news for PRO users,
best regards,
Georg aka deerwood

SUpdf.svg zipped

This time the SKP

thomthom

@deerwood said:

The given "AdobePDF.pdf" obviously is in pixel format (I counted/estimated them: ~400 pixels or so not beeing white , PDF file size ~9KB). Maybe you didn't check that "Use high accuracy HLR" in the SU initial print dialog? Also, if you still wannna help, would you please check "Fit to page" and "Use model extents" in your print dialog? The EPS file you gave looks to me as pixel format too. I was not able to import it as vectors into Inkscape (though I had to pipe it through GhostScript 8.63 for conversion from EPS to PDF).

Ah, yea, I didn't check the printer settings when I printed. I'll upload a new version when I get into work.

@deerwood said:

Oops/sorry for that SKB (what is that anyway)? You could open it?

Yea. No worries. It's the backup file Sketchup creates. Just had to rename to to .skp.

Anssi

I must definitely take a look at Inkscape. At work I can use Illustrator to open PDF files as editable graphics but I cannot justify buying that just to play with at home.

Thanks Deerwood for starting this discussion

Anssi

thomthom

Oops! Forgot to do them files again. Sorry. Trying again tomorrow.

deerwood

Hi all,

just to let you know: the overly complicated clippathes ain't neccessary at all, but either produced by intention or by some really stupid piece of code (maybe in some library). See this image (screenshot from Inkscape, clippath turned into a normal path, path edit tool active, so that the knots show up):

Clippath of a face that could be done with just 4 knots

Note the almost clean path at the lower edge.

When we further zoom in (here the former clippath is given a red outline and moved to the very front), the whole mess of unneccessary knots will be visible more clearly:

Zoomed in

Zoomed in even more

I checked: the extra knots are already present in the PDF file, so it is definitely not Inkscapes fault. And I cross checked with a Postscript printer driver (HP2500 PS3) ... the generated Postscript was very different from the PDFCreator/Ghostscript one (different headers and thus different printing instructions). But the madness with these excess knots was identical.

So I'm pretty sure now, that the strange code leading to the excess knots is not located in the printer drivers. Instead it must be the way SU 7 free paints to the printer device context/driver. It would be most interesting, if the SU 7 PRO version produces similar results when printing, because we know, it can do much better when exporting. If PRO also shows this strange behaviour, I would want to add a feature request to do that better or even report it as bug, because also the PDF files are unneccessarily large.

If PRO behaves better when printing, then, sigh, SU 7 free users have to live with that as it is, which would be a pitty.

One could, in simple models like this sample SVG, go and manually modify the SVG with Inkscape, e.g. by

unclip the face shading object, which leaves you with the BB rectangle in the right color and that ridiculous path
delete that path, but remember the face it was meant for
edit the left over rectangle with the path tool and move the corner nodes to the correct positions, when neccessary removing 1 knot (for triangle face fragments) or adding more knots (for faces with more than 4 corners). Remember to enable a good snapping behaviour in the document settings.

But then, this is really only for the "very poor man" and for simple models. So that e.g. the occasional supporter of wikipedia commons is aware of the issues, but not totally lost (and this thread will show up on Google searches, thus I must warn/hint, to keep commons free from really bad SVG files).

Finally I hope, that Google will be really aware of SVG beeing/becoming THE new web standard for vector oriented 2D graphics and sponsors/supports it much more (they already sponsored Inkscape development in a summer of code). Though MS obviously ignores SVG as a WEB standard in IE, almost all other important browsers support it. And beating MS is one of Google's current goals, isn't it ?

Best regards, deerwood

thomthom

Here's new files, pdf and eps printed with "Use high accuracy HLR".

@deerwood said:

Finally I hope, that Google will be really aware of SVG beeing/becoming THE new web standard for vector oriented 2D graphics and sponsors/supports it much more (they already sponsored Inkscape development in a summer of code). Though MS obviously ignores SVG as a WEB standard in IE, almost all other important browsers support it. And beating MS is one of Google's current goals, isn't it ?

SVG is based on the VML specs MS submitted to the W3C. I suppose MS hopes W3C would accept it with no changes. Google maps uses SVG for all browsers with exception for IE where it serves VML.

su.zip

deerwood

Dear thomthom,

thanks a lot for still helping. I could only start to analyze the Adobe Distiller generated PDF, because the SVG generated out of that is EXTREMLY different from both, the (nearly optimal) SU PRO Export and the (ugly) results I got so far. With regard to the SVG filesize it is somewhere between both extremes (22K < 54K < 183K).

But it also produces, in principle, a similar result with regard to the shaded areas. It also uses these bounding box shading rectangles and clips them afterwards and the clip pathes used have many excess knots along the edges ... although much less than the PDFCreator produced ones.

And finally the distiller produces extremly nested SVG (I still assume, that Inkscape follows the PDF/Postscript instructions 1:1 just translating to SVG). It begins with clipping twice and continues by grouping simple pathes extremly deep, just to apply transformations, like so:


<g transform="translate(364.68,319.34)" ...
  <path d="M 0,0 L 84.96,-32.16" />
  <g transform="..."
    <path d="M 0,0 L -244.02,85.56" />
    <g transform="..."
      <path d="M 0,0 L 100.32,-72.48" />
      <g transform="..."
        <path d="M 0,0 L -96.9,69.06" />
        <g
          ... 15 levels more
    ...
  </g>
</g>

which makes editing and analysis of the SVG extremly difficult.

I also gave the SVGMaker printer driver a try with even different results. This one isn't really better, but it does not use clipping, instead it uses shaded pathes for the faces ... but these pathes have even more excess knots. That front face from my last post (with 209 knots) has more than 2000 knots in SVGMaker!!! All along the edges, but distibuted much more evenly.

My first conclusions to all these observations are:

I no longer assume, that SU Free does bad output on print, especially not by intention.
I assume SU uses, what a device driver announces to be capable of and just uses that. Leaving the rendering details to the driver. E.g. for the face shading, SU tells the driver: fill me that area, with this color, starting from this coordinate (like a paint bucket). Essentially the same, as if painting to the screen.
The driver has to figure out, how to best follow these instructions, having no high level context anymore. One is doing better, the other worse.
Thus that mentioned "stupid piece of code" is located inside the drivers.
Though this is speculation already.

Best regards, deerwood

deerwood

Dear all,

you for sure would not believe, what I tried in the meantime, to get clean SVG out of SU7 FREE. Call me beeing stupid.

All attempts, getting clean SVG out of FREE, including using an EMF (Enhanced Meta File) printer drivers, failed in some or the other way.

My last resort was to ask Google for a PDF export even in the FREE version. Just sent, if they answer, I'll report.

Best regards, deerwood