How to keep vector fill pattern (e.g. WMF/EMF) when exporting from PowerPoint to PDF

It helps to think of what you would have to do manually to create such a graphic in vector form. Every instance of the frog that is partially cropped by the pentagon would have to have the curves edited to chop and reconnect them, It would be a huge amount of manual work. So PowerPoint examines the filled shape and concludes the most efficient way of creating such a cropped graphic is to bitmap the fill. If I had to do the same operation manually, I would come to the same conclusion.

The workaround is to use a vector program like InkScape, then manually crop all of the vector shapes before placing it in PowerPoint. You could also use Adobe Illustrator or Corel Draw, if you have access to them. You probably have better things to do with your time.

Hi FamKis,

Aster's suggestion might help if you were applying vector patterns to the slide background, but it won't help with the problem of vector picture fills becoming rasterized in PDF, unfortunately.  I'm seeing the same thing here with EMF-filled shapes, though the rasterization doesn't become apparent until I've zoomed WAY into the PDF.

Are you seeing something different?  

I'm having no luck downloading your example file ... the browser just says "Loading ..." forever.

By the way, are you using PowerPoint's File | Save As and choosing PDF or are you using Adobe's add-in, or some other?

@John:

> So PowerPoint examines the filled shape and concludes the most efficient way of creating such a cropped graphic is to bitmap the fill.

PowerPoint doesn't do such resource considerations. It simply converts any vector fill to a bitmap, even if it is just one frog, or one line, for that matter.

@Steve: Here is another copy of that file. I hope that the downloading works with this site.

The vector fill is converted to a bitmap independent of the way the PPT is converted to PDF (i.e. "Save As", "Export" or "Print" using Adobe, Foxit or PDF-XChange).

Here's a sample of your WMF cropped to an oval as I described, exported as EMF, placed in PowerPoint and saved as PDF. Remarkably, it is not bitmapped: EMF cropped to shape

To do this correctly, you need to use PathFinder in Adobe Illustrator, or ShapeFormat>Merge Shapes in PowerPoint. It's also possible in Corel Draw, but I don't have that installed at the moment.

Thanks John, I know that any existing WMF vector image can be placed in PowerPoint and then also retains its vector quality when being exported to PDF.

Therefore, I could construct my frog-pattern filled shape (or any vector pattern filled shape for that matter) in an external program like Inkscape and then use it in PowerPoint.

However, as mentioned in my OP, I'm specifically looking for using vector pattern fills directly (for editable shapes) in PowerPoint (which PowerPoint can already do perfectly -- other than many even dedicated graphics software packages). The only function that seems to have been forgotten in PowerPoint is the actual vectorial export of such vector fill patterns.

@Steve, maybe you could pull some strings and update the appropriate team at MS about the problem once again, as in the similar case mentioned by AsterT1 above? 

Thank you.

The PowerPoint developers often use bitmapping in PDF exports. You can see this if you apply text effects, the text is no longer text and accessibility goes out the window. You can make a suggestion to add such a feature at the PowerPoint User Voice forum. 

I don't really have any strings to pull other than reporting problems, and generally it's best if the user with the problem does that:

Choose File | Feedback | I don't like something and describe the problem (and be sure to include a link to your example file).

Have your file open so you can also let it include a screenshot.

But it may be that this behavior is intentional/by design. Passing a huge number of vectors (as in your vector fill) can overwhelm a printer driver, and as John's mentioned, cropping vector art like this on the fly would be very processor-intensive, once someone wrote the code to do it in the first place.

Thanks. I still believe that this behavior is not intentional and rather comes from the fact that until recently there was no vector fill feature in PowerPoint, but only bitmap fills were available.

Also, a few 100 or 1000 vectors should not be a problem nowadays. Moreover, a tiled vector fill like this even has the advantage that it actually doesn't create a lot of data, because the tile is stored only once, see for example the tiny file size of a corresponding vector fill file like shown below (which can also be printed without problems):

PowerPoint: 47 kB

PDF: 22 kB

SVG: 120 kB

Download link

I shall prepare a corresponding feedback to Microsoft.

>> Also, a few 100 or 1000 vectors should not be a problem nowadays.

No. But take one of your frogs (in the original format, not once it's in PPT) and open it in a capable drawing package. Note how many control points each of the beziers or splines in the frog entails. Then consider that most printer drivers (any that are not PostScript, as far as I'm aware) can't handle splines and beziers, so the app must convert each curve into a series of straight lines. If it's trying to do a half-decent job of this, each individual curve in each of the frogs might become dozens if not hundreds of straight-line segments. 

>> Moreover, a tiled vector fill like this even has the advantage that it actually doesn't create a lot of data, because the tile is stored only once

Internally, within PPT, certainly.  But when it must be printed or converted to some other format, everything changes. While some printer drivers may be smarter about these things than others, it's been my experience that PPT (all the Office products, really) don't take much advantage of printer driver intelligence; they reduce everything to lowest common denominator.

I'm not *intimately* familiar with the innards of printer drivers, but I'm pretty sure that most output gets sent as EMF. As a test, I exported a vector-filled polygon to EMF, then reimported and ungrouped it down to the lowest component level, which gave me a bitmap image of the fill.