घोस्टस्क्रिप्ट के माध्यम से चलने के बाद पीडीएफ में सभी शब्दों में एक अतिरिक्त रिक्त होता है

Question

इस PDF को Abbyy Finereader 10 द्वारा निर्मित किया गया था:

http://ebooks.zeitr.org/from_abbyy.pdf

आप पहले वाक्य को कॉपी और पेस्ट कर सकते हैं और इसे (बहुत अच्छा) पाठ परिणाम प्राप्त कर सकते हैं:

Der »Bund Deutscher Gymnastik-Schulleiter« wurde am 20. November 1955 anläinerlich einer Zusammenkunft der Leiterinnen und Leiter der privaten deutschen Gymnikik-Ausbildungsstätten gegründet।

घोस्टस्क्रिप्ट 9.02 (64 बिट विंडोज) के साथ कुछ प्रसंस्करण के बाद मुझे यह फ़ाइल मिलती है:

http://ebooks.zeitr.org/after_ghostscript.pdf

अब पहला वाक्य अजीब लग रहा है - प्रत्येक शब्द के अंतिम चरित्र से पहले एक अतिरिक्त स्थान है।

डेर »बन डी डॉयचे आर जिमनास्टिक शकुललेटर« वर्ड ओमे 20। Novembe r 195 5 aläßlic h eine r Zusammenkunf t der Leiterinne n un d d Leite r de r Private n deutsche n GymnastikAusbildungsstätät n gegründet।

इसका मुख्य नकारात्मक प्रभाव है जिसे आप एक्रोबैट रीडर में पूरे शब्दों में नहीं खोज सकते। मैं घोस्टस्क्रिप्ट के लिए निर्धारित न्यूनतम पैरामीटर के साथ प्रभाव को पुन: उत्पन्न कर सकता हूं:

-sDEVICE=pdfwrite ^
-dBATCH ^
-dNOPAUSE ^
-sstdout="myStdOut" ^
-sOutputFile="myDestFile.pdf" ^
 mySourceFile.pdf

कोई विचार?

Comments

@Erwin Jurschitza: क्या आप अपनी from_abbyy.pdf फ़ाइल की लिंक को कुछ समय के लिए रखना चाहेंगे , इसलिए इसे कुछ महीनों बाद भी पुनः प्राप्त किया जा सकता है?

— कर्ट पफीफेल

@ पिपिटास: कोई बात नहीं, यह अमेज़न S3 पर है।

Answer 1

मुझे यह एक दिलचस्प समस्या लगी और एक करीब से देखा ...

सबसे पहले, मैंने qpdfपीडीएफ डेटा स्ट्रीम को अन-कंप्रेस करने के लिए कमांडलाइन टूल का उपयोग किया ताकि मैं दोनों फाइलों के सोर्स कोड को बेहतर तरीके से देख सकूं:

qpdf.exe ^
   --qdf ^
     from_abbyy.pdf ^
     qdf--from_abbyy.pdf

qpdf.exe ^
   --qdf ^
     after_ghostscript.pdf ^
     qdf--after_ghostscript.pdf

पहली घटनाओं में से एक को देखते हुए, जहां एक अतिरिक्त स्थान डाला जाता है (यह मूल स्ट्रिंग है "बुंड ड्यूशेर जिमनास्टिक-शूलराइटर" "बन डी ड्यूश आर जिमनास्टिक स्चुलेलेटर" में बदल जाता है ), मुझे निम्नलिखित पीडीएफ स्निपेट मिलते हैं:

Qdf में - from_abbyy.pdf:

( Deutsche) Tj
0 Tc
(r) Tj
1 0 0 1 143.236 265.140 Tm     %% Tm = 'text matrix' operator
3.569 Tw
0.706 Tc
( Gymnastik-Schulleite) Tj

Qdf में - after_ghostscript.pdf:

( Deutsche)Tj
0 Tc
36.235 0 Td                    %% extra Td = 'move text current point' operator
(r)Tj
2.16501 0 Td                   %% Td = 'move text current point' instead of Tm
3.569 Tw
0.706 Tc
( Gymnastik-Schulleite)Tj

आपको थोड़ा सा आइडिया देने के लिए कि यहाँ इस्तेमाल होने वाले पीडीएफ ग्राफिक ऑपरेटर क्या कहते हैं, यहाँ एक छोटी सूची है:

Tj - show text
Tc - set character spacing
Tm - set text matrix
Tw - set word spacing
Td - move text current point

जैसा कि आप देख सकते हैं, घोस्टस्क्रिप्ट ने मूल Tm( टेक्स्ट मैट्रिक्स ) ऑपरेटर को एक Td( टेक्स्ट करंट पॉइंट ) स्थानांतरित करके बदल दिया , और इसने एक अतिरिक्त भी जोड़ा 2.16501 0 Td... मुझे नहीं पता कि यह क्यों है। मैं घोस्टस्क्रिप्ट के बगज़िला [*] को एक बग रिपोर्ट प्रस्तुत करूंगा और देखूंगा कि क्या वे इसे हल करने में रुचि रखते हैं।

हालाँकि, ध्यान दें कि यह समस्या उत्पन्न नहीं होती है, अगर मैं लिनक्स एक्रोबेट रीडर 9.4.2 का उपयोग करता हूं और मेनू एक्शन "फाइल -> टेक्स्ट के रूप में सहेजें ..." का उपयोग करता हूं । इस मामले में, कोई अतिरिक्त स्थान नहीं हैं (लेकिन कुछ अतिरिक्त लाइनब्रेक)। लिनक्स पर भी, पाठ सही ढंग से खोज योग्य नहीं है, और copy'n'paste करते समय अतिरिक्त रिक्त स्थान भी दिखाता है ...।

---

^{[*] मैं बग नंबर के साथ यहां अपडेट करूंगा जब मैंने इसे कर लिया है।}

---

अपडेट करें:

प्रतिस्थापित Tmऑपरेटर के बारे में थोड़ा और विचार करने के बाद , अब मुझे लगता है कि यह समस्या की जड़ नहीं होनी चाहिए।

यह महसूस करते हुए, मैंने v9.02 के बजाय घोस्टस्क्रिप्ट v8.71 के साथ रूपांतरण करने का प्रयास किया। और क्या कहूँ? Copy'n'paste समस्या v8.71 आउटपुट के साथ नहीं होती है!

इसका मतलब है कि घोस्टस्क्रिप्ट 9.02 में एक समस्या है जो 8.71 में नहीं थी। सबसे अधिक संभावना है कि इसे आउटपुट पीडीएफ में एम्बेडेड फ़ॉन्ट मैट्रिक्स के साथ करना होगा। क्योंकि ऊपर उद्धृत पीडीएफ स्निपेट्स v8.71 आउटपुट में v9.02 आउटपुट के समान हैं ...।

अपडेट 2:

घोस्टस्क्रिप्ट के बगज़िला में बग प्रविष्टि का URL:

• http://bugs.ghostscript.com/show_bug.cgi?id=692206

अपडेट 3:

यह बग इस बीच तय हो गया लगता है। मुझे नहीं लगता कि यह घोस्टस्क्रिप्ट संस्करणों के साथ हुआ है जिसे मैंने फिर से इसके साथ परीक्षण किया है: वर्तमान गिट (v9.10GIT) और न ही घोस्टस्क्रिप्ट वी 9.06 के साथ।

Comments

@ पिपिटास: इसके विश्लेषण के लिए आपका बहुत-बहुत धन्यवाद!

Answer 2

यदि आप एक पृष्ठ को पीडीएफ में पाठ के साथ स्कैन करते हैं और उस पर एक ओसीआर एप्लिकेशन चलाते हैं, तो पाठ को पृष्ठ में जोड़ा जाएगा, लेकिन "पाठ रेंडरिंग मोड" अदृश्य पर सेट है। यह वहां है, लेकिन यह स्क्रीन पर (या कागज पर मुद्रित होने पर) प्रदान नहीं किया गया है। आप जो देखते हैं या प्रिंट करते हैं वह मूल स्कैन की गई छवि है।

हम अदृश्य पाठ को कैसे दृश्यमान बना सकते हैं?

खैर, हम पीडीएफ को संपादित कर सकते हैं ... पाठ कोड को अदृश्य करने के लिए सेट करने के लिए पीडीएफ कोड यह है:

3 Tr

आप इस स्ट्रिंग (अभी तक) को मूल from_abbyy.pdf में नहीं पा सकते हैं और न ही from_ghostscript.pdf में क्योंकि पीडीएफ के कुछ हिस्से संकुचित हैं। इसलिए हम उनकी मदद से जहाँ तक संभव हो, उन्हें अनसुना करते हैं qpdf:

qpdf \
 --qdf \
   from_abbyy.pdf \
   qdf--from_abbyy.pdf

qpdf \
 --qdf \
   after_ghostscript.pdf \
   qdf--after_ghostscript.pdf

अब हम ऊपर स्ट्रिंग को आसानी से पा सकते हैं (और प्रत्येक फ़ाइल में केवल एक घटना है)।

पाठ रेंडरिंग के दृश्यमान तरीकों में से एक में इसे स्विच करते हैं। कुल मिलाकर, हम इन 8 पाठ रेंडरिंग मोड्स में से एक चुन सकते हैं:

 0 -  fill glyph shapes
 1 -  stroke glyph shapes
 2 -  fill, then stroke glyph shapes
 3 -  neither fill nor stroke glyph shapes (invisible)
 4 -  fill and add to path for clipping glyph shapes
 5 -  stroke glyph shapes and add to path for clipping
 6 -  fill, then stroke glyph shapes and add path for clipping
 7 -  add glyph shapes to path for clipping

यदि मैं "भरण" मोड का उपयोग करता हूं, तो ओसीआर से पाठ संभवतः अंतर्निहित स्कैन छवि के शीर्ष पर इतना अच्छा नहीं लगेगा। इसलिए मैं "स्ट्रोक" संस्करण पसंद करता हूं। इसलिए मैं बस पढ़ने के लिए ऊपर की लाइन को बदलता हूं

 1 Tr

इस संशोधित पीडीएफ को देखते हुए, मुझे यह पसंद नहीं है, क्योंकि डिफ़ॉल्ट लिनिविथ मेरे स्वाद के लिए बहुत मोटी है। इसके अलावा, आउटलाइन स्ट्रोक का रंग काला (डिफ़ॉल्ट) है; मैं लाल रंग पसंद करता हूँ ताकि मूल रूप से स्कैन की गई आकृति के विपरीत हो। इसलिए मैं इस लाइन के सामने कुछ कोड जोड़ता हूं जो लिनिविद को एक बिंदु के एक चौथाई तक सेट करता है:

 .25 w

और कुछ अन्य रंग को लाल रंग में सेट करने के लिए:

 1 0 0 RG

पूरी लाइन अब पढ़ी जाती है:

 .25 w 1 0 0 RG 1 Tr

बस इतना ही।

ध्यान दें, कि हमारे छोटे हेरफेर ने फ़ाइल को नुकसान पहुंचाया है, क्योंकि इसकी "TOC" (तकनीकी शब्दों में: इसकी xrefतालिका) अब मान्य नहीं होगी। एक्रोबेट रीडर या एक्रोबेट प्रोफेशनल अभी भी इसे (शिकायत के बिना भी) और चुपचाप फ़ाइल के xref सेक्शन को "रिपेयर" करेगा। अन्य पीडीएफ दर्शक फ़ाइल को अस्वीकार कर सकते हैं, लेकिन अब हम इसकी परवाह नहीं करते ...

यहाँ परिणाम के स्क्रीनशॉट हैं: (पहला स्क्रीनशॉट विंडो की चौड़ाई पर ज़ूम किया गया है।) (दूसरा स्क्रीनशॉट 800% तक ज़ूम किया गया है।)

लाल रूपरेखा, स्कैन किए गए पाठ को अब दिखाई दे रहा है, जैसा कि हम चाहते थे।

मैंने दोनों फ़ाइलों के लिए ऊपर बताई गई एक ही प्रक्रिया का संचालन किया । from_abbyy.pdf और after_ghostscript.pdf । मैंने एक्रोबेट रीडर के 2 अलग-अलग उदाहरणों में दोनों परिणाम खोले। यदि हम उन दोनों को एक ही मान पर ज़ूम करते हैं और दोनों विंडो को अधिकतम करते हैं, तो दोनों फ़ाइलों के बीच के दृश्य को टॉगल करना आसान है [alt]+[tab]। यह दो पीडीएफ फाइलों के बीच बेहतरीन प्रतिपादन मतभेदों को प्रकट करने का एक अच्छा तरीका है।

मेरा परिणाम है: इस फाइल के लिए घोस्टस्क्रिप्ट (v9.02) इनपुट और इसके आउटपुट के बीच एक भी पिक्सेल अलग नहीं है। लेकिन काफी अंतर है अगर आप टेक्स्ट को कॉपी करना चाहते हैं ...

Answer 3

मुझे वर्णित समस्या नहीं दिख रही है। मैंने एक्रोबैट प्रोफेशनल 9.0 के साथ 'आफ्टर' पीडीएफ फाइल खोली और टेक्स्ट कॉपी किया और सही तरीके से पेस्ट किया।

घोस्टस्क्रिप्ट पूरी तरह से पीडीएफ फाइल की व्याख्या करता है, और इसकी व्याख्या के आधार पर एक नई पीडीएफ फाइल का निर्माण करता है, इसका मूल फाइल के अलावा कोई संबंध नहीं है क्योंकि यह पाठ की स्थिति को रिकॉर्ड करता है।

पीडीएफ के समृद्ध फीचर सेट के कारण कई अलग-अलग तरीकों का उपयोग करके एक ही स्थान पर पात्रों को तैनात करना संभव है। इस तरह से कुछ गलत या अप्रत्याशित नहीं है कि जीएस पीडीएफ फाइल का निर्माण कर रहा है।

यह देखते हुए कि पाठ को सही ढंग से सहेजा जा सकता है, यह एक्रोबेट हेयुरेटिक्स का मामला है जो यह तय करता है कि आस-पास के दो 'पास' अक्षर आसन्न हैं या बीच में एक जगह है, जब लगातार ASCII के रूप में संभाला जाता है।

मुझे विश्वास नहीं है कि समस्या सरल कारण के लिए एम्बेडेड फॉन्ट मेट्रिक्स हो सकती है जो फॉन्ट एम्बेडेड नहीं है :-) उपयोग किया जा रहा फॉन्ट हेल्वेटिका है, जो डॉक्यूमेंट में एंबेडेड नहीं है, और इसलिए एक्रोबैट (मेरे लिए कम से कम) ArialMT का उपयोग करता है। ध्यान दें कि 'मूल' पीडीएफ फाइल में भी फोंट नहीं हैं।

मैं अंततः रिपोर्ट किए गए बग को देखूंगा, लेकिन यह जल्द ही नहीं होगा और मुझे संदेह है कि इसके बारे में हम कुछ भी कर सकते हैं (या करेंगे)। ऐसा लगता है कि यह उत्तराधिकार का एक अनिवार्य परिणाम है। यह फोंट को एम्बेड करने में मदद कर सकता है , ताकि कम से कम वे सुसंगत हों।

Comments

@ user701996: दिलचस्प - एक्रोबैट प्रो 9.0 के साथ कोई समस्या नहीं? मेरे एक्रोबैट रीडर एक्स (10.0.1, विंडोज) में समस्या है।

@ user701996: मैंने एक्रोबेट प्रोफेशनल 9.4.4 में फाइल खोली। Copy'n'paste के बाद -file काम नहीं करता है। पाठ के रूप में सहेजें ... हालांकि काम करता है ....

— कर्ट फ़ेफ़ेले

@ user701996: भले ही फ़ॉन्ट एम्बेडेड नहीं है, फ़ॉन्ट मीट्रिक हैं । हम्म, जब तक कि फ़ॉन्ट 'बेस 14' में से एक नहीं है .... तो आप इस मामले में सही हो सकते हैं। मैं करीब से देखूंगा।

— कर्ट पफीफले

@ user701996: आपको लगता है कि आप घोस्टस्क्रिप्ट लोगों में से एक हैं। क्या आप?

— कर्ट पफीफले

Answer 4

घोस्टस्क्रिप्ट बग रिपोर्ट यहां से:

http://bugs.ghostscript.com/show_bug.cgi?id=692206

---

मैं अब इस मुद्दे को पुन: पेश करने में सक्षम हो गया हूं, और यह 8.71, इसकी प्रगति (और एक एडोब परिवर्तन) से प्रतिगमन नहीं है।

8.71 एक बग के साथ भेज दिया गया, जिसके कारण इसे अवैध टुननोडे सीएमएप्स लिखना पड़ा। भ्रामक और विरोधाभासी Adobe दस्तावेज़ीकरण CMap को CMap के रूप में लिखा जा रहा था, जब वास्तव में ToUnicode CMaps के अपने स्वयं के, असंगत, नियम होते हैं।

ToUnicode CMaps आमतौर पर केवल खोज और कॉपी / पेस्ट के लिए उपयोग किया जाता है। जैसा कि नाम से ही स्पष्ट है कि इनका उपयोग यूनिकोड कोड पॉइंट्स के चरित्र कोड को मैप करने के लिए किया जाता है। 8.71 PDF फ़ाइल में ToUnicode CMap का उपयोग नहीं किया गया है, क्योंकि यह अमान्य है, बाद के संस्करणों में से एक मान्य है, और एक्रोबेट इसका उपयोग करने के लिए जाना जाता है।

ऐसा प्रतीत होता है कि एक्रोबैट रीडर में 9.2 तक और ट्यूरिनोड डेटा के अस्तित्व में कोई अंतर नहीं है। 9.2 के बाद कुछ बिंदु पर खोज तंत्र, बदल गया, और एक्रोबैट दो अलग-अलग तंत्रों का उपयोग करता प्रतीत होता है, जो इस बात पर निर्भर करता है कि क्या एक टूयुनोडे सीएमएपी मौजूद है। मेरे पास 9.2 के बाद एक्रोबैट प्रो तक पहुंच नहीं है और केवल हाल ही में स्थापित रीडर एक्स है, मेरे बीच कुछ भी नहीं है।

एक्रोबेट के सभी संस्करणों पर 'नो यूनिकोड' पद्धति काम करती है, नए संस्करणों पर 'यूनिकोड' पद्धति विफल हो जाती है।

मैंने इसे FontDescriptor से ToUnicode CMap के संदर्भ में सफेद जगह देकर दिखाया। यदि आवश्यक हो तो मैं विभिन्न फाइलों को उपलब्ध करा सकता हूं, लेकिन वे बड़े होते हैं क्योंकि वे विघटित होते हैं।

चूंकि पीडीएफ में खोज एक हेयुरिस्टिक प्रयास है, इसलिए परिणाम की गारंटी देना संभव नहीं होगा। व्यवहार में परिवर्तन एक्रोबैट के कारण है, घोस्टस्क्रिप्ट नहीं, और घोस्टस्क्रिप्ट में परिवर्तन एक वास्तविक बग को ठीक करना था, इसलिए एक प्रगति, एक प्रतिगमन नहीं।

Answer 5

विकर की जांच करने के लिए यह समस्या फ़ॉन्ट के 'एम्बेडेड-नेस' से जुड़ी है या नहीं, मैंने लिनक्स पर एक और रूपांतरण किया है। मैंने इस कमांडलाइन का इस्तेमाल भूतों के फोंट को इस्तेमाल करने के लिए एम्बेड करने के लिए किया है:

gs \
 -o after_ghostscriptonlinux.pdf \
 -sDEVICE=pdfwrite \
 -dPDFSETTINGS=/prepress \
 -sEmbedAllFonts=true \
  from_abbyy.pdf

घोस्टस्क्रिप्ट इस आउटपुट को दिखाएगा:

GPL Ghostscript SVN PRE-RELEASE 9.02 (2011-02-07)
Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.
Page 1
Loading NimbusSanL-Regu font from %rom%Resource/Font/NimbusSanL-Regu... 2776276 1420923 2081124 778943 3 done.
Loading NimbusSanL-ReguItal font from %rom%Resource/Font/NimbusSanL-ReguItal... 2853416 1529123 2137980 831640 3 done.
Loading NimbusSanL-Bold font from %rom%Resource/Font/NimbusSanL-Bold... 2970748 1643508 2194836 886454 3 done.

घोस्टस्क्रिप्ट में निम्बसैनएल नामक एक फ़ॉन्ट परिवार से फोंट एम्बेडेड हैं । इसलिए कोई और एरियलएमटी , जैसा कि एक्रोबैट रीडर द्वारा स्क्रीन पर रेंडरिंग के लिए इस्तेमाल किया गया था, लापता हेलवेटिका के विकल्प के रूप में (ऊपर उपयोगकर्ता 701996 की टिप्पणियाँ भी देखें)। ध्यान दें, कि घोस्टस्क्रिप्ट एम्बेडेड होने के साथ ही उस फ़ॉन्ट का नाम बदलकर Helvetica रख देगा। लेकिन यह कोई समस्या नहीं है, क्योंकि NimbusSanL को Helvetica के क्लोन के रूप में बनाया गया था ...

हालाँकि, इस आउटपुट पीडीएफ के लिए, एक्रोबैट रीडर से कॉपी'न'पेस्ट भी अच्छा नहीं होगा। इस तथ्य के बावजूद कि पाठक को अब हेल्वेटिका को स्थानापन्न करने के लिए एरियलएमटी का उपयोग करने की आवश्यकता नहीं है। पाठक अब NimbusSanL / Helvetica- क्लोन का उपयोग करता है जो एम्बेडेड है।

अब तक हमने एक्रोबैट रीडर या एक्रोबैट प्रोफेशनल से कॉपी'नैपिंग टेक्स्ट के बारे में इन तथ्यों को स्थापित किया है:

• घोस्टस्क्रिप्ट वी 9.02 का आउटपुट इस फाइल के लिए पर्याप्त रूप से काम नहीं करता है ।
• यही स्थिति है कि क्या फ़ॉन्ट जीएस द्वारा एम्बेड किया गया है या नहीं।

• विंडोज एक्सपी पर जीएस के साथ-साथ लिनक्स पर जीएस के लिए भी यही स्थिति है।

• घोस्टस्क्रिप्ट वी 8.71 का आउटपुट इस फाइल के लिए पर्याप्त रूप से काम करता है ।

• यही स्थिति है कि क्या फ़ॉन्ट जीएस द्वारा एम्बेड किया गया है या नहीं।

• विंडोज एक्सपी पर जीएस के साथ-साथ लिनक्स पर जीएस के लिए भी यही स्थिति है।

• यहां तक ​​कि आउटपुट के लिए जहां copy'n'paste टूट गया है, टेक्स्ट के रूप में सहेजें ... करता है।

मुझे अभी भी समझ नहीं आया कि ऐसा क्यों होना चाहिए। लेकिन यह स्पष्ट रूप से v8.71 से 9.02 तक अपने रास्ते पर घोस्टस्क्रिप्ट के कुछ (शायद मामूली) प्रतिगमन के रूप में दिखता है।

आइए अब 'महत्वपूर्ण' PDF के साथ अन्य PDF दर्शक सॉफ़्टवेयर आज़माएँ:

• लिनक्स पर शराब के अंदर एडोब रीडर एक्स: copy'n'paste v9.4.4 के साथ उसी तरह b0rken है।
• लिनक्स पर Ev2 v2.32.2: copy'n'paste काम करता है।
• Windows XP प्रो: copy'n'paste काम करता है पर PDFXChange दर्शक 2.5 (191 का निर्माण)।
• लिनक्स पर MuPDF रीडर 0.8: dunno कैसे copy'n'paste करने के लिए - लेकिन 'खोज' निर्दोष रूप से काम करता है।
• पाया गया s.th लिनक्स पर "पीडीएफ व्यूअर 0.1.7" कहा जाता है: copy'n'paste काम करता है।
• लिनक्स पर वाइन के अंदर SumatraPDF v1.5: copy'n'paste काम करता है।
• Windows XP पर SumatraPDF v1.5.1: copy'n'paste काम करता है।
• Windows XP पर FoxitReader 4.3.1.0113: copy'n'paste काम करता है।
• लिनक्स पर वाइन के अंदर नाइट्रो पीडीएफ रीडर: copy'n'paste काम करता है।

ध्यान दें, अभी भी सभी 'कामकाजी' पीडीएफ पाठकों के बीच बहुत कम अंतर हैं, लेकिन जहां मेरा फैसला copy'n'paste काम करता है । यहाँ एक लापता डैश के रूप में, या वहाँ शब्दों के बीच कुछ दोगुना स्थान, और अन्य ऐसी बातें ... मैं वर्तमान में कोई स्पष्टीकरण नहीं है कि यह क्यों हो सकता है, लेकिन शायद यह एक ही मूल कारण है कि एडोब उत्पादों के बीच बड़ा अंतर क्यों है (जो इस फ़ाइल के लिए copy'n'paste काम नहीं कर रहा है) एक का हसन और दूसरे पर "बाकी दुनिया" है।