November 3, 2011 at 17:13Development of an electronic, interactive magazine for the iPad
I would like to share my personal experience and methods for creating interactive magazines for the iPad.
Somewhere at the end of 2010, I was contacted with an order to implement an application that would translate printed materials from publishers (magazines, books, brochures) into electronic format for easy reading on an iPad. After long conversations and clarifications, the final task of the technical task was formulated as follows:
Create an iPad app that is an electronic magazine store. The user, having passed a simple registration, replenished the balance to the required amount, could download an available electronic journal and view it. The magazine should be interactive, that is, it had the functions of viewing a set of slides, rotation, video, audio, increasing the font, adding bookmarks, beautiful animations for scrolling pages and a list of things in the same vein. The original journal was a clean pdf, coming directly from the publisher.
In order not to talk for a long time and not to delve into all the problems, we will discard the implementation of the server part, user registration, balance replenishment, synchronization. We proceed directly to the class that should have been responsible for viewing and interacting with the magazine.
I took the project github.com/brow/leaves as the basis of animation , which is still one of the most famous engines in this direction. I really liked the implementation of bending and page turning effects. The initial view of the engine is shown in the figure below.
After I changed the engine for myself, made functions for displaying previews, adding pages to bookmarks and other nuances, received a pdf version of a 40 page magazine from a publisher that weighed 144MB and uploaded to a real device, I encountered a fatal problem. When flipping a random page, the magazine just crashed.
Turning to the logs, I encountered an error:
data formatters temporarily unavailable
In fact, the iPad has run out of virtual RAM, which is allowed to use the application. Digging a lot deeper using tools - memory allocations, I noticed that when rendering the next pdf page, the allocated memory is accumulated and not freed.
Of course, you might think that I did not correctly use CGPDFPageRelease and other operations related to freeing and cleaning memory. But testing the application for more than a month, having studied hundreds of Internet posts, problems and solutions, the only reasonable explanation on the topic “Rendering large pdfs” is that iOs sdk, when calling the CGPDFPageRelease method, does not really destroy memory. As it was written on the official apple website (unfortunately, I could not find the link already) CGPDF caches page tiles in memory so that the next time the call is rendered, rendering will be faster. That is, there was a problem with such an internal cache mechanism from apple, which consistently did not allow reading heavy pdf-magazines.
In a cold sweat, gripping by the deadlines, I began to search for optimal solutions to this problem. Additionally, the customer did not really like the slow rendering of CATiledLayer, although it was difficult to explain to him that one page weighed at least 7 MB. I tried to download my miracle pdf file from the publisher to UIWebView, as a result, the idea failed completely. The web component fell even faster than my engine, already full of crutches.
We turn to the solutions to the problem :
In the end, I wanted to write a pdf parser that would take out all the pictures and text from the file. Then I overtook them in my format, and displayed them in the application using standard tools (for example, UIImageView, UITextView or CoreText). I have not mastered reading a ton of Adobe manuals, although I still consider this a promising idea. Finding a normal pdf parser on the Internet did not work either - everyone was tearing off the images either clumsily or not at all. About the fact that I get texts from pdf at least in the .doc or .html format in general I am silent.
My final implementation represented the following mechanism.
With the help of the Quark Xpress publishing program, I cut out all heavy pictures from pdf, additionally compressed them, changed the size, color space. Then I developed my pseudo scripting language (where html-like tags were used), for example:
(page num = 1)
(pdf) 1 (/ pdf)
(image) 0,0,768,1024, first_page_image.png (/ image)
(text ) ..... (text)
(video) ..... (video)
(slide) ..... (slide)
(3d) .... (3d)
(/ page)
Then light jpg previews were created for each page. When the page turning effect ended on the preview, a CATiledLayer was added which began to draw pdf-ku with cut out images (that is, only text and simple elements). At the same time, a file with tags was parsed, and all interactive elements were added to the background or foreground, handlers were hung on them, animations started in the right places, special “activators” elements were added on top of them to interact with interactive elements.
As a result, my application did not crash, it worked fast enough and met all the requirements of the ToR.
About a month ago, a similar proposal came up again for the implementation of an electronic journal. But I was forced to refuse, because I did not want to go through all this hemorrhage again. But for my own curiosity, I analyzed new stable free-engines on the Internet. Of the new ones, I liked github.com/vfr/Reader.
But as soon as I poured into it the same pdf-ku with which I had suffered for so long a year ago, it also fell. All official apple engines are falling too.
If anyone wants to share their experience, or to assure that his engine solves the problem of reading giant pdf-ok - write, I will be happy to share more detailed tips and throw off the very malicious pdf-ku, which, most likely, will drop your engine.
Somewhere at the end of 2010, I was contacted with an order to implement an application that would translate printed materials from publishers (magazines, books, brochures) into electronic format for easy reading on an iPad. After long conversations and clarifications, the final task of the technical task was formulated as follows:
Create an iPad app that is an electronic magazine store. The user, having passed a simple registration, replenished the balance to the required amount, could download an available electronic journal and view it. The magazine should be interactive, that is, it had the functions of viewing a set of slides, rotation, video, audio, increasing the font, adding bookmarks, beautiful animations for scrolling pages and a list of things in the same vein. The original journal was a clean pdf, coming directly from the publisher.
In order not to talk for a long time and not to delve into all the problems, we will discard the implementation of the server part, user registration, balance replenishment, synchronization. We proceed directly to the class that should have been responsible for viewing and interacting with the magazine.
I took the project github.com/brow/leaves as the basis of animation , which is still one of the most famous engines in this direction. I really liked the implementation of bending and page turning effects. The initial view of the engine is shown in the figure below.
After I changed the engine for myself, made functions for displaying previews, adding pages to bookmarks and other nuances, received a pdf version of a 40 page magazine from a publisher that weighed 144MB and uploaded to a real device, I encountered a fatal problem. When flipping a random page, the magazine just crashed.
Turning to the logs, I encountered an error:
data formatters temporarily unavailable
In fact, the iPad has run out of virtual RAM, which is allowed to use the application. Digging a lot deeper using tools - memory allocations, I noticed that when rendering the next pdf page, the allocated memory is accumulated and not freed.
Of course, you might think that I did not correctly use CGPDFPageRelease and other operations related to freeing and cleaning memory. But testing the application for more than a month, having studied hundreds of Internet posts, problems and solutions, the only reasonable explanation on the topic “Rendering large pdfs” is that iOs sdk, when calling the CGPDFPageRelease method, does not really destroy memory. As it was written on the official apple website (unfortunately, I could not find the link already) CGPDF caches page tiles in memory so that the next time the call is rendered, rendering will be faster. That is, there was a problem with such an internal cache mechanism from apple, which consistently did not allow reading heavy pdf-magazines.
In a cold sweat, gripping by the deadlines, I began to search for optimal solutions to this problem. Additionally, the customer did not really like the slow rendering of CATiledLayer, although it was difficult to explain to him that one page weighed at least 7 MB. I tried to download my miracle pdf file from the publisher to UIWebView, as a result, the idea failed completely. The web component fell even faster than my engine, already full of crutches.
We turn to the solutions to the problem :
In the end, I wanted to write a pdf parser that would take out all the pictures and text from the file. Then I overtook them in my format, and displayed them in the application using standard tools (for example, UIImageView, UITextView or CoreText). I have not mastered reading a ton of Adobe manuals, although I still consider this a promising idea. Finding a normal pdf parser on the Internet did not work either - everyone was tearing off the images either clumsily or not at all. About the fact that I get texts from pdf at least in the .doc or .html format in general I am silent.
My final implementation represented the following mechanism.
With the help of the Quark Xpress publishing program, I cut out all heavy pictures from pdf, additionally compressed them, changed the size, color space. Then I developed my pseudo scripting language (where html-like tags were used), for example:
(page num = 1)
(pdf) 1 (/ pdf)
(image) 0,0,768,1024, first_page_image.png (/ image)
(text ) ..... (text)
(video) ..... (video)
(slide) ..... (slide)
(3d) .... (3d)
(/ page)
Then light jpg previews were created for each page. When the page turning effect ended on the preview, a CATiledLayer was added which began to draw pdf-ku with cut out images (that is, only text and simple elements). At the same time, a file with tags was parsed, and all interactive elements were added to the background or foreground, handlers were hung on them, animations started in the right places, special “activators” elements were added on top of them to interact with interactive elements.
As a result, my application did not crash, it worked fast enough and met all the requirements of the ToR.
About a month ago, a similar proposal came up again for the implementation of an electronic journal. But I was forced to refuse, because I did not want to go through all this hemorrhage again. But for my own curiosity, I analyzed new stable free-engines on the Internet. Of the new ones, I liked github.com/vfr/Reader.
But as soon as I poured into it the same pdf-ku with which I had suffered for so long a year ago, it also fell. All official apple engines are falling too.
If anyone wants to share their experience, or to assure that his engine solves the problem of reading giant pdf-ok - write, I will be happy to share more detailed tips and throw off the very malicious pdf-ku, which, most likely, will drop your engine.