एलईटीएक्स दस्तावेजों पर GOST 2.104 (फ्रेमवर्क) के अनुसार बुनियादी शिलालेखों का अधिरोपण

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

जब मैं बहुत छोटा "विशेषज्ञ" था, तो मैंने हतोत्साहित होकर देखा क्योंकि Microsoft कार्यालय ने तकनीकी विनिर्देश, कार्यक्रम और परीक्षण विधियाँ लिखी थीं। कभी-कभी ये दस्तावेज़ बहुत जटिल और लंबे होते हैं। सबसे भयावह मुख्य पाद लेख में लगाए गए शिलालेख थे। उन्होंने GOST 2.104 का अनुपालन नहीं किया। आम लोगों में उन्हें "ढांचा" कहा जाता है। वे भयानक थे। मैंने किसी को भी उन्हें सही करने के लिए प्रबंधन करते नहीं देखा है। तैरा आकार, लाइन मोटाई। यह बिना शासक के भी दिखाई देता था।

किसी भी संस्करण नियंत्रण प्रणाली का उपयोग किए बिना एक सॉफ्टवेयर उत्पाद विकसित करने की कल्पना करें। यह हास्यास्पद लगता है। हालाँकि, Microsoft Office में जटिल दस्तावेज़ लिखकर कम ही लोग भ्रमित होते हैं। फ़ाइल प्रारूप द्विआधारी है, किसी भी परिवर्तन को ट्रैक करना असंभव है। रेखाओं की लेखकीय स्थापना संभव नहीं है। एक ही समय में एक दस्तावेज़ पर कई लोगों के लिए काम करना भी असंभव है। कई चित्रों के साथ 500 पृष्ठों की लंबाई के साथ दस्तावेजों का संपादन कभी-कभी लगभग असंभव होता है। बहुत सारे रैम वाले आधुनिक कंप्यूटर, निश्चित रूप से 5 साल पहले की तुलना में बहुत बेहतर हैं।

यही कारण है कि एक समय में मैं LaTeX (अधिक सटीक, XeTeX) में बदल गया। सभी दस्तावेज तुरंत एसवीएन में रखे जाने लगे। आप आसानी से वेक्टर छवियों को एक दस्तावेज़ में सम्मिलित कर सकते हैं - यह अद्भुत लग रहा था। प्रत्येक पंक्ति के लेखक को समस्याओं के बिना स्थापित किया गया था। किसी दस्तावेज़ में टिप्पणी लिखना संभव था, जैसे सी।

एक समस्या थी। दस्तावेजों के लिए बहुत "ढांचे" का पालन करना आवश्यक था। शायद मैं बुरी तरह से देख रहा था, लेकिन उस समय मुझे तैयार समाधान नहीं मिला, या उन्होंने मुझे गुणवत्ता के अनुरूप नहीं बनाया। मुझे पता है कि LaTeX ट्यूरिंग-कम्प्लीट है और इसके कमांड्स की मदद से आप अपनी मनचाही चीज खींच सकते हैं। हालाँकि, उस समय C में मेरा ज्ञान LaTeX से 100 गुना बेहतर था। वास्तव में, LaTeX पर स्विच करना इतना दर्द रहित नहीं था।

मैं निर्णायकता से भरा था, मुझे हर कीमत पर अपनी योजना का एहसास करना था। मुझे pdftk के अस्तित्व के बारे में पता था। इसके साथ, आप एक पीडीएफ दस्तावेज़ को दूसरे के ऊपर ओवरले कर सकते हैं। सब मुझे करना था किसी तरह केवल "फ्रेम" युक्त एक दस्तावेज़ उत्पन्न करना था। तब मैं इसे आसानी से किसी भी पीडीएफ दस्तावेज़ पर ओवरले कर सकता था।

मैं पहले से ही काफी inkscape प्यार कर चुका हूँ। एसवीजी फ़ाइल की संरचना की समीक्षा करने के बाद, मुझे एहसास हुआ कि इसे उत्पन्न करना इतना मुश्किल नहीं है। यह PHP का उपयोग करके HTML उत्पन्न करने से थोड़ा कठिन है। कमांड लाइन से इंकस्केप पीडीएफ में एसवीजी निर्यात कर सकता है। कुछ दिनों के लिए मैंने सी में एक कार्यक्रम लिखा था, जिसने किसी भी डिजाइन दस्तावेजों के लिए कोई बुनियादी लेबल उत्पन्न किया। दस्तावेज़ के प्रकार (पाठ या ड्राइंग), शीट का आकार, इसकी अभिविन्यास और चादरों की संख्या को इंगित करना आवश्यक था। मुख्य शिलालेख के प्रत्येक स्तंभ में GOST 2.104 के अनुसार एक संख्या है। उदाहरण के लिए, स्तंभ 11 में हस्ताक्षरकर्ताओं के नाम दर्ज किए गए हैं। मैंने उस डेटा को संग्रहीत करने का निर्णय लिया जो एक सरल टेक्स्ट फ़ाइल में उपयुक्त कॉलम में टेबल के रूप में एक डिलिटर के रूप में टैब के साथ भरा होना चाहिए।

स्रोत फ़ाइल:

 रेखाचित्र A4
 1 0 मेटल डिटेक्टर
 1 1 विधानसभा ड्राइंग
 2 0 ABVG.123456.001 एस.बी.
 ६ ० १: १
 ११ ० इवानोव
 11 1 सिदोरोव
 ११ २ पेत्रोव
 ११ ४ फाल्कन्स
 ११ ५ कुजनेत्सोव

काम का परिणाम:


एक मेकफाइल जल्दी से लिखा गया था कि पूरी प्रक्रिया को स्वचालित किया गया था। सामान्य तौर पर, विधानसभा प्रक्रिया इस प्रकार की गई:

1. लाटेक्स नामक समय की आवश्यक संख्या। एक नियम के रूप में, दो पास आवश्यक हैं, बहुत कम तीन;
2. pdftk का उपयोग करके, पृष्ठों की संख्या (N) को LaTeX द्वारा उत्पन्न पीडीएफ फाइल से निकाला जाता है;
3. शीर्षक ब्लॉक जनरेटर शुरू होता है। यह एन एसवीजी फाइलें निकलता है;
4. प्रत्येक एसवीजी फाइल को इंकस्केप का उपयोग करके पीडीएफ में बदला जाता है। यह एन पीडीएफ फाइलों को चालू करता है;
5. परिणामी शीर्षक ब्लॉक दस्तावेज़ पर pdftk (LaTeX द्वारा जनरेट किया गया) का उपयोग करके सुपरिंपोज किया गया है।

इस प्रकार, सुंदर "फ्रेम" के साथ सुंदर दस्तावेज प्राप्त किए गए थे। हालांकि, एक खामी थी। एक पीडीएफ फाइल पर एक "फ्रेम" ओवरले करने के लिए, इसे (एक पीडीएफ फाइल) को पहले अलग-अलग पृष्ठों में विभाजित किया जाना चाहिए। फिर, आवेदन करने के बाद, फिर से एक साथ रखें। इसके परिणामस्वरूप, दस्तावेज़ का आकार लगभग N गुना बढ़ जाता है, जहां N पृष्ठों की संख्या है। क्रॉस-संदर्भों ने भी काम करना बंद कर दिया और सामग्री गायब हो गई (पीडीएफ)।

इस समस्या को हल करने के लिए, लाटेक्स का उपयोग करके सीधे "फ्रेमवर्क" के कार्यान्वयन को लागू करना आवश्यक था। \ AddToShipoutPicture टीम बचाव में आई। यह आपको पृष्ठ पर पृष्ठभूमि डालने की अनुमति देता है। सब कुछ कोड के निम्नलिखित टुकड़े से तय किया गया था:

\ifdefined\overlaypass \newcounter{overlaypage} \setcounter{overlaypage}{1} \AddToShipoutPicture{\AtPageLowerLeft{\includegraphics[page=\arabic{overlaypage}] {./Form/Form.pdf}\stepcounter{overlaypage}}} \fi 

Form.pdf फ़ाइल फ़्रेम के साथ एक बहु-पृष्ठ दस्तावेज़ है।

अब सब कुछ सही था। फ़ाइल का आकार एक बार फिर से नहीं बढ़ा, मुख्य लेबल दिखे जैसा कि उन्हें होना चाहिए और सही पैमाने पर सही जगह पर थे।

एक पाठ दस्तावेज़ का टुकड़ा:

लाटेक्स के बारे में बिल्कुल नहीं

कई पाठ दस्तावेज़ (GOST 2.106) हैं, जो टेबल हैं। इस तरह के दस्तावेजों में विनिर्देश और विभिन्न बयान शामिल हैं। वस्तुओं की सूची भी आम है। मुझे समझ नहीं आया कि ये दस्तावेज़ ऑटोकैड में क्यों खींचे गए हैं। इसमें बहुत समय लगता है।

कुछ और समय बिताने के बाद, मैंने छोटे कंसोल उपयोगिताओं का एक सेट लिखा, जो एक नियमित CSV फ़ाइल को विनिर्देशन या खरीदी गई उत्पादों की सूची में बदल देते हैं, उदाहरण के लिए।

वस्तुओं की एक उत्पन्न सूची का एक उदाहरण:

निष्कर्ष

सब कुछ लिखा 2009 को संदर्भित करता है। उसके बाद, ईमानदार होने के लिए, मैंने अब एनालॉग्स देखने की कोशिश नहीं की, क्योंकि समाधान अब तक पूरी तरह से संतुष्ट है। परिवर्तन, यदि आवश्यक हो, तो आसानी से बनाये जाते हैं, क्योंकि सब कुछ अपने हाथों से लिखा जाता है। विकास के दौरान, केवल मानक C और C ++ पुस्तकालयों का उपयोग किया गया था। कुछ समय के लिए इसे विंडोज के तहत भी इस्तेमाल किया गया था।

नतीजतन, डिजाइन प्रलेखन कोडांतरण के लिए एक पूरी प्रणाली बनाई गई थी। कुछ मालिकाना सॉफ्टवेयर का उपयोग करने की आवश्यकता लगभग शून्य हो गई है। इंकस्केप के साथ, आप काफी जटिल चित्र बना सकते हैं। हां, इसके लिए इरादा नहीं है, लेकिन यह ऑटोकैड के विपरीत बिल्कुल मुफ्त है, उदाहरण के लिए।

डिजाइन प्रलेखन के एक पैकेज का निर्माण करने के लिए, बस निर्देशिका में जाएं और मेक रन करें। सभी दस्तावेजों को एकत्र करके एक अलग स्थान पर रखा जाता है। प्रत्येक दस्तावेज़ के लिए शीट की संख्या स्वचालित रूप से अलग से और पूरे प्रोजेक्ट के लिए गणना की जाती है। कभी-कभी ये संख्याएं बहुत आवश्यक होती हैं, और हाथों से गिनना दिलचस्प नहीं है, खासकर जब 100 से अधिक दस्तावेज होते हैं और वे समय-समय पर बदलते रहते हैं।

UPD: उपरोक्त सभी GitHub पर एक सन्निकटन या किसी अन्य में उपलब्ध है: github.com/kutelev/gost.forms

UPD2: संकलित उदाहरण GitLab में उपलब्ध हैं: gitlab.com/kutelev/gost_forms/builds/artifacts/master/browse?job=build%3Adocuments