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
Can't get there from here: converting to other types
Can't get there from here: converting to other types
- Attachments
-
- bounding_line4_pdfcreator.pdf
- PDF via PDFcreator
- (22.14 KiB) Downloaded 190 times
-
- bounding_line4_saveas.pdf
- Saved as PDF
- (165.42 KiB) Downloaded 204 times
-
- bounding_line4.svg
- Starting svg drawing
- (105.04 KiB) Downloaded 175 times
Re: Can't get there from here: converting to other types
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.
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.
- Attachments
-
- save as ODG (this is a screen capture of it loaded in LO draw).
- bounding_line4_odg_screencapture.PNG (80.18 KiB) Viewed 3571 times
-
- bounding_line4.emf_not.pdf
- save as to EMF (not really a PDF file!)
- (63.28 KiB) Downloaded 173 times
-
- bounding_line4_adobepdf.pdf
- PDF via adobe PDf printer
- (9.97 KiB) Downloaded 195 times
Re: Can't get there from here: converting to other types
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.
Re: Can't get there from here: converting to other types
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....
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....
Re: Can't get there from here: converting to other types
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
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
- Attachments
-
- Example after save as to PDF, and then opened with LODraw
- LODraw_from_PDF_no_opaque.PNG (39.43 KiB) Viewed 3541 times
-
- Example screenshot from inside inkscape
- bounding_line4_no_opacity.png (107.02 KiB) Viewed 3541 times
-
- bounding_line4_no_opacity.svg
- example with all opacity, gradients, and fills removed
- (78.95 KiB) Downloaded 164 times
Re: Can't get there from here: converting to other types
PDF import issues which seem to be LODraw problems have been reported here:
https://bugs.freedesktop.org/show_bug.cgi?id=43806
https://bugs.freedesktop.org/show_bug.cgi?id=43806
Re: Can't get there from here: converting to other types
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?
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?
Basics - Help menu > Tutorials
Manual - Inkscape: Guide to a Vector Drawing Program
Inkscape Community - Inkscape FAQ - Gallery
Inkscape for Cutting Design
Manual - Inkscape: Guide to a Vector Drawing Program
Inkscape Community - Inkscape FAQ - Gallery
Inkscape for Cutting Design
Re: Can't get there from here: converting to other types
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
https://bugs.launchpad.net/inkscape/+bug/905032
Re: Can't get there from here: converting to other types
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.
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.
- Attachments
-
- bounding_line4_plain.svg
- boundling_line4 saved as plain svg
- (87.59 KiB) Downloaded 166 times
-
- LODraw import of bounding_line4_plain svg
- LODraw_plain_svg.PNG (14.08 KiB) Viewed 3410 times
-
- LODraw import of inkscape svg
- LODraw_inkscape_svg.PNG (86.49 KiB) Viewed 3410 times
Re: Can't get there from here: converting to other types
SVG import problems for LODraw added to this existing bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=37072
https://bugs.freedesktop.org/show_bug.cgi?id=37072
Re: Can't get there from here: converting to other types
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.
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.
- Attachments
-
- toxic_textboxt_is_really_ppt_not.zip
- imported PDF saved in .ppt by LOimpress, fake .zip extension to allow upload, is really .ppt
- (31.5 KiB) Downloaded 178 times
-
- toxic_text_box.pdf
- example, save as to pdf
- (13.17 KiB) Downloaded 243 times
-
- toxic_text_box.svg
- test case, fractional point size fonts, in rectangular bounding boxes
- (32.55 KiB) Downloaded 182 times
Re: Can't get there from here: converting to other types
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.
- Attachments
-
- screen dump of the .ppt opened in MS Powerpoint
- toxic_textbox_screendump_from_ppt.PNG (22.72 KiB) Viewed 3318 times
Re: Can't get there from here: converting to other types
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.
- Attachments
-
- SVG import in LODraw 3.5.0b2, sadly, this is an image, not a set of objects.
- lo_350b2_image.PNG (115.69 KiB) Viewed 3286 times
Re: Can't get there from here: converting to other types
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.
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.
- Attachments
-
- How it looks inserted into a PPT slide
- pptA4_scaling_example_from_ppt_screenshot.PNG (31.67 KiB) Viewed 3182 times
-
- pptA4_scaling_example.svg
- Source/example file: inkscape to ppt
- (13.11 KiB) Downloaded 163 times