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 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.
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.
To move a graphic from Inkscape into PowerPoint through an intermediary EMF file do the following:
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:
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 pageThe 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.
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:
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 pageThis 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.
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:
Top of page
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.
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 |
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 pageAffects 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 pageAffects 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 pageAffects 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:
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:
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
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 pageAffects 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 pageAffects 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:
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 pageAffects 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):
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:
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:
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 pageTo move a graphic from PowerPoint into Inkscape through an intermediary EMF file do the following:
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 pageAffects 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:
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:
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:
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:
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 pageThis 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 pageAffects 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:
.
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.
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:
More information on SVG:
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 pagePowerPoint'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:
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:
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.
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 pageWeb 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 pageAs 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.
Conversion from PDF to Postscript has the same opacity issues as does any other source creating Postscript.
Conversion from PDF to Postscript has the same gradient issues as does any other source creating Postscript.
Top of pageI 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 pageThis page is maintained by David Mathog, Biology Division,
Caltech. Please send comments or corrections to
