EMF problems on import into Powerpoint

The scaling on lines is even odder than I thought. Attached is a modified SVG example with lines at various powers of two widths (in points). This is the conversion table after it is ungrouped:

SVG -> PPT = ratio
32 -> 28.8 = .900
16 -> 14.38 = .898
 8 -> 7.25 = .906
 4 -> 3.63 = .908
 2 -> 1.75 = .875
 1 -> .88 = .880
0.5 -> .38 = .760
.25 -> .25 =1.00
,125 -> .13 =1.04

It starts out for small point sizes nearly linear 1:1, then goes off the rails at 0.5 pt and up.

The same EMF imported into LibreOffice Draw (3.4.3) also has issues, but different ones:

1. the line widths are all converted to zero.
2. the X vs. solid setting for stroke is respected here (that much is an improvement)
3. Font sizes map 40->18.8, 20->9.3, 10->4.6, 5->2

Also if the SVG is exprted as WMF instead of EMF, all the lines come out as they should (exactly the right point sizes) but the text is converted into I'm not quite sure what, but it looks like bitmaps. They are all at the same font size, whatever they are.

There was a typo in the SVG file, the smallest text says 10 pt, but it is 4pt.

Tried this with PowerPoint 2010. Nothing was fixed, one thing got worse. On import of the EMF before ungrouping the line segments have what looks like more or less the proper width. After ungrouping they all
have width 0 (which is still visible in PPT). So newer PPT versions act like LibreOffice draw in that they too lose
the line width information.

The import of rotated text also still doesn't work from EMF with PPT 2010.

The font size ratios after import in Powerpoint 2010 are:

40->27, 20->13, 10->7, 4->3

This is turning into one of those "you can't get there from here" days. I tried exporting the 3rd version of this test file to ODG format and then opened it in LO Draw (version number cited in one of the previous posts).

1. All lines converted to 0.0 pt width.
2. Respects the visibility bit setting from the SVG
3. All text converted to paths (so not editable text anymore).

This is the best I have come up with so far for Inkscape -> PPT:

1. Make a diagram in Inkscape.
2. Write to PDF using pdfcreator (the Adobe PDF driver had more glitches for some reason)
3, Open the PDF in LibreOffice Draw
3b. Select all lines and change corner style from rounded -> mitered.
4. Select all, ungroup, copy
5. Open a ppt document in Powerpoint 2003.
6. Paste
6b. find text that isn't horizontal. The letters may have flipped over. If so, select them and
rotate them 90 twice in the same direction.

This method retained the logic for boundary lines being visible or not, and the fonts are all proportional to each other (if not the starting size: 40pt -> 32pt).

The down side(s):

1. At draw import the bounding lines all end up "rounded" when they should be "mitred"
2. Text is converted to separate letters on import into draw. They are still letters and not paths, but they cannot be edited easily.
3. Letters are sometimes flipped when finally seen in Powerpoint
4. Line segments are converted to rectangles when pasted into Powerpoint (they were lines in LO Draw).
5. Transparency cannot be moved this way as the PDF creation goes through postscript where transparency
is not supported.
6. This is a very time consuming method of moving graphics from one program to another!!!

With the PDF creation, have you tried directly saving to PDF within Inkscape itself rather than using a PDF printer?

Yes, that turned out just like printing through PDF creator. Same deal with the rounded corners on bounding lines.

It turns out that LO Draw export to EMF (or select and copy) breaks curved polylines down into huge numbers of small line segments on import into PPT, which looks pretty dreadful.

> 2. Font sizes change when an imported picture is ungrouped. All sizes are in points:

Inkscape uses 'px' as unit for font sizes, not points.

Would you be willing to add a screenshot of how it looks?

Here is the problem I found going from LODraw to PPT. The image on the left is LODraw after importing the PDF created from the inkscape drawing. It looks very good and the control points on the polylines/curves are where they are supposed to be. Unfortunately after select, copy, and then paste into a PPT slide they look like the image on the right.

Here is another method that works better, sometimes, at least with relatively simple drawings. Unfortunately it
introduces yet another set of glitches:

1. open PDF in LODraw.
2. select region (or all)
3. copy
4. In LOImpress paste
5. In LOImpress save as .ppt (not .pptx, that does something too awful to describe).

The result in either LOImpress or Powerpoint is as shown in the attachment. It is almost perfect. Except that odd connection from the break in the path. It cannot be removed in PPT. In PPT select that curve and try "edit points" and nothing happens.

It can be removed in LibreOffice with a little effort:

1, select the improperly closed curve
2. change to curve
3. split (if this isn't done, it is impossible to split the curve, there is no obvious change in the diagram, but
"split" falls off the menu, and "split curve" is no longer greyed out in the "edit points" window.)
4. select the two points on the end of the erroneous straight line
5. split curve
6. select the straight line
7. delete it

However, this route is no panacea either, the more elements that are present when Impress saves to ppt the less likely it is to work properly. For instance, the glitch described here isn't seen when this fragment is pasted along with the rest of the original page. Instead curved black lines are broken up into separate line segments (no longer polylines) and the red and green circles are no longer colored.

Very frustrating!

The problem with invisible bounding lines around filled objects becoming visible can be fixed by adding this code snippet:

//Inkscape is NOT calling create_pen for objects with no border. PPT, and presumably others, pick whatever they want
 //for the border if it is not specified, so no border can become border. To avoid this specify "no pen" here if we can determine
 //that no pen will be needed after the fill.
     if (style->stroke.noneSet || style->stroke_width.computed == 0.0){
           if(hpen)destroy_pen();
           hpen = (HPEN) GetStockObject(NULL_PEN);
           hpenOld = (HPEN) SelectObject( hdc, hpen );
     }

Just before:

    if (style->fill.isColor()) {
        if (create_brush(style))
            return 0;
    } else {
        // create_brush(NULL);
        return 0;
    }

in emf-win32-print.cpp

As the comments indicate, the problem is that some other part of Inkscape never calls the emf code for an object with no bounding line (no stroke). Other programs, notably powerpoint, assume different things than Inkscape does about what
to do when no pen has been specified. This fix says explicitly when such a line is to be invisible. With this patch in place EMFs imported into PowerPoint do not pick up borders where none were intended. So far this as it looks like hpen and hpenOld are being overwritten.

I am not confident that the destroy_pen call is being employed in all instances where it is needed, and not in some where it is not needed.

It would be better if the problem was addressed in the calling code (which I could not identify) which needs to call both stroke and fill methods for every object, and let the underlying target (EMF, SVG, PDF, or whatever) decide when "no pen" is the same as "do not draw".

On a somewhat related note there is code in emf-win32-print.cpp involving explicit rectangle() and ellipse() functions, near as I can tell, nothing ever calls the rectangle() part (did not test ellipse). All rectangles are being passed as poly lines.

Strange glitch in the previous post. The sentence:

  So far this as it looks like hpen and hpenOld are being overwritten.

Should have been

  So far this looks like it is working as it should. I cannot rule out a memory leak because it appears that hpen
  and hpenOld are being overwritten.

Branch <https://code.launchpad.net/~inkscape.dev/inkscape/emf-support> (superseded lp988601) was merged intro trunk in revision 12488:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12488>

@David - please add a comment here if the status change was wrong, and this report isn't addressed with the merge of your branch in r12488.

The issues discussed above, with one exception, were resolved in lp988601 so they should now be resolved in trunk.

The one exception is with PowerPoint 2010 ignoring line widths on import from EMF, and that is plain and simple, a bug in PowerPoint 2010.