Pull to refresh

Comments 8

Спасибо, поправил. Правильный термин "Место составления (издания)". Хотя глагол "выпустить" в отношении документа употребляется, в том числе и в нормативных актах, поэтому не настолько уж и трагичная ошибка))

На самом деле я имел ввиду транслит. Неужели нельзя что-то типа `place-of-issue`? `foot-note` можно, а остальное нет? На первом курсе я тоже страдал таким... Вы ещё не видели код с русским транслитом имён переменных...

footnote — ключевое слово Asciidoc, поэтому тут без вариантов.


Касательно транслита, специально в тексте статьи указал, что мы используем доработанный ГОСТ 7.79-2000 (система Б). Причины доработки здесь: https://github.com/CourseOrchestra/course-doc/blob/master/doc/gost-translit.adoc


Если мы автоматизируем процессы, связанные с применением российского законодательства, то использование транслита оправдано. Термины, раскрытые в нормативном акте, крайне сложно хорошо переводить на английский. То же "Место составления (издания)" вы перевели как "Place of issue". Хотя основное слово здесь — "составление", а не издание (выпуск), которое не имеет хорошего перевода, отражающего его смысл.


Я не говорю о поиске хорошего перевода для специфических терминов, например "Контрольно-надзорное мероприятие" и "Контрольно-надзорное действие".

Очень круто, что появился backend под ODT! На прошлой работе мы уже пробовали делать всю документацию в asciidoctor, но были проблемы потом при переводе этого всего в docx для клиента в конечной стадии работы. Делали через pandoc, но нельзя было кастомизировать все нужные нам стили, в результате чего приходилось вручную их править, что было очень неудобно.

Именно такая беда и побудила создать backend)) Pandoc вообще не подошёл, мы прогоняли через html

Добрый день, а напишите все-таки небольшой мануальчик как правильно документы формировать с необходимыми стилями, а то для AsciiDoc ничего не нашел.
Если прям для этого backend'a, то прям вообще отлично будет

Составитель документа по сути не должен задумываться о том, как формировать документ с необходимыми стилями. Он следит за структурой документа и содержанием.


Например, требование: "я хочу покрасить ячейку в красный цвет", — необходимо переформулировать примерно так: "я хочу атрибут, который определяет резко негативное отношение к данным в ячейке". Красной ячейка будет или нет (или красным будет только текст) решает специалист, разрабатывающий форматирование.


Форматирование берёт на себя backend. Более того, оно вариативно. Например, ГОСТ ЕСКД разрешает нумеровать графический материал внутри раздела или в разделах допускает сквозную нумерацию. Титул вообще очень вариативен. Ну и всякие рамочки, колонтитулы и т.д.


Поэтому я заложил в бэкенд большую степень кастомизируемости: на уровне шаблона, на уровне препроцессинга содержания, на уровне программного переопределения стилей Open Document. Но, в целом, это не очень сложно. Например, данную статью я писал в Asciidoc а для рецензирования отправлял в docx. Кастомизация стилей с нуля заняла не более получаса. Мне кажется (как человеку писавшему этот текст), что здесь написано достаточно, чтобы понять основные принципы https://courseorchestra.github.io/asciidoctor-open-document/. Если что-то описано недостаточно, криво или есть конкретные юзкейсы пишите Issue или в личку.

Only those users with full accounts are able to leave comments. Log in, please.