Using a QLPreviewController/UIWebView to preview Word documents which have merge fields

Question

We are currently working on an iPad application which will have the following functionality:

• User provides credentials, logs in.
• Set of tasks are retrieved via a web service, which contain base64 encoded documents of varying formats. (.doc, .docx, .rtf etc.)
• The document titles are displayed in a popover list.
• When a document is selected, it is pushed out to a control to render and display it.

Our problem begins when we attempt to push out Word documents which contain bound document properties (merge fields) - the data is not being shown, leaving us with documents which contain for example "Address Line 1, Address Line 2, Postcode", as opposed to the actual values.

Supporting merge fields is a fairly high priority business case for us, so it's important that we get this working if possible.

So far, we've tried using both a QLPreviewController and a UIWebView to render the documents, and the behaviour seems to be the same with both controls.

Has anyone experienced this issue before, and if so how did you work around it?

Answer 1

As suggested previously, it looks like this is simply not supported by the preview engine used by OSX/iOS.

Our eventual solution was to use a conversion library on the server side to convert our doc, docx or RTF documents to PDF (which both populates the merge fields and seems to be well supported by the previewer) before they are sent to the iPad. This has introduced some latency into the web service, however it seems to be the best solution for now.

Answer 2

This appears to be fixed in iOS 6, however QLPreviewController could use a lot of further work to make it useful in other views / interactions with UIGestures.

Answer 3

It's possible the Quick Look engine underneath does not support that particular feature of Word.

Did you try to look at the same document on Mac OS X using Desktop's Quick Look (in Finder)?

If your document does not display as you want there, then it won't be much better on iOS as both are using the same rendering engine. And in this case, you should file a bug to Apple.