In some of my iOS projects I had to display PDFs of documents originally intended for print format. Some of those PDFs would appear horribly on iOS devices, with colors messed up. It was a pretty surprising behaviour, which I initially attributed to bugs in Apple's PDF rendering code.
My first approach to getting around such problems was to use a server-side component powered by Ghostscript to convert each PDF page into an image, that would show up in the right colors, and display that. The advantage of this approach is that it can be fully automated. The disadvantage is that images may show up poorly (pixelated) when zoomed in, depending on their pixel density.
Upon investigating this problem further I discovered a way to fix this problem at its root, that is the source PDF document. Unfortunately it can't be automated easily because it involves running Adobe's Acrobat tool. In the absence of a public API to run that conversion programatically one has the option of using workflow-recording tools like Apple's Automator to drive the Acrobat automatically. While that approach may work, it would be hard to scale in a cost-effective manner.
Another option to handle this may be to use iText to automatically convert CYMK profiles to RGB, or if that's not possible, to at least detect the presence of CYMK profiles and alert the user about the need to convert the PDF manually using Acrobat.
Showing posts with label Adobe. Show all posts
Showing posts with label Adobe. Show all posts
Saturday, May 25, 2013
Friday, May 10, 2013
Rendering office documents in HTML - an idea whose time has come
A while ago I was working on a project that needed rendering PDFs on iOS. There are several ways to do that. On iOS, that is. My client wanted a solution for Android too, and was complaining about the lack of similar capabilities there. Since Android wasn't one of my areas of competence at the time I wasn't involved with that effort directly. However I kept hearing about the need to use some 3rd party, rather expensive, libraries.
So naturally it dawned on me this idea: why don't the "owners" of the PDF format, Adobe, provide a cross-platform viewer. The natural solution would be an HTML based approach, since virtually all popular platforms provide a way to display HTML. At the time I was thinking that the capabilities provided by HTML 5 and CSS 3 should be enough to accomplish the "print-quality" level of rendering offered by Adobe's Acrobat Reader or Apple's Preview. Since Adobe wasn't doing much about it, it seemed a pretty good opportunity. Turns out that wasn't such a bad idea. In fact folks at Crocodoc were banging at it since 2006. Today was the payback. Good for them.
I only heard about them today. A brief glance at their API shows that right now it fetches the documents from some servers, where they're processed and converted from PDF to HTML. With this dependency on a server-side component it doesn't seem to have support for offline viewing. I guess one could hack around and save the generated HTML and all the referenced components (images, CSS, and what not), but that may be a brittle solution. With their new owner I'm sure they'll keep improving their technology and this may well become a compelling cross-platform document rendering solution.
So naturally it dawned on me this idea: why don't the "owners" of the PDF format, Adobe, provide a cross-platform viewer. The natural solution would be an HTML based approach, since virtually all popular platforms provide a way to display HTML. At the time I was thinking that the capabilities provided by HTML 5 and CSS 3 should be enough to accomplish the "print-quality" level of rendering offered by Adobe's Acrobat Reader or Apple's Preview. Since Adobe wasn't doing much about it, it seemed a pretty good opportunity. Turns out that wasn't such a bad idea. In fact folks at Crocodoc were banging at it since 2006. Today was the payback. Good for them.
I only heard about them today. A brief glance at their API shows that right now it fetches the documents from some servers, where they're processed and converted from PDF to HTML. With this dependency on a server-side component it doesn't seem to have support for offline viewing. I guess one could hack around and save the generated HTML and all the referenced components (images, CSS, and what not), but that may be a brittle solution. With their new owner I'm sure they'll keep improving their technology and this may well become a compelling cross-platform document rendering solution.
Subscribe to:
Posts (Atom)