Development of electronic, interactive magazine for iPad
I would like to share my personal knowledge and methods for creating interactive magazines for the iPad.
Somewhere in late 2010, they turned to me with an order to implement an application that would allow translating printed materials of publishing houses (magazines, books, brochures) into electronic format for easy reading on iPad. After long conversations and clarifications, the final task of the technical task was formulated as follows:
Create an iPad app that is an online magazine store. The user, having passed a simple registration, replenishing the balance to the required amount, could download the available electronic journal and view it. The magazine should be interactive, that is, it had functions for viewing a set of slides, rotation, video, audio, increasing the font, adding bookmarks, beautiful animation for scrolling through pages and another list of things in the same vein. The original magazine was a clean pdf, coming in direct from the publisher.
In order not to talk for a long time and not to dig into all the problems, let us discard the implementation of the server part, user registration, recharge, synchronization. We proceed directly to the class that was supposed to be responsible for viewing and interacting with the magazine.
')
I took the github.com/brow/leaves project as the basis for the animation, which is still one of the most famous engines in this direction. I really liked the realization of the effects of turning over and turning pages. 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, I received a pdf-version of a 40 page magazine from a publisher that weighed 144MB and uploaded to a real device, ran into a fatal problem. With a random page flipping, the magazine just flew out.
Turning to the logs, I encountered an error:
data formatters temporarily unavailable
In fact, the iPad has run out of virtual storage, 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 released.
You can certainly think that I did not correctly use CGPDFPageRelease and other operations related to the release and cleaning of memory. But testing the application for more than a month, examining hundreds of Internet posts, problems and solutions, the only reasonable explanation on the topic “Rendering large pdfs” is that iOs sdk does not really destroy memory when calling the CGPDFPageRelease method. As it was written on the official apple website (unfortunately, the link could not be found) CGPDF caches the page tiles in memory so that the next time they are rendered, the rendering will be faster. That is, there was a problem of such an internal cache mechanism from apple, which consistently prevented reading heavy pdf journals.
In cold sweat, grief over time, I began to look for optimal solutions to the current problem. Additionally, the customer didn’t really like the slow drawing of CATiledLayer, although it was difficult to explain to him that one page weighed at least 7MB. I tried to download my wonder-pdf file from the publisher in UIWebView, as a result, the idea suffered a complete fiasco. The web component fell even faster than my engine, already full of crutches.
Moving on to solving 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 output them in the application by standard means (for example, UIImageView, UITextView or CoreText). I haven’t mastered reading a ton of Adobe manuals, although I still consider this a promising idea. Finding a normal pdf parser on the Internet didn’t work either - everyone was tearing up images either clumsily or doing something completely wrong. About getting texts from pdf, at least in .doc or .html format, generally keep quiet.
My final implementation was the following mechanism.
With the help of the Quark Xpress publishing program, I cut out all the heavy pictures from pdf-files, additionally squeezed them, changed the size, the color space. Then I developed my pseudo script 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 scrolling effect ended on a preview, a CATiledLayer was added, which began to draw a pdf with cut out pictures (that is, only text and simple elements). In parallel, the file with tags was parsed, and all interactive elements were added to the background or the 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 fall, it worked quickly enough and met all the requirements of the TZ.
About a month ago, there was again a similar proposal on the implementation of an electronic journal. But I was forced to give up, because I did not want to go through all this haemorrhoid again. But for my own curiosity, I analyzed the new stable free-engines on the Internet. From new liked github.com/vfr/Reader
But as soon as I poured into him the very same pdf-ku with which he had been suffering a year ago for so long, he, too, fell. All official apple engines fall as well.
If anyone wants to share experience, or 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 most malicious pdf-ku, which, most likely, will drop your engine.
Somewhere in late 2010, they turned to me with an order to implement an application that would allow translating printed materials of publishing houses (magazines, books, brochures) into electronic format for easy reading on iPad. After long conversations and clarifications, the final task of the technical task was formulated as follows:
Create an iPad app that is an online magazine store. The user, having passed a simple registration, replenishing the balance to the required amount, could download the available electronic journal and view it. The magazine should be interactive, that is, it had functions for viewing a set of slides, rotation, video, audio, increasing the font, adding bookmarks, beautiful animation for scrolling through pages and another list of things in the same vein. The original magazine was a clean pdf, coming in direct from the publisher.
In order not to talk for a long time and not to dig into all the problems, let us discard the implementation of the server part, user registration, recharge, synchronization. We proceed directly to the class that was supposed to be responsible for viewing and interacting with the magazine.
')
I took the github.com/brow/leaves project as the basis for the animation, which is still one of the most famous engines in this direction. I really liked the realization of the effects of turning over and turning pages. 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, I received a pdf-version of a 40 page magazine from a publisher that weighed 144MB and uploaded to a real device, ran into a fatal problem. With a random page flipping, the magazine just flew out.
Turning to the logs, I encountered an error:
data formatters temporarily unavailable
In fact, the iPad has run out of virtual storage, 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 released.
You can certainly think that I did not correctly use CGPDFPageRelease and other operations related to the release and cleaning of memory. But testing the application for more than a month, examining hundreds of Internet posts, problems and solutions, the only reasonable explanation on the topic “Rendering large pdfs” is that iOs sdk does not really destroy memory when calling the CGPDFPageRelease method. As it was written on the official apple website (unfortunately, the link could not be found) CGPDF caches the page tiles in memory so that the next time they are rendered, the rendering will be faster. That is, there was a problem of such an internal cache mechanism from apple, which consistently prevented reading heavy pdf journals.
In cold sweat, grief over time, I began to look for optimal solutions to the current problem. Additionally, the customer didn’t really like the slow drawing of CATiledLayer, although it was difficult to explain to him that one page weighed at least 7MB. I tried to download my wonder-pdf file from the publisher in UIWebView, as a result, the idea suffered a complete fiasco. The web component fell even faster than my engine, already full of crutches.
Moving on to solving 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 output them in the application by standard means (for example, UIImageView, UITextView or CoreText). I haven’t mastered reading a ton of Adobe manuals, although I still consider this a promising idea. Finding a normal pdf parser on the Internet didn’t work either - everyone was tearing up images either clumsily or doing something completely wrong. About getting texts from pdf, at least in .doc or .html format, generally keep quiet.
My final implementation was the following mechanism.
With the help of the Quark Xpress publishing program, I cut out all the heavy pictures from pdf-files, additionally squeezed them, changed the size, the color space. Then I developed my pseudo script 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 scrolling effect ended on a preview, a CATiledLayer was added, which began to draw a pdf with cut out pictures (that is, only text and simple elements). In parallel, the file with tags was parsed, and all interactive elements were added to the background or the 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 fall, it worked quickly enough and met all the requirements of the TZ.
About a month ago, there was again a similar proposal on the implementation of an electronic journal. But I was forced to give up, because I did not want to go through all this haemorrhoid again. But for my own curiosity, I analyzed the new stable free-engines on the Internet. From new liked github.com/vfr/Reader
But as soon as I poured into him the very same pdf-ku with which he had been suffering a year ago for so long, he, too, fell. All official apple engines fall as well.
If anyone wants to share experience, or 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 most malicious pdf-ku, which, most likely, will drop your engine.
Source: https://habr.com/ru/post/131855/
All Articles