IPad के लिए एक इलेक्ट्रॉनिक, इंटरैक्टिव पत्रिका का विकास

मैं iPad के लिए इंटरैक्टिव पत्रिका बनाने के लिए अपने व्यक्तिगत अनुभव और तरीकों को साझा करना चाहूंगा।

कहीं न कहीं 2010 के अंत में, मुझे एक ऐसे आवेदन को लागू करने के आदेश के साथ संपर्क किया गया था जो एक iPad पर आसानी से पढ़ने के लिए प्रकाशकों (पत्रिकाओं, पुस्तकों, ब्रोशर) से मुद्रित सामग्री का अनुवाद करेगा। लंबी बातचीत और स्पष्टीकरण के बाद, तकनीकी कार्य का अंतिम कार्य निम्नानुसार तैयार किया गया था:

एक iPad ऐप बनाएं जो एक इलेक्ट्रॉनिक पत्रिका स्टोर है। उपयोगकर्ता, एक साधारण पंजीकरण पास कर रहा है, आवश्यक राशि के लिए शेष राशि को फिर से भरता है, एक उपलब्ध इलेक्ट्रॉनिक पत्रिका डाउनलोड कर सकता है और इसे देख सकता है। पत्रिका इंटरएक्टिव होनी चाहिए, यानी इसमें स्लाइड, रोटेशन, वीडियो, ऑडियो का एक सेट देखने, फॉन्ट बढ़ाने, बुकमार्क जोड़ने, स्क्रॉलिंग पेज के लिए सुंदर एनिमेशन और एक ही नस में चीजों की एक सूची देखने के कार्य थे। स्रोत पत्रिका एक साफ पीडीएफ थी, जो प्रकाशक से सीधे आ रही थी।

लंबे समय तक बात नहीं करने और सभी समस्याओं को हल करने के लिए नहीं, हम सर्वर भाग, उपयोगकर्ता पंजीकरण, शेष पुनःपूर्ति, सिंक्रनाइज़ेशन के कार्यान्वयन को छोड़ देंगे। हम सीधे उस वर्ग के लिए आगे बढ़ते हैं, जिसे पत्रिका को देखने और बातचीत करने के लिए जिम्मेदार माना जाता था।

मैंने एनीमेशन के आधार के रूप में प्रोजेक्ट github.com/brow/leaves लिया, जो अभी भी इस दिशा में सबसे प्रसिद्ध इंजनों में से एक है। मुझे वास्तव में फोल्डिंग और पेज टर्निंग इफेक्ट्स का कार्यान्वयन पसंद आया। इंजन का प्रारंभिक दृश्य नीचे दिए गए आंकड़े में दिखाया गया है।



जब मैंने अपने लिए इंजन को बदल दिया, तो पूर्वावलोकन प्रदर्शित करने के लिए कार्य किए, पृष्ठों को बुकमार्क और अन्य बारीकियों से जोड़ा, एक प्रकाशक से 40 पृष्ठ पत्रिका का एक पीडीएफ संस्करण प्राप्त किया, जिसका वजन 144 एमबी था और एक वास्तविक डिवाइस पर अपलोड किया गया था, मुझे एक भयंकर समस्या का सामना करना पड़ा। एक यादृच्छिक पृष्ठ को फ़्लिप करते समय, पत्रिका बस दुर्घटनाग्रस्त हो गई।

लॉग की ओर मुड़ते हुए, मुझे एक त्रुटि का सामना करना पड़ा:
डेटा स्वरूपण अस्थायी रूप से अनुपलब्ध हैं
वास्तव में, iPad वर्चुअल रैम से बाहर चला गया है, जिसे एप्लिकेशन का उपयोग करने की अनुमति है। टूल्स - मेमोरी एलोकेशन का उपयोग करके बहुत गहरा खोदते हुए, मैंने देखा कि अगले पीडीऍफ़ पेज को प्रस्तुत करते समय, आवंटित मेमोरी संचित हो जाती है और मुक्त नहीं होती है।

बेशक, आप सोच सकते हैं कि मैंने सही ढंग से CGPDFPageRelease और अन्य कार्यों का उपयोग नहीं किया है जो कि मेमोरी को मुक्त और सफाई से संबंधित हैं। लेकिन एक महीने से अधिक समय तक आवेदन का परीक्षण करना, सैकड़ों इंटरनेट पोस्ट, समस्याओं और समाधानों का अध्ययन करना, "बड़े pdfs का प्रतिपादन" विषय पर एकमात्र उचित स्पष्टीकरण यह है कि iOs sdk, जब CGPDFPageRelease विधि को बुलाता है, वास्तव में स्मृति को नष्ट नहीं करता है। जैसा कि यह आधिकारिक ऐप्पल वेबसाइट पर लिखा गया था (दुर्भाग्य से, मुझे पहले से लिंक नहीं मिल पाया) सीजीपीडीएफ कैश पेज मेमोरी में टाइल करता है ताकि अगली बार जब कॉल किया जाए, तो रेंडरिंग तेज हो। यही है, सेब से इस तरह के आंतरिक कैश तंत्र के साथ एक समस्या थी, जो लगातार भारी पीडीएफ-पत्रिकाओं को पढ़ने से रोकती थी।

एक ठंडे पसीने में, समय सीमा के अनुसार, मैंने इस समस्या के इष्टतम समाधान की खोज शुरू कर दी। इसके अतिरिक्त, ग्राहक वास्तव में CATiledLayer के धीमे प्रतिपादन को पसंद नहीं करते थे, हालांकि उन्हें यह समझाना मुश्किल था कि एक पृष्ठ का वजन कम से कम 7 एमबी था। मैंने प्रकाशक से UIWebView तक अपनी चमत्कारिक पीडीएफ फाइल डाउनलोड करने की कोशिश की, परिणामस्वरूप, विचार पूरी तरह से विफल हो गया। पहले से ही बैसाखी से भरा मेरे घटक की तुलना में वेब घटक और भी तेजी से गिर गया।

हम समस्या के समाधान की ओर मुड़ते हैं :

अंत में, मैं एक पीडीएफ पार्सर लिखना चाहता था जो फ़ाइल से सभी चित्रों और पाठ को बाहर निकाल देगा। फिर मैंने उन्हें अपने प्रारूप में आगे निकाल दिया, और उन्हें मानक उपकरण (उदाहरण के लिए, UIImageView, UITextView या CoreText) का उपयोग करके आवेदन में प्रदर्शित किया। मुझे Adobe मैनुअल का एक टन पढ़ने में महारत हासिल नहीं है, हालांकि मैं अभी भी इसे एक आशाजनक विचार मानता हूं। इंटरनेट पर एक सामान्य पीडीएफ पार्सर खोजने से भी काम नहीं हुआ - हर कोई छवियों को अलग-थलग कर रहा था या तो अनाड़ी था या बिल्कुल नहीं। पीडीएफ से ग्रंथों को कम से कम .doc या .html प्रारूप में प्राप्त करने के बारे में मैं आमतौर पर चुप रहता हूं।

मेरा अंतिम कार्यान्वयन निम्नलिखित तंत्र का प्रतिनिधित्व करता है।
क्वार्क Xpress प्रकाशन कार्यक्रम की मदद से, मैंने पीडीएफ से सभी भारी चित्रों को काट दिया, इसके अलावा उन्हें संकुचित कर दिया, आकार, रंग स्थान बदल दिया। फिर मैंने अपनी छद्म पटकथा भाषा विकसित की (जहाँ html- जैसे टैग का उपयोग किया गया था), उदाहरण के लिए:

(पेज संख्या = 1)
(pdf) 1 (/ pdf)
(छवि) 0,0,768,1024, first_page_image.png (/ छवि)
(पाठ) ..... (पाठ)
(वीडियो) ..... (वीडियो)
(स्लाइड) ..... (स्लाइड)
(3 डी) .... (3 डी)
(/ पृष्ठ)

फिर प्रत्येक पृष्ठ के लिए हल्के jpg पूर्वावलोकन बनाए गए थे। जब पृष्ठ मोड़ प्रभाव पूर्वावलोकन पर समाप्त हो गया, तो एक CATiledLayer जोड़ा गया, जो कट-आउट छवियों (यानी केवल पाठ और सरल तत्वों) के साथ पीडीएफ-कू को आकर्षित करना शुरू कर दिया। उसी समय, टैग के साथ एक फ़ाइल पार्स की गई थी, और सभी इंटरैक्टिव तत्वों को पृष्ठभूमि या अग्रभूमि में जोड़ा गया था, हैंडलर उन पर लटका दिए गए थे, सही स्थानों पर एनिमेशन शुरू हो गए थे, विशेष "एक्टीवेटर" तत्वों को उन इंटरैक्टिव तत्वों के साथ बातचीत करने के लिए जोड़ा गया था।

नतीजतन, मेरा आवेदन दुर्घटनाग्रस्त नहीं हुआ, इसने काफी तेजी से काम किया और टीओआर की सभी आवश्यकताओं को पूरा किया।

लगभग एक महीने पहले, एक समान प्रस्ताव फिर से इलेक्ट्रॉनिक पत्रिका के कार्यान्वयन के लिए आया था। लेकिन मुझे मना करने के लिए मजबूर किया गया था, क्योंकि मैं इस सभी रक्तस्राव के माध्यम से फिर से नहीं जाना चाहता था। लेकिन अपनी जिज्ञासा के लिए, मैंने इंटरनेट पर नए स्थिर मुक्त इंजनों का विश्लेषण किया। नए लोगों में से, मुझे github.com/vfr/Reader पसंद है
लेकिन जैसे ही मैंने उसमें डाला वही pdf-ku जिसके साथ मैं एक साल पहले इतने लंबे समय तक पीड़ित था, वह भी गिर गया। सभी आधिकारिक सेब इंजन भी गिर रहे हैं।

यदि कोई भी अपना अनुभव साझा करना चाहता है, या यह आश्वासन देना चाहता है कि उसका इंजन विशालकाय पीडीएफ-ओके पढ़ने की समस्या को हल करता है - तो मुझे अधिक विस्तृत सुझाव साझा करने और बहुत ही दुर्भावनापूर्ण पीडीएफ-कू को फेंकने में खुशी होगी, जो आपके इंजन को छोड़ने की संभावना है।