Can't get there from here: converting to other types

mathog · Postby **mathog** » Wed Dec 14, 2011 5:05 am

Here are some examples demonstrating just how hard it is to get a moderately complicated SVG drawing from Inkscape into another format - any other format.

The starting drawing is SVG. It seems to have a small bug all by itself, the fill on the open path in the lower left examplar of each set of four on the lower right of the image should be a straight line, but it has a notch in it. Otherwise it looks like I think it should look.

Now, can it be successfully sent to a PDF? There are some non 100% opacity sections, so anything that goes through postscript is going to have problems. It was printed three different ways to PDF (save_as, through Adobe PDF printer, through PDF creator printer.) View these in Acrobat and PDF-XChange viewer - none of the pdf's are perfect. The save_as is closest but there are extra red lines on the 3 arrows at the upper left. The ones that went through the postscript printer drivers are seriously messed up, and messed up exactly the same way for AdobePDF and PDFcreator, suggesting the problem is in Inkscape's conversion to Postscript. Among the issues: no rotated text. no filled paths, no lines with alternate end treatments, no gradients (expected due to the opacity issue - but not even the bounding shape made it through.)

Import the simpler PDF files into LibreOffice draw and things aren't too bad, just a stray rectangle or two. Import the "save as" PDF one and all hell breaks loose due to the gradients. Text at multiples of 90 degrees is OK, but text at 45 degrees is ripped to shreds (in no obvious pattern).

Save as to ODG, import into LO Draw, and many things look pretty good. But some basics are messed up: line widths are lost, fill is hit and miss on paths, opacity is lost (but the bounding shape remains), open paths are closed.

Save as EMF, reopen in Inkscape. Rotated text is all back at zero angle, opacity, gradients, and patterns are lost. Outlines are all retained. We already know that this EMF cannot be ungrouped in Powerpoint because it contains dotted lines.

Inkscape 0.48.2-1 on Windows XP
LibreOffice Draw 3.4.3 on Windows XP

mathog · Postby **mathog** » Wed Dec 14, 2011 5:16 am

More attachments...

Sorry, could not upload the ODG, even compressed it is beyond the attachment limit of 256 KB. Uploaded a screen capture of it loaded into LO Draw instead.

mathog · Postby **mathog** » Wed Dec 14, 2011 5:19 am

Ah, I see where that notch is coming from now. Unlinking the path created two paths, and the fill is on each. That is OK then.

mathog · Postby **mathog** » Wed Dec 14, 2011 7:23 am

Regarding the ODG file.

1. The fonts have been converted to paths. ODG supports fonts as fonts, such a conversion isn't needed.
2. LibreOffice does support open ended paths. Open the ODG in LOdraw, edit points on one of the "join/cap" examples, select the endpoints of the hypotenuse, "break path apart", remove the hypotenuse line. Save, reopen in LOdraw - path now has the same shape as in the original SVG. So inkscape must somehow be putting a "closed path" on the original path.
3. The point size of all lines is 0.0. LODraw can perfectly well save and restore line widths, Inkscape must be specifying these incorrectly.
4. LODraw has corner properties rounded, beveled, and mitered that correspond 1:1 to the Inkscape corner properties. However, LODraw does not have end of line properties, ends of lines are always square. LODraw sees all corners in the ODG file produced by Inkscape as "rounded". That is the default in LODraw - either inkscape isn't specifying it or is specifying "default" which on inkscape is not rounded.

Ah, 3.4.4 of LibreOffice is out, let's see if that changes anything....

mathog · Postby **mathog** » Wed Dec 14, 2011 9:48 am

Carefully removing all objects with opacity < 100%, pattern fill, or gradients lets the Inkscape -> PDF -> LODraw method work pretty well. However, for every object (including the tiniest line segment) that is missed there will be a page sized black rectangle in LODraw. In this example it turned out that earlier versions had opacity <100% for the converted dashes in the "separate paths" column, and also for the objects in the "no fill" column.

Even after eliminating those three object properties the following defects remain:

1. Text rotated by 90 degrees has some peculiar offsets.
2. Text rotated by an angle other than 90 degrees is mangled (see the red stuff in the upper right corner of the LODraw png)
3. All corners are rounded. This last can be repaired in LODraw by ungrouping everthing, selecting everything, then changing the line property from rounded to mitered.

Since none of these are apparent in the PDF, presumably they are all PDF import bugs in LODraw.

LODraw 3.4.4 wasn't different from 3.4.3

mathog · Postby **mathog** » Wed Dec 14, 2011 9:49 am

PDF import issues which seem to be LODraw problems have been reported here:

https://bugs.freedesktop.org/show_bug.cgi?id=43806

Postby **brynn** » Thu Dec 15, 2011 1:57 pm

Hi mathog,
I don't really have anything I can contribute to this topic. I find keeping up with other formats, which import, which export, which can be converted, which parts of an Inkscape drawing survive, which don't. It really is all VERY confusing, and most of the time, I leave these questions for more knowledgeable members to answer.

I think it would be helpful to have some kind of guide, like a chart or something. The problem with making something like that, is that it would have to be updated with every new version release.

I don't know what ~suv would have to say, as a developer. But she may have some comments for you?

mathog · Postby **mathog** » Fri Dec 16, 2011 9:28 am

The cause of the red lines on save as to PDF has been determined. If the straight line has a fill color set, even though that fill is not visible in Inkscape, it will be visible in the PDF after save as to PDF. Not clear to me what it means to "fill" a straight line, but whatever it is that Inkscape writes in this case, it shows up as a red line under the line segments in the PDF.

https://bugs.launchpad.net/inkscape/+bug/905032

mathog · Postby **mathog** » Fri Dec 23, 2011 3:13 am

Here are the problems trying to use SVG to move an inkscape drawing to LODraw. (Worry about moving from there to PPT if/when this first step works better.) When the SVG is in Inkscape format (a regular svg save from inside Inkscape) and LODraw opens it:

1. the geometric boundaries look about right
2. the line widths are all increased by 1.25
3. the arrow heads come off the corresponding lines and cluster in the upper left corner of the page
4. pattern fills and fills on open paths are lost
5. the text is lost

When the SVG is in plain svg format and LODraw opens it there is a general input/output error and no elements are imported. The error message depends on how it was opened . If it was with "Open with" the message shown here appears. Otherwise if it is from within LODraw with insert -> file there is a "The file could not be loaded!" message.

The "plain" svg renders fine with the browsers I tried. Odd that it is toxic for LODraw when the inkscape SVG is not.

mathog · Postby **mathog** » Fri Dec 23, 2011 3:27 am

SVG import problems for LODraw added to this existing bug report:

https://bugs.freedesktop.org/show_bug.cgi?id=37072

mathog · Postby **mathog** » Wed Jan 11, 2012 3:10 am

One more gotcha to add to the list - noninteger font sizes stored in PPT files are handled differently by LOImpress and PowerPoint itself. Here is one way to see this scenario:

Move a diagram Inkscape -> PDF -> LOdraw (copy) -> LOImpress (paste) -> save as PPT -> Open in PowerPoint.

After saving in .ppt format, and reopening in LOImpress, the font sizes named are the rounded off versions of the PPT, however, what is displayed is the original fractional font size, so the text stays within its bounding rectangle. Conversely, in PowerPoint, the fonts are named by the rounded off font size AND they are displayed that way, so the text overflows the rectangle.

Take home lesson (again), for portability only use font sizes that are integer numbers when converted to Points.

mathog · Postby **mathog** » Wed Jan 11, 2012 3:11 am

Here is the screen dump of what PowerPoint does with this .ppt file. Not shown, LOImpress view - looks just like it did in the PDF.

mathog · Postby **mathog** » Thu Jan 12, 2012 9:47 am

Just tried LO 3.5.0b2 to see if it worked any better. At first I was very excited when I saw the very nice job it did of importing the bounding_line4.svg file. Aside from one stray rectangle it was beautiful. Sadly it was too good to be true - it had not actually imported the SVG as objects into LODraw, but rather rendered it as an image. There was no way to convert from that image to objects. So 3.5.0b2 is even less useful for SVG import than is 3.4.4.

mathog · Postby **mathog** » Thu Feb 02, 2012 4:40 am

Version 0.48+devel works pretty well now for moving drawings from Inkscape to PPT 2003. See this thread:

https://bugs.launchpad.net/inkscape/+bug/919728

To get everything working right, use the last code variant in that thread for emf-win32-print.cpp and pay special attention to the workaround described starting at post #50, which is needed to match up the page sizes between the two programs. Do it this way and:

1. inkscape drawing size maps onto PPT drawing size
2. font sizes and linewidths are preserved
3. rotated text works

Still broken (seems to be an issue in PPT): text offsets downward slightly by an amount proportional to font size. Issue for very large type or when alignment is critical. Same EMF imported back into Inkscape doesn't have this text offset problem.

Note: PPT 2010 has an additional bug, it drops line widths on EMF import, it does this even for EMFs it created itself.

This is a read-only archive of the inkscapeforum.com site. You can search for info here or post new questions and comments at inkscape.org/forums

This is a read-only archive of the inkscapeforum.com site. This feature is no longer available.

InkscapeForum.com

Can't get there from here: converting to other types

Can't get there from here: converting to other types

Re: Can't get there from here: converting to other types

Re: Can't get there from here: converting to other types

Re: Can't get there from here: converting to other types

Re: Can't get there from here: converting to other types

Re: Can't get there from here: converting to other types

Re: Can't get there from here: converting to other types

Re: Can't get there from here: converting to other types

Re: Can't get there from here: converting to other types

Re: Can't get there from here: converting to other types

Re: Can't get there from here: converting to other types

Re: Can't get there from here: converting to other types

Re: Can't get there from here: converting to other types

Re: Can't get there from here: converting to other types

Who is online