Size: a a a

DocOps-сообщество

2019 May 21

НН

Нац Нац in DocOps-сообщество
Slava Chernikoff
а то работаю над постпроцессором для автогенерации тех документации из исходников. конечный автомат и дерево интерфейса нарисовал, а на архитектуре застрял
Я люто фанатею от markdeep, посмотри, может подойдет https://casual-effects.com/markdeep/features.md.html#basicformatting/diagrams
источник

НН

Нац Нац in DocOps-сообщество
Slava Chernikoff
а то работаю над постпроцессором для автогенерации тех документации из исходников. конечный автомат и дерево интерфейса нарисовал, а на архитектуре застрял
источник

SC

Slava Chernikoff in DocOps-сообщество
Спасибо, посмотрю! Хотя и тут надо все в псевдографике рисовать
источник

SC

Slava Chernikoff in DocOps-сообщество
идеально бы как в PlantUML -вложил один rectangle в другой... но там все как-то уж очень ограниченно
источник

H

Hartmann in DocOps-сообщество
Slava Chernikoff
идеально бы как в PlantUML -вложил один rectangle в другой... но там все как-то уж очень ограниченно
В Линке на форуме тех писателей не спрашивал? Мб там подскажут.
источник

SC

Slava Chernikoff in DocOps-сообщество
пока не спрашивал 😊
источник

НН

Нац Нац in DocOps-сообщество
Slava Chernikoff
Спасибо, посмотрю! Хотя и тут надо все в псевдографике рисовать
источник

SC

Slava Chernikoff in DocOps-сообщество
кле, не видел этих инструментов раньше. буду экспериментировать
источник

H

Hartmann in DocOps-сообщество
Царский подгон. И себе сохраню, на всякий.
источник

BG

Bogdan (SirEdvin) Gladyshev in DocOps-сообщество
> The app requires macOS 10.10 Yosemite or later (all versions including 10.13 High Sierra are fully supported).

Боль
источник

H

Hartmann in DocOps-сообщество
Bogdan (SirEdvin) Gladyshev
> The app requires macOS 10.10 Yosemite or later (all versions including 10.13 High Sierra are fully supported).

Боль
Почему?
Мак настолько старый, что на него последние обновления не ставятся?
источник

BG

Bogdan (SirEdvin) Gladyshev in DocOps-сообщество
У меня линь)
источник

НН

Нац Нац in DocOps-сообщество
вторая тулза вебная
источник

BG

Bogdan (SirEdvin) Gladyshev in DocOps-сообщество
Вторая да, но первая выглядит совсем-совсем сочно, но она не для меня росла
источник
2019 May 22

K

Konstantin in DocOps-сообщество
Slava Chernikoff
идеально бы как в PlantUML -вложил один rectangle в другой... но там все как-то уж очень ограниченно
источник

EB

Elena Baskakova in DocOps-сообщество
Очень удобный инструмент, спасибо!
источник

EN

Ekaterina Noskova in DocOps-сообщество
круто, спасибо)
источник

NP

Nikolaj Potashnikov in DocOps-сообщество
Анатолий Клюса
) Правда?..
Честно говоря, я не знаю, где именно это происходит, при обработке asciidoc или где-то в другом месте...
Ведь гитлаб же понимает при обработке asciidoc, что это формат не png, а svg, а выводит всё равно как изображение, просто, видимо. для унификации.
У нас по базе данных генерируется plantUML-файл со ссылками, а само описание таблиц в asсiidoctor.

Чтобы ссылки из svg приводили к описаниям нужных таблиц, внедрять их нужно вот так image::link_in_svg.svg[opts=inline], здесь подробнее https://github.com/asciidoctor/asciidoctor.org/blob/master/docs/_includes/image-svg.adoc. При таком подходе код svg вставляется внутрь html.

А в самом plantUML должно быть что-то типа "Class 1" as class_1 [[#c1]]. Посколько svg тоже генерирует якоря, то наименование объектов в plantUML должны отличаться от якорей в документе.

В данной задаче код plantUML не внедряется в asciidoctor-файл, поскольку средство генерации документации создает картинку и описание по отдельности. Но, думаю, так тоже можно заставить работать.
источник

АК

Анатолий Клюса in DocOps-сообщество
Nikolaj Potashnikov
У нас по базе данных генерируется plantUML-файл со ссылками, а само описание таблиц в asсiidoctor.

Чтобы ссылки из svg приводили к описаниям нужных таблиц, внедрять их нужно вот так image::link_in_svg.svg[opts=inline], здесь подробнее https://github.com/asciidoctor/asciidoctor.org/blob/master/docs/_includes/image-svg.adoc. При таком подходе код svg вставляется внутрь html.

А в самом plantUML должно быть что-то типа "Class 1" as class_1 [[#c1]]. Посколько svg тоже генерирует якоря, то наименование объектов в plantUML должны отличаться от якорей в документе.

В данной задаче код plantUML не внедряется в asciidoctor-файл, поскольку средство генерации документации создает картинку и описание по отдельности. Но, думаю, так тоже можно заставить работать.
Я так понимаю, Вы советуете не напрямую открывать md/adoc в гитлабе, а сначала прогонять через asciidoctor, который конвертит это дело в html5, а потом открывать соотв. страницу?
Я отпишу в личку подробнее...)
источник

NV

Nick Volynkin in DocOps-сообщество
Друзья, а кто-нибудь из вас работает с локализацией документов в rST/Sphinx?

У меня тут проблема. В синтаксисе rST есть line block, который с вертикальными черточками.  http://docutils.sourceforge.net/docs/user/rst/quickref.html#line-blocks

sphinx-build -M gettext такие блоки растаскивает построчно и теряет номера строк. То есть получается буквально вот такое:
источник