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:

Inkscape:

File menu → Save As....

The Save file dialog will appear.

Set File type: to Enhanced Metafile (*.emf).

Set File name: to your_filename
(choose any filename).

Click on Save.

The EMF Output option dialog will appear.

Select the desired EMF Output options.

Click OK

PowerPoint:

Select slide to import into.

Insert → Picture → From File....

The Insert Picture dialog will appear.

Set Files of type: to All or Windows
Enhanced Metafile (*.emf).

Set File name: to your_filename
(just created above)

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:

right click on the graphic → Grouping → Ungroup
→ click Yes

right click on the graphic → Grouping → Ungroup

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.

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:

Convert texts to paths

Convert editable text to a drawing path. Used very rarely,
only when the target program's EMF input is so horribly broken
that text cannot otherwise be transferred.

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.

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 sizeWidth
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:

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

PowerPoint:

Select a slide to export.

Create a rectangle that exactly fills the entire slide,
then Order → Send to Back.

Select All objects in that slide - including the
rectangle from the preceding step.

Right click on any of the selected objects and
choose Save as Picture....

The file save dialog will appear.

Set Save as Type: to Enhanced Metafile
(*.emf)

Set File name: to your_filename

Click Save.

(Optional - delete the rectangle from the second step.)

Inkscape:

File menu → Open...

The file open dialog will appear.

Set Files of Type: to Enhanced Metafile
(*.emf).

Set File name: to your_filename
(as used in PowerPoint),

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.

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:

Example rotated image as seen in a PowerPoint slideExample rotated image
exported to EMF
Example, as seen in Inkscape (the original rotated image is now
embedded in a larger image)
Example in Inkscape with the large image and one mask separated.
(The mask coloring is that given to any bitmap encountered which
is used in an unsupported manner.)

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:

Example ppt
Example, as seen in PowerPoint. There are only 4 circles. The two
black circles were grouped together first, then the two grey
circles were grouped, then the two groups were grouped. The
grouping is not visible.

Example exported to EMF
Example svg after importing EMF. The extra copies are all stacked
on top of one another, and so are not visible.

Example, as seen in Inkscape, illustration of the problem. There
are 12 circles. The two extra sets have been pulled aside to
reveal that there are 3 groups of 4 circles.

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:

Example with 50% transparency on three overlapping rectangles as
seen in PowerPoint Example exported from PowerPoint to
EMF
Example as seen after import from the EMF file into Inkscape. The
four components which originally were located where the red
rectangle is now have been moved aside. These are: the boundary
and three bitmap masks. Originally all of these components were
stacked on on top of each other.

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:

Example with a linear gradient as seen in PowerPoint. Original on
left, after saving to EMF and reading back in on right. Example exported from PowerPoint to EMF
Example as seen after import from the EMF file into Inkscape. The
mask has been lost so the gradient extends beyond the shape. The
vertical light lines are an antialiasing artifact which results
from the thin gradient objects not overlapping.

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.

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.

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:

SVG file with super and subscripts using the baseline
shift method. Compare to the next image to determine if you
are using a browser with this issue.
SVG file with super and subscripts using vertical
kerning. It was made by exporting the SVG file below from
Inkscape to EMF, and then reading it back in so that the text
would be reassembled. This should be displayed correctly in
all browsers.
Screenshot of the SVG file as seen in Inkscape

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.

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.

Example graph in an SVG file.Example PowerPoint file which includes
the graph and some text.Example HTML version of
the PowerPoint file via "Save as HTML". Notice that the graph is
blocky and ugly.Example HTML version
where a copy of the HTML version has been edited to replace the
GIF with the original SVG. The graph is once again high
resolution.

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:

Example with three overlapping 50% opacity colored rectangles in
PowerPoint.Postscript file produced when this
was printed to a color printer and saved as a file.
Contents of the postscript file as viewed in Ghostview (a
Postscript viewer). The opacity was 50% so the dither is a
checkboard, with every other pixel colored.

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.

Example with two gradients in PowerPoint.Postscript file produced when
this was printed to a color printer and saved as a file.
Contents of the postscript file as viewed in Ghostview (a
Postscript viewer).

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.

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.

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.

Example with two gradients in PowerPoint.PDF file produced from
PowerPoint using Adobe Distiller.