Не смотря на то, что многие считают наши государственные стандарты касающиеся ЕСКД и ЕСПД устаревшими. Конструкторскую и программную документацию необходимо выполнять в соответствии с ними.
Когда я был совсем молодым «специалистом» я с унынием наблюдал за тем как в Microsoft Office пишутся технические условия и программы и методики испытаний. Порой эти документы очень сложные и длинные. Наиболее пугающими были основные надписи помещённые в колонтитул. Они никак не соответствовали ГОСТ 2.104. В простонародье их называют «рамками». Они были ужасны. Я не видел чтобы кому-то удавалось сделать их правильно. Плавали размеры, толщины линий. Это было видно даже без линейки.
Представьте себе разработку программного продукта без использования какой-либо системы контроля версий. Звучит нелепо. Однако мало кого смущает написание сложных документов в Microsoft Office'е. Формат файла бинарный, отследить какие либо изменения не возможно. Установить авторство строк не возможно. Работать нескольким людям над одним документом одновременно тоже не возможно. Редактирование документов длинной в 500 страниц с множеством рисунков порой практически невозможно. Современные компьютеры с большим количеством ОЗУ, конечно, справляются с этим намного лучше чем 5 лет назад.
Именно поэтому в своё время я перешёл на LaTeX (точнее XeTeX). Все документы сразу стали помещаться в SVN. Можно было без проблем вставлять в документ векторные изображения — выглядело это изумительно. Без проблем устанавливался автор каждой строки. В документе даже можно было писать комментарии, прямо как в Си.
Была одна проблема. К документам необходимо было приладить те самые «рамки». Может я плохо искал, но в то время я не нашёл готовых решений, либо они меня не устраивали по качеству. Я знаю, что LaTeX является тьюринг-полным и то, что с помощью его команд можно нарисовать всё что угодно. Однако, в то время мои познания в Си были в 100 раз лучше чем в LaTeX. На самом деле, переход на LaTeX был не таким уж и безболезненным.
Я был полон решительности, мне нужно было во что бы то ни стало реализовать задуманное. Я знал о существовании pdftk. С его помощью можно наложить один PDF документ поверх другого. Мне оставалось только как-то сгенерировать документ содержащий только «рамки». Потом я без проблем мог наложить его на любой PDF документ.
Я уже достаточно любил inkscape. Просмотрев структуру SVG-файла я понял, что сгенерировать его не так уж и сложно. Это ни чуть не сложнее генерирования HTML с использованием PHP. inkscape может экспортировать SVG в PDF, в том числе и из командной строки. За пару дней я написал программу на Си, которая генерировала любые основные надписи для любых конструкторских документов. Необходимо было указать тип документа (текстовый или чертёж), размер листа, его ориентацию и количество листов. Каждая графа основной надписи имеет номер в соответствии с ГОСТ 2.104. Например в графу 11 вписываются фамилии лиц, подписавших документов. Данные которые должны заполнять графы решил хранить в простом текстовом файле в виде таблицы с табуляцией в качестве разделителя.
Исходный файл:
Drawing A4 1 0 Металлоискатель 1 1 Сборочный чертеж 2 0 АБВГ.123456.001 СБ 6 0 1:1 11 0 Иванов 11 1 Сидоров 11 2 Петров 11 4 Соколов 11 5 Кузнецов
Результат работы:
-na-LaTeX-dokumenty.png "Наложение основных надписей по ГОСТ 2.104 (рамок) на LaTeX документы")
Быстро был написан makefile, который автоматизировал весь этот процесс. В общем, процесс сборки выполнялся следующим образом:
1. Необходимое количество раз вызывается LaTeX. Как правило необходимо два прохода, очень редко три;
2. С помощью pdftk извлекается количество страниц (N) из PDF-файла, сгенерированного LaTeX'ом;
3. Запускается генератор основной надписи. Получается N SVG-файлов;
4. Каждый SVG-файл преобразуется в PDF формат с использованием inkscape. Получается N PDF-файлов;
5. Полученная основная надпись накладывается, с использованием pdftk, на документ (сгенерированный LaTeX'ом).
Таким образом получались красивые документы с красивыми «рамками». Однако был один недостаток. Для того чтобы наложить «рамку» на PDF-файл, его (PDF-файл) необходимо предварительно разбить на отдельные страницы. Потом, после наложения, опять собрать воедино. Вследствие этого размер документа увеличивается в практически N раз, где N — количество страниц. Так же переставали работать перекрёстные ссылки и исчезало содержание (PDF).
Чтобы решить эту проблему необходимо было реализовать наложение «рамок» непосредственно с использованием LaTeX. На помощь пришла команда AddToShipoutPicture. Она позволяет подложить фон на страницу. Всё решилось следующим кусочком кода:
ifdefinedoverlaypass
newcounter{overlaypage}
setcounter{overlaypage}{1}
AddToShipoutPicture{AtPageLowerLeft{includegraphics[page=arabic{overlaypage}]
{./Form/Form.pdf}stepcounter{overlaypage}}}
fi
Файл Form.pdf является многостраничным документом с «рамками».
Теперь всё было отлично. Размер файла лишний раз не увеличивался, основные надписи выглядели как надо и были в нужном месте с нужным масштабом.
Фрагмент текстового документа:
-na-LaTeX-dokumenty-2.png "Наложение основных надписей по ГОСТ 2.104 (рамок) на LaTeX документы")
Совсем не про LaTeX
Существует ряд текстовых документов (ГОСТ 2.106), которые представляют собой таблицы. К таким документам относятся спецификации и различные ведомости. Также широко распространены перечни элементов. Я не понимаю почему эти документы рисуют в AutoCAD'е. На это ведь уходит много времени.
Потратив ещё немного времени я написал набор маленьких консольных утилит, которые превращают обычный CSV-файл в спецификацию или ведомость покупных изделий, например.
Пример сгенерированного перечня элементов:
-na-LaTeX-dokumenty-3.png "Наложение основных надписей по ГОСТ 2.104 (рамок) на LaTeX документы")
H Дроссели L L1 Д3 - 03 - 0.16 ГОСТ 17597 - 78 1 L L2 Д25 - 0.08 - 1.1 ГОСТ 17597 - 78 1 L H Конденсаторы L С1 КТ4 - 24 - 180мкФ ОЖО.460.021 ТУ 1 L С2 КМ - 5 - 100мкФ ±10% ОЖО.460.021 ТУ 1 L С3 КМ - 5 - 51мкФ ±10% ОЖО.460.021 ТУ 1 L С4 КМ - 5 - 160мкФ ±10% ОЖО.460.021 ТУ 1 L C5 КМ - 5 - 51мкФ ±10% ОЖО.460.021 ТУ 1 L С6, C7 КМ - 5 - 36мкФ ±10% ОЖО.460.021 ТУ 2 L С8 КМ - 5 - 0.15мкФ ±10% ОЖО.460.021 ТУ 1 L С9 КМ - 5 - 200мкФ ±10% ОЖО.460.021 ТУ 1 L С10 КМ - 5 - 0.047мкФ ±10% ОЖО.460.021 ТУ 1 L С11 К53 - 16 - 50мкФ ± 20% ОЖО.460.021 ТУ 1 L H Микросхемы L DD1 К176ЛП2 ГОСТ 9336-31 1
Заключение
Всё написанное относится к 2009 году. После этого я, если честно, больше не пытался искать аналогов. Так как решение полностью устраивает до сих пор. Изменения, при необходимости, вносятся легко поскольку всё написано собственноручно. При разработке использовались только стандартные библиотеки C и C++. Некоторое время даже использовалось под Windows.
В итоге была сделана целая система сборки конструкторской документации. Необходимость использования какого-либо проприетарного программного обеспечения практически сошла на нет. С помощью inkscape можно делать достаточно сложные чертежи. Да, он для этого не предназначен, но зато он абсолютно бесплатный в отличии от AutoCAD, например.
Для сборки пакета конструкторской документации достаточно зайти в директорию и выполнить make. Все документы собираются и складываются в отдельное место. Автоматически подсчитывается количество листов для каждого документа отдельно и для всего проекта целиком. Иногда эти цифры очень нужны, а считать руками совсем не интересно, особенно, когда документов больше 100 и они периодически меняются.
Автор: kutelev
