दूरस्थ संसाधनों से HTML-से-PDF प्रॉक्सी प्रमाणीकरण त्रुटियाँ
जब मुख्य दस्तावेज़ स्थानीय रूप से प्राप्त होने के बावजूद HTML-से-PDF निर्माण प्रॉक्सी चुनौती का सामना करे, तो द्वितीयक संसाधन अनुरोध खोजें।
HTML एक स्ट्रिंग के रूप में आता है। PDF निर्माण शुरू होता है, फिर कोई नेटवर्क अपवाद प्रॉक्सी प्रमाणीकरण का उल्लेख करता है। PDF फ़ाइल को दोष देने से पहले दस्तावेज़ के भीतर देखें।
एक रेंडरर अपने इनपुट द्वारा संदर्भित संसाधनों को हल कर सकता है। दूरस्थ छवि, स्टाइलशीट, फ़ॉन्ट या समर्थित आयात एक और अनुरोध जोड़ता है। कौन से संसाधन प्रकार समर्थित हैं यह रेंडरर पर निर्भर करता है; मुख्य मार्कअप प्रदान करना पूर्णतः ऑफ़लाइन रूपांतरण की गारंटी नहीं देता।
दूसरा URL खोजें
वह संसाधन दर्ज करें जिसे रेंडरर विफल होने पर प्राप्त कर रहा था। सापेक्ष संदर्भों को वास्तविक आधार URL के विरुद्ध हल करें। मासूम दिखने वाला लोगो पथ एप्लिकेशन के बाहर इंगित कर सकता है जब वह आधार ब्राउज़र पूर्वावलोकन में प्रयुक्त आधार से भिन्न हो।
फिर डाउनलोडर की पहचान करें। आपके अपने HTTP क्लाइंट का सफल अनुरोध रेंडरर की आंतरिक संसाधन पुनर्प्राप्ति को कॉन्फ़िगर नहीं करता। रेंडरर का प्रलेखित संसाधन इंटरफ़ेस या स्वीकृत प्रीफ़ेच व्यवस्था हो तो उसका उपयोग करें।
स्रोत एप्लिकेशन के क्रेडेंशियल भी स्वतः प्रॉक्सी क्रेडेंशियल नहीं होते। रेंडरर किसी सेवा पहचान के अंतर्गत भिन्न परिवेश और भिन्न नेटवर्क पथ के साथ चल सकता है।
निर्भरता को स्पष्ट करें
ऑफ़लाइन काम करने के इरादे वाली रिपोर्टों के लिए, समर्थित तंत्र के माध्यम से स्वीकृत स्थानीय या एम्बेडेड संसाधन प्रदान करें। यदि दूरस्थ संसाधन आवश्यक हों, तो उनके अनुमत गंतव्य, प्रमाणीकरण और विफलता व्यवहार को रेंडरिंग डिज़ाइन का भाग बनाएँ।
लापता लोगो और विफल रूपांतरण भिन्न संभावित परिणाम हैं। केवल इसलिए कि PDF फ़ाइल बन गई, रिपोर्ट को पूर्ण घोषित करने के बजाय जाँचें कि लाइब्रेरी पुनर्प्राप्ति त्रुटियों को कैसे संभालती है। विफल संसाधन और अनुरोध चरण को निदान में रखें; मूल दस्तावेज़ का URL बार-बार बदलने से वास्तविक डाउनलोड अछूता रह सकता है।