PowerPoint Graphics Portability Issues

PowerPoint Graphics Portability Issues


Table of contents

Top of page

Introduction

Microsoft PowerPoint is the de facto standard for presentation software. For all of its strengths, PowerPoint has quite a few deficiencies in the way it handles graphics, especially vector (or object) graphics. When these issues are not taken into account graphics may become fuzzy or corrupted when they are converted from a PowerPoint presentation to other formats (and vice versa). These issues will be discussed here, as will be methods for avoiding or mitigating these problems. The issues were all discovered during the preparation of college level lectures, but they are not subject specific and would be expected to occur in other contexts, in industry, and elsewhere.

The flow of graphics in a typical lecture are indicated in the figure below. (If you cannot see this figure your browser does not support SVG - use a different browser to read this document.) Red text indicates the file formats usually employed in each transition.

Graphics flow into/out of Powerpoint

Graphics are typically imported into PowerPoint as bitmap images from other class lectures, from the scientific literature, or from elsewhere on the web, for instance similar lectures at other institutions. Other graphics are created within the presentation using PowerPoint's drawing tools. These two types of graphics differ substantially in their properties. Typically the vector graphics produced by PowerPoint's drawing tools use less space and are sharper than the bitmap images. For this reason, whenever possible, vector graphics should be preferred over bitmap graphics. As an example, consider a graphic of an arrow imported as a 128 x 128 pixel bitmap image. This image is as sharp as it can ever be, so enlarging it will just result in a blocky or fuzzy larger image. Conversely, a vector graphics arrow will remain sharp no matter how much it is enlarged. Bitmap images cannot be edited within PowerPoint. Consequently, it is common to encounter presentations where undesired parts of an image have been hidden by placing vector rectangles (or other shapes) "above" the image. Obscuring parts of the image this way is visually nearly as good as an actual erasure if the color of the blocking shape is set to the background of the image. Text may be blocked out and other text entered above.  Yet modifying vector graphics is still simpler, as elements may be deleted, resized, colored differently, and text may be edited. However the drawing tools available within PowerPoint are very limited in comparison to dedicated drawing programs.

It is not common for the original PowerPoint file to be provided to the students, or through public class web sites, to a wider audience. Instead these files are converted to one of several other formats as shown in the drawing above. Unfortunately doing so will often result in some or all of the vector graphics being converted to bitmap images, and the resulting presentations may be quite blurred in comparison to the original. Conversion to Web Pages is especially problematic in this regard.

A slightly different paradigm is described here. Instead of incorporating graphics directly into PowerPoint, such graphics are first imported into Inkscape, a separate open source and free drawing program. A figure or entire page is composed in Inkscape. Inkscape's native file format is SVG, which is a standard vector graphics format which modern web browsers should support. However PowerPoint cannot read SVG files. So to move the graphics from Inkscape to PowerPoint EMF (Enhanced Windows Metafile) files are used, as PowerPoint can read these (subject to numerous issues which are discussed below.) In the figure below source material has already been brought into or composed in Inkscape (these arrows are not shown) and is then moved from there into PowerPoint or elsewhere.Red text indicates the file formats usually employed in each transition.

Graphics flow into/out of Powerpoint and through Inkscape

There are known issues associated with each of the indicated conversions. Each of these is discussed below, and where possible, methods for avoiding or ameliorating these problems are presented.


Inkscape → PowerPoint via EMF files

Method

To move a graphic from Inkscape into PowerPoint through an intermediary EMF file do the following:

  1. Inkscape:
    1. File menu → Save As....
    2. The Save file dialog will appear.
    3. Set File type: to Enhanced Metafile (*.emf).
    4. Set File name: to your_filename (choose any filename).
    5. Click on Save.
    6. The EMF Output option dialog will appear.
    7. Select the desired EMF Output options.
    8. Click OK
  2. PowerPoint:
    1. Select slide to import into.
    2. Insert → Picture → From File....
    3. The Insert Picture dialog will appear.
    4. Set Files of type: to All or Windows Enhanced Metafile (*.emf).
    5. Set File name: to your_filename (just created above)
    6. Click Insert

At this point the graphic has been imported as a Picture. A Picture is essentially a rectangle as far as PowerPoint is concerned, and what lies within that rectangle cannot be modified by PowerPoint, although the entire object may be moved or resized. PowerPoint will display the contents of that graphic using what appears to be the same code as Windows Preview. Importing an EMF file as a Picture does not convert it to a bitmap - internally it is still composed of vector graphics objects. In order for PowerPoint to be able to modify these vector graphic objects the Picture must be converted to Microsoft drawing objects. Many of the PowerPoint issues listed below arise during this conversion (which is why it is probably better to leave the imported graphic as a Picture). To convert do the following in PowerPoint:

  1. right click on the graphic → GroupingUngroup → click Yes
  2. right click on the graphic → GroupingUngroup

The first ungroup will convert the graphic to a collection of Microsoft Drawing objects - with all of the members grouped together. The second ungroup breaks them apart so that they may be individually manipulated.

Top of page

Inkscape Version

The current release version of Inkscape (0.48.4) does not yet incorporate all of the changes needed to handle EMF files as described here. A binary version for Windows systems with all of the EMF related patches included may be downloaded here: http://saf.bio.caltech.edu/pub/software/windows/. It is distributed in a zip file, just download it and unpack it, then double click on the file inkscape.exe within it to run the program. As this is written a version based on Inkscape version r13276 is available. Mac and Linux users will need to build their own by following the directions at http://wiki.inkscape.org/wiki/index.php/Compiling_Inkscape. This has most of the same patches applied, but it will not include the more experimental ones which have not yet been committed to trunk. Then proceed as described in the development page to build a working version of Inkscape.

Although it may seem inconvenient to have to use a modified version of Inkscape, that is actually one of the main reasons the program was chosen for this work. Besides being free, the source code is available. Numerous EMF issues not listed here were present in earlier versions of Inkscape, but these have been eliminated by modifying the program so that the end user will never enounter these problems. The issues which remain are all the result of limitations in the EMF format or bugs in PowerPoint.

Top of page

EMF Output Options

Inkscape provides a small number of EMF Output options. These allow the EMF file to be tailored for specific target applications. In particular, it provides a way to compensate for some of the bugs in PowerPoint's Picture to Microsoft Drawing objects conversion.

The Output options are:

Examples:

Top of page

Phantom rectangle

This issue affects all known versions of PowerPoint. The issue manifests during conversion to Microsoft drawing objects.

After the conversion from a Picture to Microsoft Drawing objects an invisible rectangle the size of the incoming EMF page is present beneath all other objects. When attempting to modify objects within the graphic this invisible rectangle is often selected by accident along with or instead of the desired objects. Immediately after importing an EMF file and converting it, it is good practice to click once on a blank part of the graphic to select the hidden rectangle, and then press the delete key to remove it.

Top of page

Page sizes

This issue affects all known combinations of PowerPoint and Inkscape.

In order to compose a page in Inkscape that will import into PowerPoint at exactly the size of a slide one must match PowerPoint's actual, as opposed to declared, page size. PowerPoint's Page Setup dialog lists standard page sizes such as Letter Paper at a declared size of 8.5" x 11". Naively one might think that by selecting a standard size the resulting slide would in fact be the declared 8.5" x 11" in size. This is not the case because PowerPoint assumes a mandatory empty border on each page which will apply when the page is printed. This border is not applied during a PowerPoint presentation. In the same dialog are shown the actual Width and Height in inches. Note how in the example below the actual page dimensions are not the same as the declared page size.

PowerPoint Page Setup standard sizes are not equal to
      actual sizes

When setting the drawing size in Inkscape using the Document properties... dialog be sure to set custom size Width and Height values, with units in inches, to match the actual PowerPoint sizes. (Unfortunately current versions of Inkscape will still show a standard Page Size selected even after a Custom size has been set - the latter takes precedence.) The page size in the example below matches the page size in the PowerPoint document above:

Inkscape Document properties, set to match PowerPoint
      actual sizes

Top of page

Font sizes

This issue affects all versions of Inkscape before r11664.

Font sizes in Inkscape prior to revision 11664 were always given in pixels, whereas in PowerPoint and most other programs the font sizes are specified in points. Subsequent to Inkscape revision 11664 font sizes also default to points. The best way to avoid this issue is therefore to use a recent version of Inkscape.

If an older version of Inkscape must be used convert from points to pixels by multiplying by 1.25, and of course, to convert in the other direction multiply by 0.8. So in the Inkscape example below, the text is 40px, or 32pt.

Inkscape Font sizes are in pixels, not points, multiply
      pts * 1.25 to get px

Since most people have been trained to think in points for font sizes, it rapidly becomes tedious having to multiply all the time to come up with the appropriate Inkscape font size. The simplest way around this is to keep a copy of the table below handy when working in Inkscape.

Points (PowerPoint) Pixels (Inkscape)
8 10
9 11.25
10 12.50
12 15
14 17.5
16 20
18 22.5
20 25
22 27.5
24 30
28 35
32 40
36 45
Top of page

Integral font sizes

Affects PowerPoint 2003 but not PowerPoint 2010. The issue manifests during conversion to Microsoft drawing objects.

Older versions of PowerPoint only support integer point sizes. When fractional font sizes are read from an EMF file they will be truncated. So an 11px font in Inkscape would import into PowerPoint not as an 8.8pt font, but as an 8pt font.

Top of page

Dotted or dashed lines

Affects all known versions of PowerPoint. The issue manifests during conversion to Microsoft drawing objects.

Microsoft's EMF file specification supports two different types of dotted/dashed line. The first may be selected from a small number of standard patterns, and the second is custom - any pattern may be specified. PowerPoint is unable to convert a Picture imported from an EMF file which contains any line that uses either of these modes to Microsoft Drawing objects. No error or warning messages result, the operation just fails. Consequently such a graphic may not be modified within PowerPoint.

Inkscape exports dotted and dashed lines to an EMF file using the "custom" mode described above. So an Inkscape drawing exported to EMF that contains any dotted or dashed lines will not be fully usable in PowerPoint. The work around is to convert the dots and dashes in such lines to separate line segments while exporting to EMF. This is accomplished by selecting the EMF Output option Convert dashed/dotted lines to single lines.

PowerPoint and several other drawing programs tested all performed this sort of conversion automatically when they saved in EMF format. Consequently none of them can export and then reimport a dotted or dashed line through EMF format. Inkscape can do so if the export option described above is disabled. Of course doing so will prevent PowerPoint from converting the Picture to Microsoft Drawing objects.

Note that subsequent to the conversion of the boundary of a filled shape with a dashed border the EMF file will contain the filled shape without a border followed by all the line segments which constituted its border. On import from the EMF file into a program this assembly will look like the original filled shape, but it will not act exactly like it. Grab a dash and drag it in the original object and the entire object moves, whereas after conversion and import only that one dash will move.

Top of page

Line widths

Affects PowerPoint 2010. It does not affect PowerPoint 2003. The issue manifests during conversion to Microsoft drawing objects.

When affected PowerPoint versions attempt to convert from a Picture imported from an EMF file to Microsoft Drawing objects all line widths are converted to the minimum visible width. These versions of PowerPoint do not save lines into an EMF file as a line object, but rather save them as a rectangular polygon. So while these appear to be able to save an image into an EMF as a line and then read it back in, in reality they have converted such lines to polygons. These broken versions have the same issue when they open EMF files produced by earlier versions of PowerPoint, which did use line widths. There is no convenient workaround for this issue since the line is such a basic type. The best choice would probably be not to employ one of these broken versions of PowerPoint, or if one must be employed, never convert from a Picture to Microsoft Drawing objects.

Top of page

Rotated images

Affects all known versions of PowerPoint and Inkscape.

Both Inkscape and PowerPoint support rotated images. The EMF file format has support for rotated objects only through a coordinate transformation, and has only weak support for transparency. Inkscape can export rotated images to an EMF file and read them back in again with no problems. However, PowerPoint has issues. Immediately after Insert Picture → From file... PowerPoint will display rotated images correctly. This is because it is using the operating system's EMF display code. (At least on Windows XP). The image might look like this:
Rotated images immediately after PowerPoint import
If within PowerPoint an attempt is made to convert the images to PowerPoint's internal representation by using the ungroup command it will be mangled, and will then look like this:
Rotated image as seen in PowerPoint
To work around this problem, and allow the images to be imported in PowerPoint and then used as one of its native objects, check Ignore Image Rotation when exporting to EMF from Inkscape. The resulting EMF will have all of its images with rotations stripped. Once inserted into PowerPoint and ungrouped these images may then be rotated within PowerPoint to recreate the original slide exactly. Top of page


Opacity

Affects all known versions of PowerPoint.

Support for opacity/transparency in EMF files is weak. The property is also not supported in some other file formats, such as Postscript. For this reason, it is probably best not to employ transparency in vector graphics which need to be moved between different drawing programs through intermediate EMF files.

Because of this limitation in EMF files PowerPoint itself is not actually able to export an object that is at all transparent to an EMF file and then reimport it, while retaining the transparency. What it does instead is employ a series of EMF records which emulate transparency by methods which will not be described here. However the resulting EMF file cannot be converted from a Picture to Microsoft Drawing objects once it is reimported. Other graphics programs have similar issues.

Inkscape drawing supports objects that are partially or fully transparent. However, when exporting such objects to EMF files Inkscape drops the transparency so that they become 100% opaque.

Examples: see Pattern Fills

Top of page

Gradients

Affects all known versions of PowerPoint.

Support for gradients in EMF files is weak. The property is also not supported in some other file formats, such as Postscript. For this reason, it is probably best not to employ gradients in vector graphics which need to be moved between different drawing programs through intermediate EMF files.

PowerPoint and all other tested graphics programs emulate gradients when they write to an EMF file. This is accomplished by writing a series of thin objects each with a single solid color. The series of colors approximate the colors of the original gradient. The resulting EMF files look approximately like the original in Windows Previwe or when re-imported into Powerpoint. They can be converted to Microsoft drawing objects within PowerPoint, but the single gradient object is replaced by a large number of thin objects. The large number of thin objects often produce Moire patterns or other undesired rendering artifacts when viewed at reduced magnification. Additionally, EMF files containing many gradients tend to be quite large, since they become bloated with the descriptions of many hundreds or thousands of these small objects.

Inkscape will perform a simlar gradient conversion if the EMF Output option Convert gradients to colored polygon series is selected. Both linear and radial gradients may be converted. Gradients which have opacity values other than 100% at any of the stops are converted as if the object was immediately above the document's background color, even if other objects are actually present in the drawing between the gradient filled object and the document background. When this option is not selected gradient filled objects are exported as being filled with a single color which is the average of the colors at the ends of their gradient.

EMF has two types of gradient records, one for rectangular gradients and one for gradients comprised of triangles with a color assigned at each corner. Inkscape can read either type. Inkscape will try to emit a rectangular gradient record if the output option Use native rectangular linear gradients is selected in addition to the Convert gradients to colored polygon series. The record will be emitted if the gradient is aligned with the edges of the polygon, otherwise it will fall back to the slice method. PowerPoint will be able to display the gradient when the EMF is imported, but it will not be able to convert that gradient to a Microsoft Drawing Object. If a conversion is attempted within PowerPoint (2003 or 2010) an empty rectangle will result.

Examples: see Pattern Fills

Top of page

Pattern Fills

Affects all known versions of PowerPoint. The issue manifests during conversion to Microsoft drawing objects.

Inkscape can import and export the full gamut of EMF patterned strokes and fills, which include standard patterns, custom paterns, and images used as a repeating pattern. PowerPoint is able to import all of these fills as a Picture using Insert → Picture → From File.... However, it is only able to convert the standard EMF patterns (horizontal, vertical, forward diagonal, reversed diagonal, hatched, and diagonal hatched) to Microsoft Drawing objects. It does not perform this task perfectly, as during the conversion PowerPoint ignores the background color specified in the EMF file and uses black, so that the resultant Microsoft Drawing objects will look quite different in PowerPoint than they did in the original drawing. Inkscape has an EMF Output option Map all fill patterns to standard EMF patterns, so that all patterns are converted into a form which PowerPoint can convert to Microsoft Drawing objects. The results may sometimes be useful, especially when only a few patterns are present in the drawing, and the type of pattern is not important. Standard EMF hatch patterns read into Inkscape have names like EMFhatchA_XXXXXX: where A is one of the digits 0 through 6 corresponding to the standard EMF hatch patterns horizontal, vertical, antidiagonal, diagonal, hatch, diagonal hatch, and solid, and XXXXXX is the RGB color in hexadecimal, like FF0080 for (255,0,128). These hatch patterns retain their pattern and color when written to an EMF file. In addition, any tiled image fill patterns imported from an EMF file and into Inkscape may be exported to an EMF file where PowerPoint may read them. However, there is currently no automatic method to export the majority of Inkscape's built in pattern fills, as these are implemented as SVG draw operations, and would need to be converted to bitmaps if they were to be stored in an EMF file.

Examples:

Top of page

Image Fills

Powerpoint can fill an object with an image. However, it treats the resulting filled objects as just another image when it exports it to an EMF file. So all the comments in Rotated images apply also in this context.

Top of page

Unicode mapping

Affects all known versions of PowerPoint.

Unicode character encoding is the standard for web content in HTML and SVG. In Unicode each character's integer value designates a single character identity, regardless of the font used. The exact rendering of the character may value somewhat from font to font, but an A is always an A. Inkscape uses Unicode encoding.

PowerPoint predates Unicode, and while Unicode support has been added to it, it still retains support for some characters through the use of the special fonts: Wingdings, Zapf Dingbats, and Symbol. Each of these special fonts consists of about 256 characters, and the character represented for the same integer value depends on the font. For instance, in PowerPoint the character whose value is 66 hexadecimal in each of these fonts is: ♐ (Sagittarius), ❆ (Heavy Chevron Snowflake), φ (Greek small Phi). As a further complication, Powerpoint actually represents the integer values for these special fonts internally not as 20-FF hexadecimal, but as F020-F0FF hexadecimal. This encoding places them in a Unicode private use area - characters with no standard Unicode encoding, for use by any program for its own ends. However, when it reads these values from an EMF file it expects to find them as 20-FF hexadecimal.

Most of the Wingdings, Zapf Dingbats, and Symbol characters have corresponding Unicode characters. For instance, the hexadecimal values for Sagittarius, Heavy Chevon Snowflake, and Greek small Phi characters are: 2650, 2746, and 03C6. If these symbols are used in Inkscape, they will be represented by the Unicode value. PowerPoint import of these sorts of Unicode symbols is hit and miss, so Inkscape has EMF Output options to automatically map these Unicode characters to their corresponding special font forms, which PowerPoint will recognize. These EMF Output options are Map Unicode to Symbol, Map Unicode to WingDings, and Map Unicode to ZapfDingbats. Additionally Inkscape provides an EMF Output option Use MS Unicode PUA (0xF020-0xF0FF) for converted characters. This is not needed for PowerPoint, which expects to find these characters in the range of valuees 0x20-0xFF.

Inkscape always automatically performs the opposite conversion when it reads an EMF file exported by PowerPoint which contains these characters. There may be a slight shift in position of the affected characters when these conversions occur, as the font metrics will not be identical between, for instance, Symbol and Times New Roman.

Be aware that on most Windows systems the font named Zapf Dingbats which is used by Microsoft applications is actually Wingdings, whereas on Mac and Linux systems Zapf Dingbats usually is that font. This can cause some font confusion, as indicated in the following example, where the expected Zapf Dingbats character (Heavy Chevron Snowflake) is replaced by the Wingdings character with the corresponding value. For this reason it is usually a bad idea to employ the EMF Output option Map Unicode to ZapfDingbats on Windows systems.

Examples (the PowerPoint images are from a Windows machine):

Top of page

Character Placement

Affects all known versions of PowerPoint. The issue manifests during conversion to Microsoft drawing objects.

Characters in different fonts are placed correctly in the EMF file. However when the EMF file is converted to a Microsoft drawing object characters are offset from their correct position in a manner which depends upon their font. Inkscape provides an EMF Output option to compensate for this effect. EMF files created with this compensation on have the characters offset in the opposite sense, so that on final conversion in PowerPoint to a Microsoft drawing object they land in the desired position. If this compensation is used the character positions seen with Windows Preview or in PowerPoint before conversion will be incorrect. It is not possible to generate a single EMF file whose characters as seen in PowerPoint will be in the currect positions both before and after conversion to Microsoft drawing objects.

To compensate for this issue in Inkscape do: File → Save as... → Save as type: Enhanced Metafile (*.emf), Filename:your_filename, click Save → check EMF Output option: Compensate for PPT font bug click OK .

Inkscape has compensation settings for these fonts:

Compensation for other fonts may be implemented by adding a line to the fontfix.conf file.

Examples:

Top of page

Formatted Strings

Affects all known versions of PowerPoint and Inkscape.

Both Inkscape and PowerPoint have internal methods for formatting a complex string such that it may contain a mixture of different fonts, font sizes, bold, italic, super or subscript, and other properties. However, the EMF file specification has no type corresponding to this complex object. When complex strings are exported to an EMF file they must be broken down into simpler parts, each composed of a string of text all with the same properties. When these simpler parts are imported into PowerPoint, and converted to Microsoft drawing objects, they may be individually edited as text, or their color changed, etc., but the complex object is not recreated so it may not be edited as a whole.

Examples:

Top of page

PowerPoint → Inkscape via EMF files

Existing PowerPoint presentations are most conveniently imported into Inkscape through EMF files. This method enables most content to be transferred without requiring subsequent tweaking or correction. However there are some issues which may arise during this process, and these are described here. Inkscape can also import graphics from other file types, notably PDF files.

Top of page

Method

To move a graphic from PowerPoint into Inkscape through an intermediary EMF file do the following:

  1. PowerPoint:
    1. Select a slide to export.
    2. Create a rectangle that exactly fills the entire slide, then Order → Send to Back.
    3. Select All objects in that slide - including the rectangle from the preceding step.
    4. Right click on any of the selected objects and choose Save as Picture....
    5. The file save dialog will appear.
    6. Set Save as Type: to Enhanced Metafile (*.emf)
    7. Set File name: to your_filename
    8. Click Save.
    9. (Optional - delete the rectangle from the second step.)
  2. Inkscape:
    1. File menu → Open...
    2. The file open dialog will appear.
    3. Set Files of Type: to Enhanced Metafile (*.emf).
    4. Set File name: to your_filename (as used in PowerPoint),
    5. Click on Open.

The graphic will import with all elements in a single group. To ungroup right click anywhere on the grapic and select Ungroup from the menu. Or use control-a to select and then control-shift-g to ungroup. Some related elements within the graphic may still be grouped together and may require subsequent ungrouping operations.

The background rectangle created in the second step in PowerPoint is needed to set the size of the EMF drawing. If it is left out the size will be whatever it takes to hold all of the selected objects. By using the background rectangle one may transfer a slide shaped drawing from PowerPoint to Inkscape without having to manually change its scale. Note that when doing many slides the background rectangle may simply be cut from slide N and pasted into slide N+1.

Top of page

Rotated images

Affects all known versions of PowerPoint and Inkscape.

Both Inkscape and PowerPoint support rotated images. The EMF file format has support for rotated objects only through a coordinate transformation, and has only weak support for transparency. Unfortunately PowerPoint does not use the coordinate transformation method to export a rotated picture to an EMF file. PowerPoint emulates image rotation in EMF files by first rotating the image within a larger image - no part of which is transparent, then exporting the larger image, then applying a series of masking operations to remove the regions in the larger image outside of the original rotated image. In the special cases where the rotation angle is a multiple of 90°, where no masking operations need be employed, Inkscape will be able to import those images. For all other angles, the EMF file produced by PowerPoint will show up in Inkscape with the larger image and one or more masks. Inkscape does not "know" how to combine these to reproduce the original image and will show both the larger image and an "unknown image" representation for the masks.

There are at least three ways to work around this issue, but all require manual intervention. The first is to find the original image, import it directly into Inkscape, rotate/scale it until it exactly overlays the imported rotated image, then delete the larger image. The second method is to draw a solid rectangle over the rotated part of the imported image, then select both the rectangle and the larger image, then do Object → Clip → Set This will hide those parts of the larger image which are not desired. Those regions are still present though, since the operation can be reversed with Object → Clip → Release. The third method is to save the larger image containing the embedded rotated image to a file, then use a program like Photoshop or Gimp to make the unwanted regions 100% transparent, and then to reimport it.

Examples:

Top of page

Grouped objects

Affects all known versions of PowerPoint.

Microsoft drawing objects, when grouped within PowerPoint, are silently replicated when later exported to other file types. The replicas appear in the same position, resulting in a stack of objects, of which only the topmost are not hidden. These unnecessary extra copies are a waste of space and can slow down later processing dramatically if there are enough of them.

To avoid this problem in PowerPoint use Select all then Grouping → ungroup until the entire drawing is reduced to ungrouped objects. Only then export the drawing to EMF.

Examples:

Top of page

Opacity

Affects all known versions of PowerPoint and Inkscape.

It is not possible to transfer (partially) transparent objects from PowerPoint to Inkscape through an intermediary EMF file. Only objects which are completely opaque will be transferred successfully.

Support for opacity/transparency in EMF files is weak. The property is also not supported in some other file formats, such as Postscript. For this reason, it is probably best not to employ transparency in vector graphics which need to be moved between different drawing programs through intermediate EMF files.

Because of this limitation in EMF files PowerPoint itself is not actually able to export an object that is at all transparent to an EMF file and then reimport it, while retaining the transparency. What it does instead is employ a series of EMF records which emulate transparency by methods which will not be described here. However the resulting EMF file cannot be converted from a Picture to Microsoft Drawing objects once it is reimported. Inkscape sees these records as a series of bitmap masks, but it cannot make any sense of them and so these parts of the imported EMF file look nothing like the original.

Examples:

Top of page

Gradients

Affects all known versions of PowerPoint and Inkscape.

Support for gradients in EMF files is weak. PowerPoint emulates gradients when saving to EMF by writing a large number of thin monochrome objects and then masking the excess. PowerPoint cannot successfully read its own gradients from an EMF file and convert them from Picture to Microsoft Drawing objects. When it does so it drops the mask operation as shown in the example below. Because the gradient objects it creates do not overlap they are subject to an antialiasing artifact that creates thin light lines between them. It appears that PowerPoint has some mechanism for avoiding this problem, perhaps by disabling antialiasing on vertical and horizontal lines, whereas other graphics programs reveal the issue. (Oddly, the widths of gradient strips produced by PowerPoint vary considerably, more than expected just from rounding or truncation errors.)

In general if a small number of gradients are involved the best choice is to remake them by hand once the diagram has been imported into Inkscape. Simply delete the many small rectangles and then apply the appropriate gradient fill to the shape's outline. This is a manual operation so it is not going to be practical if hundreds or thousands of gradients need to be repaired. Since moving gradients back to PowerPoint from Inkscape is also problematical, serious consideration should be given to using solid fills instead.

Examples:

Top of page

Patterns

The EMF file format supports fills consisting of a standard set of hatch patterns, custom hatch patterns, and repeated tiling of images. Inkscape can import all of these types. PowerPoint always exports its pattern fills using the image tiling method, so Inkscape can patterned fills which PowerPoint exported to an EMF file. Inside Inkscape these patterns are shown with names like EMFImageX_ref, where X is an integer. It is possible to apply these fill patterns to other objects within Inkscape. However PowerPoint itself can only partially process these same fill patterns from an EMF file, including ones it created. More details here.

Top of page

Unicode mapping

This issue is discussed in depth the the section covering PowerPoint to Inkscape font mapping. When Inkscape is exporting to EMF it offers the option to try to convert Unicode characters to Symbol, Wingdings, and/or ZapfDingbats. When the export target is PowerPoint on Windows the first two options would usually be selected, and when it is PowerPoint on a Mac all three options would be used.

Top of page

Formatted Strings

Affects all known versions of PowerPoint and Inkscape.

Both Inkscape and PowerPoint have internal methods for formatting a complex string such that it may contain a mixture of different fonts, font sizes, bold, italic, super or subscript, and other properties. However, the EMF file specification has no type corresponding to this complex object. When complex strings are exported to an EMF file they must be broken down into simpler parts, each composed of a string of text all with the same properties. When these simpler parts are imported into Inkscape from an EMF file they are passed to libTERE which attempts to reassemble them into formatted text.  So long as the text is reasonably well behaved, that is, looks more or less like normal formatted text, this generally results in the original formatted string being successfully reassembled.  The assembled text differs from normal Inkscape formatted text in one slight way - super- and subscripts are implemented with kerning, rather than by the baseline shift method Inkscape usually uses.

Examples:

Screen dump of an EMF file viewed with Windows XP Preview which has been broken down into component parts:
EMF example as seen in Windows XP Preview.

In the SVG file shown below the preceding EMF has been read into Inkscape and the text reassembled.  Within Inkscape the various text fields may be edited as if they they had been created within that program.  For instance, in the math formula at the upper right, place the cursor on the first "a" in the top line and it will track across that line, following the upper and lower case positions, and then move to the lower line which may also be edited.  Had the text not been reassembled the first "a" would have been the extent of that editable field. 
Text reassembled by
        Inkscape

Top of page


Inkscape → Web Pages via SVG files

Top of page

Super and Subscript Characters

Affects current versions of Firefox, Seamonkey, and related browsers.

Astoundingly some web browsers do not support text superscript and subscript when they display SVG files. This is because in Inkscape and some other SVG generating programs these properties are implemented using something called "baseline-shift", and that does not work in these browsers.  This renders these browsers unsuitable for displaying most scientific and engineering documents, which inevitably contain this formatting. Browsers which are known to handle this task correctly include Opera, Chrome, and Safari. 

Examples:

Top of page

PowerPoint → Web Page via HTML, JPG, GIF files


Spurious browser warning

PowerPoint's Save As... → Web Page (*.htm;*.html) method is a convenient way to produce a web page version of a presentation, but it produces very complex pages which are difficult to edit to make changes. Additionally the top or "project" page will often warn browsers other than Internet Explorer that they are not supported. To see this warning click here while using Firefox or Opera.

Top of page

Vector Graphics convert to Bitmaps

PowerPoint's Save as Web Page option converts all graphics to bitmaps. The resulting loss of resolution is usually severe, so that fine print and other similar details become unreadable. If only a small number of conversions are needed, and the original vector graphics are available in SVG files, one may edit the resulting HTML and replace the img links to gifs with img links to the SVG. Aligning and sizing the SVG files using height,width, and viewbox may take several iterations.

In the example below the HTML was modified so that

 <img border=0 v:shapes="_x0000_s69218"
 src="slide0006_image002.gif" style='position:absolute;top:60.24%;left:3.24%;
 width:42.05%;height:39.75%'>
    
was replaced by
 <svg id="whatever"  height="175%" width="175%"
     xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" >
     <svg viewbox="+450 -900 3000 3000">
        <image x="1" y="1" height="3000" width="3000"  xlink:href="P2WP_graph.svg" />
     </svg>
 </svg>

    

Examples:

Top of page

PowerPoint → Printed Lecture Notes as Postscript files


Opacity

Many printers use the Postscript printing language. Postscript does not support Opacity/Transparency, so the printer driver will either try to emulate that property by dithering (setting colored/empty pixels in proportion to the opacity) or it will just use an opaque rendering. Either way the resulting printout will often not turn out as expected.

Examples:


Top of page

Gradients

While Postscript 3 does have the smooth shading shfill command which may be used to create gradient fills it is often not used by the printer drivers. Instead the printer driver creates an image of the gradient and stores that bitmap in the Postscript file. Typically the result is of acceptable quality once it is printed, although the resulting file (or transfer size, as the postscript is not usually saved anywhere) may be quite large. In this simple example the Postscript file produced is 282 KB, even though it consists of only two words and two gradient filled rectangles. The two words of "text" in this example are not converted to a bitmap - they are written at full resolution "over" the bitmap after that is rendered. So the use of bitmaps in this context does not degrade the resolution of overlaying vector objects.


Top of page

PowerPoint → Web Lecture Notes as PDF files

Grouped objects

PDF files have been observed which contain repeat copies of grouped objects similar to those observed when PowerPoint slides are saved to EMF. These were obtained from outside sources. No repeated objects were produced in tests where PowerPoint presentations were saved to PDF either through Adobe Distiller or PDFCreator. The most likely scenario is that the affected PDF files acquired extra copies of objects at some other point in their construction, and not at the stage where they were converted to PDF. However, only limited tests were performed and these do not rule out the the possibility that under some circumstances converting a PowerPoint presentation with grouped objects to PDF might creates extra copies of those objects.

Top of page

Opacity

Web lecture notes are in PDF format, and PDF format supports transparency, yet on most operating systems the printer queue used is a Postsript printer queue, and Postscript does not support transparency. So how does the transparency get into the PDF? That magic is accomplished through the use of pdfmarks, which are inserted by the driver into the Postscript stream. These have no effect whatsoever on how the Postscript would be rendered by a printer, but when the data stream reaches the actual PDF generator, it uses this information to add transparency effects. Some printer drivers, notably Acrobat Distiller, know how to do this and these will create PDF files containing transparent objects. (This appears to be one of the things which Distiller is doing when it makes the first pass through a document, before actually printing it.) Most other PDF generators, for instance PDFCreator, do not have an early phase during which they may insert pdfmarks, so they receive a version of the Postscript identical to what a printer would see, and consequently they cannot create a PDF file containing transparencies.

Top of page

Gradients

As for opacity the PDF file is generated from a Postscript data stream. In this instance there are no pdfmarks to aid in the creation of gradients and so PDF uses exactly the same methods for these as does Postscript. However, the resulting file is usually smaller, either because the PDF uses shfill instead of creating a bitmap, or because the image compression method used in the PDF version is more efficient than whatever is used in the Postscript version. In the example below the PDF is 20 times smaller than its postscript equivalent.

Top of page

Web Lecture Notes → Printed Lecture Notes as Postscript files


Opacity

Top of page

Conversion from PDF to Postscript has the same opacity issues as does any other source creating Postscript.


Gradients

Conversion from PDF to Postscript has the same gradient issues as does any other source creating Postscript.

Top of page

Acknowledgements

I thank Valek Filippov for pointing out errors concerning image rotation in an earlier version of this document. I also thank him for providing some very useful test files.

Top of page

Contact information

This page is maintained by David Mathog, Biology Division, Caltech. Please send comments or corrections to


last updated 13-Apr-2014