Obviously, requirements for print are quite the opposite from mobile: print quality is important for advertisers in today’s high gloss magazines and that requires high resolution images. Interesting design frequently comes with complex rendering tasks e.g. for transparent objects like shadows or complex diagrams. Not an issue for print, since print houses have fast internal production networks and output devices are high-performance dedicated computers. However, when it comes to tablets, not every user will have a fast internet connection or one of the newest, fast devices.
One approach would be to generate two different outputs from the editorial and page layout system. Unfortunately, that is not ideal: last-minute changes are frequent and it is not always possible to get back to the original page. In addition, many pages have adverts, so that access to the original file is not possible. What is needed, is a reliable process that takes the print PDF page and converts it into a small and performant page. Since the number of magazines that is published in such an app is large, you definitely need to do that in an automated process without any human interaction.
To begin with the most obvious: you would convert the print color space CMYK into RGB. In addition, you do not need 300 ppi. Even if you want to support HD devices, you can probably accept around 150 ppi [-> DEV?]. Both already reduce image and therefore PDF sizes.
Improving display performance, even for complex graphics (transparency, auto-generated vector graphics in diagrams), is a more demanding step:
Transparency flattening reduces transparency (which is necessary in this context), but may again introduce complex areas consisting of thousands of objects created by the flattening engine. Additionally, some flatteners divide larger images into smaller pieces. Unfortunately, many viewers display thin lines between these images (even if there is no gap between them) - something you want to avoid in tablet publishing!
For this reason, it makes sense to raster the whole page which would 'reduce' transparency, merge diagrams consisting of large numbers of vector elements ... Since we do not know what PDF input files we get from print - so that they might already be transparency flattened - it is good to see that by this process also visible lines between image fragments created by a transparency flattener (see above) go away.
Not a nice thing is that flattening also converts text into image, which makes it more difficult to read and gives the whole page a somewhat 'cheap' appearance.
What you would want to do is to separate text from the rest of the page, raster everything except text into a single image and switch the text on again. This will create fast pages from every kind of input and keep text quality.
But there is one remaining problem: in many cases text is covered, sometimes only partly. Just think of the model (women or man) on the cover of the magazine where the model’s head stands in front of the magazine title. In the process described above, the text would be either behind (invisible) or above the page image (in front of the model’s head). What you need to do is to detect such covered text and combine it with the rasterized part.
Today’s prepress PDF automation engines are able to analyze page content in context, which allows them to identify objects that are (partly) overlapped. We have explained that in a previous blog post about Sifter in pdfToolbox.
This is more difficult than you would think, because the engine needs to calculate object areas and compare them with each other - something that the combination of human eye and brain can easily do, but is surprisingly demanding for computers. Anyhow, modern PDF technology can do that as well. Seen with a bird’s eye what you do is to create two variants of your PDF page: one with all graphics (images, smooth shades, vector and text that is partly covered) and one with all text. Then you raster the first page and put the text on top of it.