দূরবর্তী সম্পদ থেকে HTML-থেকে-PDF প্রক্সি প্রমাণীকরণ ত্রুটি

HTML একটি স্ট্রিং হিসেবে আসে। PDF তৈরি শুরু হয়, তারপর একটি নেটওয়ার্ক ব্যতিক্রম প্রক্সি প্রমাণীকরণের কথা বলে। PDF ফাইলকে দোষারোপ করার আগে নথির ভিতরে দেখুন।

একটি রেন্ডারার তার ইনপুটে উল্লিখিত সম্পদ সমাধান করতে পারে। একটি দূরবর্তী ছবি, স্টাইলশিট, ফন্ট বা সমর্থিত ইমপোর্ট আরেকটি অনুরোধ আনে। কোন সম্পদ ধরন সমর্থিত তা রেন্ডারারের উপর নির্ভর করে; মূল মার্কআপ সরবরাহ করলে সম্পূর্ণ অফলাইন রূপান্তরের নিশ্চয়তা নেই।

দ্বিতীয় URL খুঁজুন

ব্যর্থ হওয়ার সময় রেন্ডারার যে সম্পদ আনছিল তা রেকর্ড করুন। আপেক্ষিক রেফারেন্সগুলি প্রকৃত বেস URL-এর বিপরীতে সমাধান করুন। একটি নির্দোষ দেখতে লোগো পথ অ্যাপ্লিকেশনের বাইরে নির্দেশ করতে পারে যখন সেই বেস ব্রাউজার প্রিভিউতে ব্যবহৃত বেসের থেকে আলাদা।

তারপর ডাউনলোডার চিহ্নিত করুন। আপনার নিজের HTTP ক্লায়েন্টের সফল অনুরোধ রেন্ডারারের অভ্যন্তরীণ সম্পদ পুনরুদ্ধার কনফিগার করে না। রেন্ডারারের নথিভুক্ত সম্পদ ইন্টারফেস বা অনুমোদিত প্রিফেচিং ব্যবস্থা থাকলে তা ব্যবহার করুন।

উৎস অ্যাপ্লিকেশনের প্রমাণপত্রও স্বয়ংক্রিয়ভাবে প্রক্সি প্রমাণপত্র নয়। রেন্ডারার অন্য পরিবেশ ও অন্য নেটওয়ার্ক পথসহ একটি পরিষেবা পরিচয়ের অধীনে চলতে পারে।

নির্ভরশীলতা স্পষ্ট করুন

অফলাইনে কাজ করার জন্য নির্ধারিত প্রতিবেদনের জন্য, সমর্থিত ব্যবস্থার মাধ্যমে অনুমোদিত স্থানীয় বা এমবেড করা সম্পদ সরবরাহ করুন। দূরবর্তী সম্পদ প্রয়োজন হলে, তাদের অনুমোদিত গন্তব্য, প্রমাণীকরণ ও ব্যর্থতার আচরণ রেন্ডারিং নকশার অংশ করুন।

অনুপস্থিত লোগো ও ব্যর্থ রূপান্তর দুটি ভিন্ন সম্ভাব্য ফলাফল। শুধু একটি PDF ফাইল তৈরি হয়েছে বলে প্রতিবেদন সম্পূর্ণ ঘোষণা করার বদলে লাইব্রেরি কীভাবে পুনরুদ্ধার ত্রুটি সামলায় তা পরীক্ষা করুন। ব্যর্থ সম্পদ ও অনুরোধের পর্যায়টি নির্ণয়ে রাখুন; মূল নথির URL বারবার বদলালে প্রকৃত ডাউনলোড অপরিবর্তিত থাকতে পারে।