Pdf.js: कोणीय + pdf.js की IE 11 संगतता सक्षम करें

को निर्मित 24 मार्च 2017 · 10टिप्पणियाँ · स्रोत: mozilla/pdf.js

विन्यास:

वेब ब्राउज़र और उसका संस्करण: IE 11
ऑपरेटिंग सिस्टम और उसका संस्करण: कोई भी
PDF.js संस्करण: 1.4.0
AngularJs संस्करण: 1.5.11

समस्या को पुन: उत्पन्न करने के लिए कदम:

स्वचालित बूटस्ट्रैपिंग के साथ AngularJS 1.5.11 का उपयोग करें
कोणीय के स्क्रिप्ट टैग से पहले PDF.js संस्करण 1.4.0 शामिल करें

अपेक्षित व्यवहार क्या है? (स्क्रीनशॉट जोड़ें)

PDF.js . के साथ कोणीय पूरी तरह से एक साथ काम करता है
PDF.js अनुपलब्ध API को ऐसे फ़ंक्शन में लपेटता है जो मूल संस्करण उपलब्ध नहीं होने पर शिम्ड संस्करण का उपयोग करेगा।

क्या गलत हुआ? (स्क्रीनशॉट जोड़ें)

देखें https://github.com/angular/angular.js/issues/15772
वर्तमान में pdf.js document.currentScript को परिभाषित करता है लेकिन link.origin और न ही link.protocol को परिभाषित करता है। यदि कोणीय शुरू होता है तो यह जांचता है कि क्या इसे स्वचालित रूप से बूटस्ट्रैप करने की अनुमति है, यह वर्तमान स्क्रिप्ट के लिए जांच करता है और मानता है कि यह आईई को फ़िल्टर करने के लिए पर्याप्त होगा, जिसका अर्थ है कि यदि वर्तमान स्क्रिप्ट परिभाषित नहीं है तो हम स्वचालित रूप से बूटस्ट्रैप कर सकते हैं। यह चेक pdf.js के संयोजन में काम नहीं करेगा।

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

किसी दर्शक से लिंक करें (यदि mozilla.github.io/pdf.js के अलावा किसी अन्य साइट पर या Firefox/Chrome एक्सटेंशन के रूप में होस्ट किया गया है):
http://plnkr.co/edit/YFCQM2Px0QU0KnGzsAlM?p=preview

1-other

स्रोत

Wolfke85

👍1

सभी 10 टिप्पणियाँ

कुछ हद तक IE11-अपूर्ण सुरक्षा जांच कोणीय तर्क से PDF.js पॉलीफ़िल में दोष स्थानांतरित करने जैसा लगता है ... ठीक है। इस अंतर को ठीक करने के लिए एक साधारण बग के रूप में चिह्नित करना:

document.location.origin को नए URL(document.location.href.origin) पर सेट किया जाना चाहिए यदि 'मूल' संपत्ति अनुपस्थित है
HTMLScriptElement.prototype में उपरोक्त के समान तर्क के साथ मूल और प्रोटोकॉल गेटर्स होंगे।

yurydelendik 24 मार्च 2017

@yurydelendik मेरे लिए यह उस स्थिति के अनुरूप है जहां कुछ वेब एपीआई को अपना नाम बदलना पड़ा क्योंकि MooTools आंशिक पॉलीफिल लागू कर रहा था और वेब पर कोड इसके आधार पर शुरू हुआ।

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

संक्षेप में: पुस्तकालय कोड उन वस्तुओं को संशोधित नहीं करना चाहिए जो उसके पास नहीं हैं, उदाहरण के लिए देशी ब्राउज़र ग्लोबल्स।

mgol 24 मार्च 2017

पॉलीफिलिंग जोखिम भरा है

@mgol ओह, मैं सहमत हूँ। संपूर्ण PDF.js व्यूअर एप्लिकेशन अपने स्वयं के सैंडबॉक्स में होना चाहिए (मैं iframe की अनुशंसा करता हूं), लेकिन लोग इसे बड़े ऐप्स के भीतर उपयोग करते रहते हैं। इसलिए हमें उसी के अनुसार प्रतिक्रिया देनी होगी।

yurydelendik 24 मार्च 2017

पुस्तकालय कोड उन वस्तुओं को संशोधित नहीं करना चाहिए जो उसके पास नहीं हैं, उदाहरण के लिए देशी ब्राउज़र ग्लोबल्स।

आइए एक और उदाहरण लेते हैं, बिना टाइप की गई सरणियाँ और Promise PDF.js लाइब्रेरी समान नहीं होगी। और वैश्विक वस्तुओं को संशोधित न करके हम अपने कोड को अपठनीय और शायद अधिकांश आधुनिक ब्राउज़रों के लिए कम प्रदर्शनकारी बना देंगे।

yurydelendik 24 मार्च 2017

आइए एक और उदाहरण लेते हैं, बिना टाइप की गई सरणियाँ और Promise PDF.js लाइब्रेरी समान नहीं होगी। और वैश्विक वस्तुओं को संशोधित न करके हम अपने कोड को अपठनीय और शायद अधिकांश आधुनिक ब्राउज़रों के लिए कम प्रदर्शनकारी बना देंगे।

जरुरी नहीं। आप वैरिएबल का अपना आंतरिक सेट रख सकते हैं जो ग्लोबल्स को छाया देता है। यह सभी मामलों को कवर नहीं कर सकता है लेकिन कम से कम वादे ठीक होने चाहिए। कुछ इस तरह:

var Promise = window.Promise || PROMISE_POLYFILL;

PDF.js के शीर्ष पर। उस स्थिति में आप वैश्विक को नहीं छू रहे हैं और आप अभी भी बिना किसी बदलाव के अपने कोड में Promise का उपयोग कर सकते हैं।

यह आधुनिक ब्राउज़रों में प्रदर्शन को प्रभावित नहीं करना चाहिए क्योंकि यह उनके लिए एक साधारण उपनाम है।

मैं समझता हूं कि यह सभी मामलों में इतना आसान नहीं हो सकता है, हालांकि (उदाहरण के लिए यदि केवल कुछ तरीकों को पॉलीफिल करने की आवश्यकता है)

mgol 24 मार्च 2017

PDF.js कोड ES6 मॉड्यूल का उपयोग करने के लिए रूपांतरित हो रहा है। उपरोक्त दृष्टिकोण समस्याग्रस्त एटीएम हो सकता है, जब तक कि कोई पैकेजर स्वचालित रूप से पॉलीफिल प्रदान नहीं करेगा।

मैं इस मुद्दे को कोणीय तर्क या pdf.js संगतता दृष्टिकोण के बारे में चर्चा में नहीं बदलना चाहूंगा, हमारे पॉलीफ़िल को ठीक करना अच्छा होगा इसलिए हम कोणीय के साथ अच्छा खेलेंगे। एक जनसंपर्क का स्वागत है :)

yurydelendik 24 मार्च 2017

दूसरे विचार पर, आइए इस मुद्दे को बंद कर दें क्योंकि यह ठीक नहीं होगा। इस बात की कोई पुष्टि नहीं है कि Angular+PDF.js+IE11 वास्तविक दुनिया का उपयोग करता है, अगर वहाँ है, तो Angular.js को पैच करके कोणीय पक्ष पर फिक्स को आसान बनाया जा सकता है।

yurydelendik 14 जून 2017

👎9

अरे वहाँ, मुझे पता है कि यह एक पुराना विषय है, लेकिन मैं ऊपर वर्णित समस्या में भाग रहा हूँ।

मेरे पास एक प्रोजेक्ट है जहां मैं PDF.js के साथ Angular 5 का उपयोग कर रहा हूं और मुझे IE11 का समर्थन करने की आवश्यकता है। मैं एंगुलर के लिए नौसिखिया हूं इसलिए मुझे बिल्कुल यकीन नहीं है कि मैं एंगुलर.जेएस को कैसे पैच करूंगा - क्या आप मुझे कुछ मार्गदर्शन दे सकते हैं कि मैं इस दोष से कैसे निपट सकता हूं? अग्रिम में धन्यवाद।

elliotstoner 20 अग॰ 2018

@elliotstoner यह मुद्दा AngularJS संगतता के बारे में है, न कि कोणीय (2+) और केवल तभी लागू होता है जब आप मैन्युअल बूटस्ट्रैपिंग के बजाय ng-app उपयोग करते हैं। कोणीय 2+ स्वचालित बूटस्ट्रैपिंग का भी समर्थन नहीं करता है, इसलिए यह समस्या वहां लागू नहीं होगी।

mgol 20 अग॰ 2018

@mgol आह ठीक है - मैं फिर एक नया मुद्दा

elliotstoner 20 अग॰ 2018

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Pdf.js: कोणीय + pdf.js की IE 11 संगतता सक्षम करें

सभी 10 टिप्पणियाँ

संबंधित मुद्दों