TXT से PDF

फ़ाइल पिकर आपकी .txt को ब्राउज़र FileReader API के ज़रिए पढ़ता है, जो UTF-8 (BOM के साथ या बिना), UTF-16 LE/BE का पता लगाता है, और Windows-1252 या ISO-8859-1 जैसे पुराने एन्कोडिंग के लिए ऑपरेटिंग-सिस्टम के डिफ़ॉल्ट पर लौट आता है। UTF-8 सुरक्षित डिफ़ॉल्ट है — हर आधुनिक टेक्स्ट एडिटर (VS Code, Notepad, TextEdit, Sublime, Vim) UTF-8 लिखता है जब तक आप उसे कुछ और न बताएँ। यदि आपका आउटपुट PDF उच्चारण-चिह्न वाले अक्षरों के बजाय बॉक्स या प्रश्नचिह्न दिखाता है, तो स्रोत फ़ाइल किसी पुराने एन्कोडिंग में है; उसे अपने एडिटर में खोलें, "Save as" UTF-8 करें, और फिर से अपलोड करें। PDF के साथ बंडल किए गए Helvetica, Times और Courier फ़ॉन्ट केवल WinAnsi वर्ण सेट को कवर करते हैं — पूरे CJK या सिरिलिक के लिए, अगला प्रश्न देखें।

सीधे तौर पर नहीं। तीनों फ़ॉन्ट विकल्प (Helvetica, Times, Courier) PDF मानक 14 फ़ॉन्ट हैं, जो केवल WinAnsi (लैटिन + पश्चिमी यूरोपीय) को कवर करते हैं। उस सीमा से बाहर के वर्ण — चीनी हान्ज़ी, जापानी काना, अरबी, सिरिलिक, ग्रीक, हिब्रू, थाई — आउटपुट में गुम ग्लिफ़ (बॉक्स) के रूप में दिखते हैं। उन लिपियों के टेक्स्ट के लिए, Type/paste मोड में टाइप या पेस्ट करें, फिर किसी समृद्ध फ़ॉर्मैटिंग टूल से एक्सपोर्ट करें, या हमारा दूसरा वर्कफ़्लो इस्तेमाल करें: अपना टेक्स्ट Word में पेस्ट करें, DOCX के रूप में सहेजें, और Word से PDF चलाएँ — वह पाइपलाइन एक Unicode फ़ॉन्ट एम्बेड करती है जो सभी आम लिपियों को कवर करता है। हम भविष्य के अपडेट में यहाँ Unicode फ़ॉन्ट एम्बेडिंग जोड़ सकते हैं।

आपके स्रोत टेक्स्ट में हार्ड लाइन ब्रेक (\n और \r\n) PDF में पैराग्राफ़ ब्रेक के रूप में सुरक्षित रहते हैं। लेआउट के दौरान टैब को चार स्पेस में बदल दिया जाता है। उपलब्ध टेक्स्ट चौड़ाई से अधिक लंबी पंक्तियाँ शब्द-सीमाओं पर सॉफ़्ट-रैप होती हैं; आपके एडिटर का मूल रैप अनदेखा कर दिया जाता है ताकि जब आप पेज आकार या मार्जिन बदलें तो आपको अटपटे अकेले शब्द न मिलें। Justify संरेखण हर पंक्ति पर शब्दों के बीच की जगह को बढ़ाता है, सिवाय हर पैराग्राफ़ की आख़िरी पंक्ति के। यदि आपको सटीक मोनोस्पेस फ़ॉर्मैटिंग चाहिए जहाँ वर्ण-कॉलम क़तार में हों (ASCII आर्ट, कोड, तालिकाएँ), तो Left संरेखण के साथ Courier चुनें — वह संयोजन हर वर्ण को एक ही कॉलम स्थिति पर रखता है।

नहीं। टेक्स्टएरिया की सामग्री पेज में ही रहती है; आपके द्वारा अपलोड की गई .txt फ़ाइल FileReader के ज़रिए पढ़ी जाती है (जो कभी नेटवर्क को छूता नहीं); PDF एक Blob पर pdf-lib (WebAssembly) का इस्तेमाल करके स्थानीय रूप से बनता है और आपको सीधे डाउनलोड के रूप में पेश किया जाता है। आप इसे DevTools Network में देख सकते हैं: कोई आउटबाउंड POST आपका टेक्स्ट नहीं ले जाता। यह तब मायने रखता है जब आप ड्राफ़्ट, डायरी प्रविष्टियाँ, स्रोत कोड, क्रेडेंशियल वाले नोट, या कोई भी ऐसा टेक्स्ट कन्वर्ट कर रहे हों जिसे आप किसी सर्वर को सौंपना न चाहें। टैब बंद करने से टेक्स्टएरिया की सामग्री मिट जाती है — localStorage में भी कुछ संग्रहित नहीं रहता।

हाँ। पेज आकार में A4 (210 × 297 mm), Letter (8.5 × 11 in / 216 × 279 mm), और Legal (8.5 × 14 in / 216 × 356 mm) उपलब्ध हैं। मार्जिन प्रीसेट 10 mm, 20 mm (डिफ़ॉल्ट — Word/Pages के डिफ़ॉल्ट से मेल खाता है), और 30 mm हैं, जो चारों ओर समान रूप से लागू होते हैं। लाइन स्पेसिंग विकल्प 1.0 (कसा हुआ, सिंगल-स्पेस्ड टाइप किए टेक्स्ट जैसा), 1.15 (डिफ़ॉल्ट — थोड़ा ढीला, Microsoft Word के डिफ़ॉल्ट जैसा), 1.5 (स्कूल निबंध), और 2.0 (छपाई-और-संपादन के लिए डबल-स्पेस्ड) हैं। फ़ॉन्ट आकार 10 pt से 24 pt तक जाता है। अभी कोई "पहली-पंक्ति इंडेंट" या "पैराग्राफ़ के बाद स्पेस" नियंत्रण नहीं है — यदि स्रोत टेक्स्ट में कोई ख़ाली पंक्ति हो तो पैराग्राफ़ उसी से अलग होते हैं।

व्यवहार में, कुछ मेगाबाइट तक का कोई भी सादा टेक्स्ट ठीक काम करता है — यह सैकड़ों पेज है, एक सामान्य दस्तावेज़ से कहीं अधिक। टूल पूरे टेक्स्ट को मेमोरी में रखता है, उसका लेआउट तय करता है, और मुख्य थ्रेड पर PDF को समकालिक रूप से रेंडर करता है; बहुत बड़ी फ़ाइलें (10+ MB टेक्स्ट, हज़ारों पंक्तियाँ) लेआउट के दौरान कुछ सेकंड के लिए ब्राउज़र टैब को जमा सकती हैं। हमारी ओर से कोई कठोर ऊपरी सीमा नहीं लगाई गई है। परिणामी PDF का हर पेज केवल टेक्स्ट और एक फ़ॉन्ट संदर्भ संग्रहित करता है, इसलिए फ़ाइल का आकार एम्बेडेड फ़ॉन्ट (Helvetica के लिए ~30 KB) से तय होता है, पेजों की संख्या से नहीं।