December 21, 2012 at 13:44The imposition of basic inscriptions in accordance with GOST 2.104 (framework) on LaTeX documents
Despite the fact that many consider our state standards regarding ESKD and ESPD to be obsolete, design and program documentation must be implemented in accordance with them.
When I was a very young “specialist,” I watched discouragedly as Microsoft Office wrote technical specifications, programs, and test methods. Sometimes these documents are very complex and long. The most frightening were the main inscriptions placed in the footer. They did not comply with GOST 2.104. In common people they are called the "framework". They were terrible. I have not seen anyone manage to do them right. Swam sizes, line thicknesses. It was visible even without a ruler.
Imagine developing a software product without using any version control system. That sounds ridiculous. However, few people are confused by writing complex documents in Microsoft Office. The file format is binary, it is impossible to track any changes. To establish the authorship of the lines is not possible. It is also impossible to work for several people on one document at the same time. Editing documents with a length of 500 pages with many drawings is sometimes almost impossible. Modern computers with a lot of RAM, of course, deal with this much better than 5 years ago.
That is why at one time I switched to LaTeX (more precisely, XeTeX). All documents immediately began to be placed in SVN. You could easily insert vector images into a document - it looked amazing. The author of each line was installed without problems. It was even possible to write comments in a document, just like in C.
There was one problem. It was necessary to adhere to the very “framework” to the documents. Maybe I was looking badly, but at that time I did not find ready-made solutions, or they did not suit me in quality. I know that LaTeX is turing-complete and that with the help of its commands you can draw anything you want. However, at that time my knowledge in C was 100 times better than in LaTeX. In fact, switching to LaTeX was not so painless.
I was full of decisiveness, I had to realize my plan at all costs. I knew about the existence of pdftk. With it, you can overlay one PDF document on top of another. All I had to do was somehow generate a document containing only “frames”. Then I could easily overlay it on any PDF document.
I've already loved inkscape enough. After reviewing the structure of the SVG file, I realized that generating it is not so difficult. It's just a little harder than generating HTML using PHP. inkscape can export SVG to PDF, including from the command line. For a couple of days I wrote a program in C, which generated any basic labels for any design documents. It was necessary to indicate the type of document (text or drawing), sheet size, its orientation and the number of sheets. Each column of the main inscription has a number in accordance with GOST 2.104. For example, in column 11 the names of the signatories are entered. I decided to store the data that should be filled in the appropriate columns in a simple text file in the form of a table with a tab as a delimiter.
Original file:
Work Result:
A makefile was quickly written that automated the whole process. In general, the build process was performed as follows:
1. LaTeX is called up as many times as necessary. As a rule, two passes are required, very rarely three;
2. Using pdftk, the number of pages (N) is extracted from the PDF file generated by LaTeX;
3. The title block generator starts. It turns out N SVG files;
4. Each SVG file is converted to PDF using inkscape. It turns out N PDF files;
5. The resulting title block is superimposed using pdftk on the document (generated by LaTeX).
Thus, beautiful documents with beautiful "frames" were obtained. However, there was one drawback. In order to overlay a “frame” on a PDF file, it (a PDF file) must first be divided into separate pages. Then, after applying, again put together. As a result of this, the size of the document increases almost N times, where N is the number of pages. Cross-references also stopped working and content disappeared (PDF).
To solve this problem, it was necessary to implement the imposition of the "framework" directly using LaTeX. The \ AddToShipoutPicture team came to the rescue. It allows you to put the background on the page. Everything was decided by the following piece of code:
The Form.pdf file is a multi-page document with frames.
Everything was perfect now. The file size did not increase once again, the main labels looked as they should and were in the right place with the right scale.
Fragment of a text document:
There are a number of text documents (GOST 2.106), which are tables. Such documents include specifications and various statements. Lists of items are also common. I don’t understand why these documents are drawn in AutoCAD. It takes a lot of time.
After spending some more time, I wrote a set of small console utilities that turn a regular CSV file into a specification or list of purchased products, for example.
An example of a generated list of items:
Everything written refers to 2009. After that, to be honest, I no longer tried to look for analogues, since the solution is completely satisfied so far. Changes, if necessary, are made easily, since everything is written with one's own hand. During development, only standard C and C ++ libraries were used. For some time it was even used under Windows.
As a result, a whole system for assembling design documentation was made. The need to use some proprietary software has virtually come to naught. With inkscape, you can make quite complex drawings. Yes, it is not intended for this, but it is absolutely free, unlike AutoCAD, for example.
To build a package of design documentation, just go to the directory and run make. All documents are collected and stacked in a separate place. The number of sheets for each document is automatically calculated separately and for the entire project. Sometimes these numbers are very necessary, and it is not at all interesting to count with hands, especially when there are more than 100 documents and they periodically change.
UPD: All of the above is available in this or that approximation on GitHub: github.com/kutelev/gost_forms
UPD2: Collected examples are available in GitLab: gitlab.com/kutelev/gost_forms/builds/artifacts/master/browse?job= build% 3Adocuments
When I was a very young “specialist,” I watched discouragedly as Microsoft Office wrote technical specifications, programs, and test methods. Sometimes these documents are very complex and long. The most frightening were the main inscriptions placed in the footer. They did not comply with GOST 2.104. In common people they are called the "framework". They were terrible. I have not seen anyone manage to do them right. Swam sizes, line thicknesses. It was visible even without a ruler.
Imagine developing a software product without using any version control system. That sounds ridiculous. However, few people are confused by writing complex documents in Microsoft Office. The file format is binary, it is impossible to track any changes. To establish the authorship of the lines is not possible. It is also impossible to work for several people on one document at the same time. Editing documents with a length of 500 pages with many drawings is sometimes almost impossible. Modern computers with a lot of RAM, of course, deal with this much better than 5 years ago.
That is why at one time I switched to LaTeX (more precisely, XeTeX). All documents immediately began to be placed in SVN. You could easily insert vector images into a document - it looked amazing. The author of each line was installed without problems. It was even possible to write comments in a document, just like in C.
There was one problem. It was necessary to adhere to the very “framework” to the documents. Maybe I was looking badly, but at that time I did not find ready-made solutions, or they did not suit me in quality. I know that LaTeX is turing-complete and that with the help of its commands you can draw anything you want. However, at that time my knowledge in C was 100 times better than in LaTeX. In fact, switching to LaTeX was not so painless.
I was full of decisiveness, I had to realize my plan at all costs. I knew about the existence of pdftk. With it, you can overlay one PDF document on top of another. All I had to do was somehow generate a document containing only “frames”. Then I could easily overlay it on any PDF document.
I've already loved inkscape enough. After reviewing the structure of the SVG file, I realized that generating it is not so difficult. It's just a little harder than generating HTML using PHP. inkscape can export SVG to PDF, including from the command line. For a couple of days I wrote a program in C, which generated any basic labels for any design documents. It was necessary to indicate the type of document (text or drawing), sheet size, its orientation and the number of sheets. Each column of the main inscription has a number in accordance with GOST 2.104. For example, in column 11 the names of the signatories are entered. I decided to store the data that should be filled in the appropriate columns in a simple text file in the form of a table with a tab as a delimiter.
Original file:
Drawing A4 1 0 Metal detector 1 1 Assembly drawing 2 0 ABVG.123456.001 SB 6 0 1: 1 11 0 Ivanov 11 1 Sidorov 11 2 Petrov 11 4 Falcons 11 5 Kuznetsov
Work Result:
A makefile was quickly written that automated the whole process. In general, the build process was performed as follows:
1. LaTeX is called up as many times as necessary. As a rule, two passes are required, very rarely three;
2. Using pdftk, the number of pages (N) is extracted from the PDF file generated by LaTeX;
3. The title block generator starts. It turns out N SVG files;
4. Each SVG file is converted to PDF using inkscape. It turns out N PDF files;
5. The resulting title block is superimposed using pdftk on the document (generated by LaTeX).
Thus, beautiful documents with beautiful "frames" were obtained. However, there was one drawback. In order to overlay a “frame” on a PDF file, it (a PDF file) must first be divided into separate pages. Then, after applying, again put together. As a result of this, the size of the document increases almost N times, where N is the number of pages. Cross-references also stopped working and content disappeared (PDF).
To solve this problem, it was necessary to implement the imposition of the "framework" directly using LaTeX. The \ AddToShipoutPicture team came to the rescue. It allows you to put the background on the page. Everything was decided by the following piece of code:
\ifdefined\overlaypass
\newcounter{overlaypage}
\setcounter{overlaypage}{1}
\AddToShipoutPicture{\AtPageLowerLeft{\includegraphics[page=\arabic{overlaypage}]
{./Form/Form.pdf}\stepcounter{overlaypage}}}
\fi
The Form.pdf file is a multi-page document with frames.
Everything was perfect now. The file size did not increase once again, the main labels looked as they should and were in the right place with the right scale.
Fragment of a text document:
Not at all about LaTeX
There are a number of text documents (GOST 2.106), which are tables. Such documents include specifications and various statements. Lists of items are also common. I don’t understand why these documents are drawn in AutoCAD. It takes a lot of time.
After spending some more time, I wrote a set of small console utilities that turn a regular CSV file into a specification or list of purchased products, for example.
An example of a generated list of items:
Original file
H Chokes L L1 D3 - 03 - 0.16 GOST 17597 - 78 1 L L2 D25 - 0.08 - 1.1 GOST 17597 - 78 1 L H Capacitors L C1 KT4 - 24 - 180 microfarad ОЖО.460.021 TU 1 L С2 КМ - 5 - 100 μF ± 10% ОЖО.460.021 TU 1 L С3 КМ - 5 - 51 μf ± 10% ОЖО.460.021 TU 1 L С4 КМ - 5 - 160 μF ± 10% ОЖО.460.021 TU 1 L C5 KM - 5 - 51 μF ± 10% ОЖО.460.021 TU 1 L C6, C7 KM - 5 - 36 μF ± 10% ОЖО.460.021 TU 2 L С8 КМ - 5 - 0.15 μf ± 10% ОЖО.460.021 TU 1 L С9 КМ - 5 - 200 μF ± 10% ОЖО.460.021 TU 1 L С10 КМ - 5 - 0.047 μf ± 10% ОЖО.460.021 TU 1 L C11 K53 - 16 - 50 μf ± 20% ОЖО.460.021 TU 1 L H Chips L DD1 K176LP2 GOST 9336-31 1
Conclusion
Everything written refers to 2009. After that, to be honest, I no longer tried to look for analogues, since the solution is completely satisfied so far. Changes, if necessary, are made easily, since everything is written with one's own hand. During development, only standard C and C ++ libraries were used. For some time it was even used under Windows.
As a result, a whole system for assembling design documentation was made. The need to use some proprietary software has virtually come to naught. With inkscape, you can make quite complex drawings. Yes, it is not intended for this, but it is absolutely free, unlike AutoCAD, for example.
To build a package of design documentation, just go to the directory and run make. All documents are collected and stacked in a separate place. The number of sheets for each document is automatically calculated separately and for the entire project. Sometimes these numbers are very necessary, and it is not at all interesting to count with hands, especially when there are more than 100 documents and they periodically change.
UPD: All of the above is available in this or that approximation on GitHub: github.com/kutelev/gost_forms
UPD2: Collected examples are available in GitLab: gitlab.com/kutelev/gost_forms/builds/artifacts/master/browse?job= build% 3Adocuments