फ़ॉन्ट सबसेटिंग संपादन क्यों तोड़ती है, पढ़ना क्यों नहीं
फ़ॉन्ट सबसेटिंग केवल वे ग्लिफ़ रखती है जो PDF पहले इस्तेमाल करता है। पाठक दिखाते रहते हैं; संपादन गुम अक्षरों पर फेल होता है। PDF123 Compress सबसेट नहीं करता।
एक PDF बिल्कुल सही दिख सकती है और फिर भी आपके टाइप किए अगले अक्षर को ठुकरा सकती है। यह अक्सर टूटा व्यूअर नहीं, बल्कि फ़ॉन्ट सबसेटिंग है: फ़ाइल वही ग्लिफ़ एम्बेड करती है जो लिखे जाते समय चाहिए थे, और संपादन ऐसा ग्लिफ़ माँगता है जो कभी पैक ही नहीं हुआ।
सबसेट क्या है
TrueType और OpenType फ़ॉन्ट में हज़ारों ग्लिफ़ हो सकते हैं; दस पेज का मेमो कुछ सौ इस्तेमाल करता है। सबसेटिंग एम्बेडेड फ़ॉन्ट को दोबारा लिखती है ताकि अनुपयोगी ग्लिफ़ हट जाएँ। फ़ाइल आकार घटता है; मौजूदा टेक्स्ट की स्क्रीन और प्रिंट रेंडरिंग वैसी ही रहती है, क्योंकि दस्तावेज़ में पहले से मौजूद हर अक्षर वहाँ बना रहता है।
इसलिए पढ़ना और छापना सफल होते हैं। विफलता बाद में दिखती है: कोई PDF को एडिटर में खोलकर उच्चारण-चिह्न या दुर्लभ विराम-चिह्न टाइप करता है, और गुम ग्लिफ़ बदल दिया जाता, खाली छोड़ दिया जाता, या अस्वीकार हो जाता है। मौजूदा टेक्स्ट की कॉपी-पेस्ट आमतौर पर अब भी चलती है; ग्लिफ़ तालिका में छेद नए अक्षर डालने पर लगता है।
सबसेटिंग फ़ॉन्ट हटाना नहीं है
फ़ॉन्ट ऑब्जेक्ट एम्बेडेड बना रहता है। जाता है ग्लिफ़ तालिका का अनुपयोगी हिस्सा। यह इनसे अलग है:
- पाठक की मशीन पर इंस्टॉल सिस्टम फ़ॉन्ट पर निर्भर रहना (OS के आर-पार प्रतिस्थापन का ख़तरा)
- टेक्स्ट को आउटलाइन या इमेज में बदलना (जो चयन और खोज मार देता है)
- फ़ाइल एन्क्रिप्ट करना (Protect): एन्क्रिप्शन ग्लिफ़ सबसेट नहीं करता
बहुत-से ऑफ़िस निर्यातक और print-to-PDF ड्राइवर एम्बेड करते समय डिफ़ॉल्ट सबसेट करते हैं। नुक़सान निर्यात के समय होता है, बाद में व्यूअर खोलने पर नहीं। किसी और PDF टूल से दोबारा सहेजने पर सबसेट हो भी सकता है और नहीं; जो ग्लिफ़ कभी लिखे ही नहीं गए, वे चमत्कार से वापस नहीं आते।
PDF123 Compress असल में क्या करता है
Compress (POST /api/v1/misc/compress-pdf) qpdf से स्ट्रीम संपीड़ित (--compress-streams=y), flate डेटा पुनःसंपीड़ित और ऑब्जेक्ट स्ट्रीम जनित कराता है। यह फ़ॉन्ट सबसेट नहीं करता और इमेज डाउनसैंपलिंग का दावा नहीं करता। अगर फ़ाइल पहले से स्ट्रीम-कसी है, तो डाउनलोड का आकार शायद मुश्किल से बदले। अगर फ़ाइल में पहले से सबसेट फ़ॉन्ट हैं, तो Compress उन्हें वैसे ही छोड़ देता है; वह उन्हें पूरे चेहरों में वापस नहीं फैलाता।
सामान्य PDF पाइपलाइनों में आकार के लीवर कैसे मिलते हैं (इमेज, स्ट्रीम, संरचना), यह PDF संपीड़ित करने पर असल में क्या होता है देखें। उसे पृष्ठभूमि मानें; इसे यह दावा न पढ़ें कि यह Compress बटन टाइपफ़ेस सबसेट करता है।
OCR और Markdown रूपांतरण भी PDF के गुम ग्लिफ़ वापस नहीं लाते: OCR Markdown टेक्स्ट लौटाता है, और PDF to Markdown वही निकालता है जो टेक्स्ट परत में पहले से है।
व्यवहार में संपादन बनाम पढ़ना
| क्रिया | सबसेटिंग के बाद सामान्य नतीजा |
|---|---|
| खोलना, स्क्रॉल, छापना, मौजूदा टेक्स्ट चुनना | चलता है; संदर्भित ग्लिफ़ मौजूद हैं |
| ऐसा अक्षर डालना जो मूल में नहीं था | फेल हो सकता है या बदल सकता है |
| PDF के भीतर पूरा संपादन-योग्य फ़ॉन्ट अपेक्षित करना | नाज़ुक; सबसेट ने अनुपयोगी ग्लिफ़ हटा दिए |
| PDF123 पर Compress चलाना | स्ट्रीम छोटी हो सकती हैं; ग्लिफ़-सूची अपरिवर्तित |
अगर पूरे अक्षर-समूह के साथ संपादन जारी रखना है, तो सबसेटिंग गलत निर्यात सेटिंग थी। संपादन-योग्य स्रोत पसंद करें (Word, ताज़ा रेंडर के लिए Markdown to PDF से Markdown) या ऐसी PDF जो पूरा चेहरा एम्बेड करे। PDF123 पर Compress वे ग्लिफ़ वापस नहीं लाएगा।
“इस PDF में é नहीं टाइप होता” का निदान करते समय देखें कि मूल निर्यात ने फ़ॉन्ट सबसेट किए थे या नहीं, व्यूअर या Repair को दोष देने से पहले। Repair संरचना दोबारा बनाता है; ग्लिफ़ तालिकाएँ नहीं फैलाता। Markdown से एक राउंड-ट्रिप नई PDF बना सकता है, उन फ़ॉन्टों के साथ जो WeasyPrint उस रेंडर में एम्बेड करता है: ताज़ा दस्तावेज़ के लिए उपयोगी, पुराने सबसेट चेहरे को सर्जिकल तरीक़े से वापस लाने के लिए नहीं।