Size: a a a

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

2020 January 10

RG

Ramil G in DocOps-сообщество
iakov v
Если по существу, то docbook работают в связке с XSL-шаблонами, соответственно, теоретически можно запрограммировать сколь угодно сложную трансформацию (хотя напрямую XSL может превращать только в другие XML-based форматы, то есть в условный HTML), а у latex цель немного другая, поэтому сделать точное позиционирование там можно, но для этого надо проделать очень большую работу.
Pandoc пробовали?
источник

iv

iakov v in DocOps-сообщество
Ramil G
Pandoc пробовали?
у pandoc чтение docbook не очень развито. хотя если исходно задача про asciidoc, то может быть pandoc и не будет особым препятствием
источник
2020 January 11

NP

Nikolaj Potashnikov in DocOps-сообщество
iakov v
у pandoc чтение docbook не очень развито. хотя если исходно задача про asciidoc, то может быть pandoc и не будет особым препятствием
Asciidoc pandoc'ом еще хуже читается. Docbook, я бы даже сказал, более менее прилично. Но в данном случае docbook-xsl — это нативная для asciidoc вещь и она дает полный контроль над layout'ом в xsl-fo.  Другой вопрос, а нужен ли тут вообще docbook-xsl, в листовке нет ни таблиц, ни других сложных элементов, процессингом которых можно было бы воспользоваться. Можно же это все перегнать в docbook и написать свое преобразование в xsl-fo с нуля. Тем более, что тут явно надо будет придумывать что-то для подгонки текста, если для какого-то описания он выскочит на следующую страницу.
источник

RG

Ramil G in DocOps-сообщество
Nikolaj Potashnikov
Asciidoc pandoc'ом еще хуже читается. Docbook, я бы даже сказал, более менее прилично. Но в данном случае docbook-xsl — это нативная для asciidoc вещь и она дает полный контроль над layout'ом в xsl-fo.  Другой вопрос, а нужен ли тут вообще docbook-xsl, в листовке нет ни таблиц, ни других сложных элементов, процессингом которых можно было бы воспользоваться. Можно же это все перегнать в docbook и написать свое преобразование в xsl-fo с нуля. Тем более, что тут явно надо будет придумывать что-то для подгонки текста, если для какого-то описания он выскочит на следующую страницу.
Да, глядя на листовку, считаю, что латех лучше всего подойдёт.
источник

NP

Nikolaj Potashnikov in DocOps-сообщество
Латех, конечно, подойдет, но это перебор для данной задачи. Т.е. если все остальное идет в латех (в чем я сомневаюсь, учитывая отсутствие нормального транслятор в латех для asciidoc), то, конечно да... но если с нуля решать
источник

СФ

Семён Факторович in DocOps-сообщество
Ivan Abashkin
Всем привет!

Ребят, подскажите, кто-нибудь пробовал генерировать pdf через такую связку?:
ASCIIDOC -> HTML+CSS -> PDF

В чем задача:
Мы пробуем использовать asciidoctor-pdf. На выходе хотим получать красивый PDF.
Asciidoctor-pdf может генерировать как pdf, так и html.
Для генерирования PDF можно использовать только шаблоны в yml.
Для генерирования HTML можно использовать шаблоны в css.
У нас сложная вёрстка документа. Дизайнеры нарисовали такой шаблон, который не отрисовать с помощью yml.
Поэтому мы решили использовать css для более тонкой отрисовки стиля.

В чем проблема:
Если передать в asciidoctor-pdf css-шаблон и .adoc файл, то
при генерации html, стиль применяется, всё ок. На выходе получаем, что хотели.
при генерации pdf, стиль, описанный в css, не отрабатывает. Отрабатывает только разметка.
Видимо при генерации pdf напрямую, asciidoctor-pdf не умеет применять css-шаблоны.

Сейчас мы хотим попробовать такую связку ASCIIDOC (+CSS) -> html -> какой-то конвертер -> pdf
Отсюда ещё несколько вопросов:
1. Как бы (с помощью каких инструментов) с использованием css-шаблона сгенерировать дизайнерский PDF из ASCIIDOC ?
2. С какими сложностями (граблями) можно столкнуться, при сохранении html страницы в PDF (используя puppeteer, html2canvas, jsPDF или аналогичные штуки)
3. Возможно ли сложную вёрстку документа описать с помощью docbook или latex? Пример вёрстки на скриншоте ниже. Нам нужно выдерживать вертикальные и горизонтальные интервалы между картинками и текстом, задавать ширину заливки, писать текст в точно заданном месте, и т.п.
Мы генерили PDF из HTML с помощью Puppeteer, полет нормальный
источник

СФ

Семён Факторович in DocOps-сообщество
Что видишь в хроме, то и получаешь в PDF, с точностью до пикселя
источник

СФ

Семён Факторович in DocOps-сообщество
Плюс можно задавать кастомные размеры итогового PDF. Мы генерили наклеиваемые этикетки, нам это было важно.
источник

СФ

Семён Факторович in DocOps-сообщество
Семён Факторович
Что видишь в хроме, то и получаешь в PDF, с точностью до пикселя
На удивление, ни один другой конвертер, что мы пробовали, это требование не выполняет
источник

СФ

Семён Факторович in DocOps-сообщество
Сейчас с ходу уже не вспомню, какие именно мы перебирали, но там точно был распиареный wkhtmltopdf
источник

IA

Ivan Abashkin in DocOps-сообщество
Семён Факторович
Мы генерили PDF из HTML с помощью Puppeteer, полет нормальный
Да, мы тоже этикетки делали с помощью Puppeteer, опыт работы с ним есть. Потому и спрашиваю про возможные грабли.

Настораживает то, что цепочка генерации pdf через Puppeteer нигде не упоминается.

Я боюсь, например, того, что не будут работать переходы по ссылкам или оглавлению, не отработают разрывы страниц, заданные в маркапе.  Непонятно как будет выглядеть нумерация страниц, левые-правые колонтитулы и т.п.
источник

СФ

Семён Факторович in DocOps-сообщество
мне кажется, вернее рассматривать Puppeteer (точнее, Headless Chrome) как обособленный инструмент конвертации HTML-PDF, а не как полноправное звено цепочки Asciidoc-HTML-PDF
источник

СФ

Семён Факторович in DocOps-сообщество
что есть во входном HTML, то и будет в итоговом PDF
источник

СФ

Семён Факторович in DocOps-сообщество
то есть Headless Chrome точно не будет оперировать правильным разбиением на страницы A4, колонтитулами и пр., если всего этого нет в HTML
источник

iv

iakov v in DocOps-сообщество
Семён Факторович
то есть Headless Chrome точно не будет оперировать правильным разбиением на страницы A4, колонтитулами и пр., если всего этого нет в HTML
поддерживаю! html сам по себе плохо подходит для документов, разбитых на страницы
источник

IA

Ivan Abashkin in DocOps-сообщество
Семён Факторович
мне кажется, вернее рассматривать Puppeteer (точнее, Headless Chrome) как обособленный инструмент конвертации HTML-PDF, а не как полноправное звено цепочки Asciidoc-HTML-PDF
Понятно, спасибо!

У нас требования к красивой верстке только для первой страницы документа.
Значит попробуем генерировать Puppeteer'ом PDF первой страницы отдельно от всего остального документа.

Осталось понять:
1. Какой способ генерации html из asciidoc оптимальнее?
2. Как склеить вместе два PDF?
источник

L

Lana in DocOps-сообщество
Ivan Abashkin
Понятно, спасибо!

У нас требования к красивой верстке только для первой страницы документа.
Значит попробуем генерировать Puppeteer'ом PDF первой страницы отдельно от всего остального документа.

Осталось понять:
1. Какой способ генерации html из asciidoc оптимальнее?
2. Как склеить вместе два PDF?
2. pdfunite
источник

NP

Nikolaj Potashnikov in DocOps-сообщество
Ivan Abashkin
Понятно, спасибо!

У нас требования к красивой верстке только для первой страницы документа.
Значит попробуем генерировать Puppeteer'ом PDF первой страницы отдельно от всего остального документа.

Осталось понять:
1. Какой способ генерации html из asciidoc оптимальнее?
2. Как склеить вместе два PDF?
2. cpdf. Возможно, с pdfunite не разобрался, но у меня при добавлении титульной страницы все ссылки ехали на одну страницу. У cpdf такого эффекта нет
источник
2020 January 13

PD

Phil Delgyado in DocOps-сообщество
Коллеги, а какие есть удобные инструмены для l18n со следующими требованиями:

1) Привязка локализации к ключам, а не тексту
2) Иерархия ключей ("ключи для экрана авторизации, ключи для оплаты услуг, ..."
3) Проверка целостности перевода по иерархии ("все ключи для формы воскрешения мертвых имеют перевод на старошумерский")
4) Ориентация на непрофессиональных локализаторов ("отдаем клиенту все на латыни, а на старошумерский он сам переведет")

И если я не указал какие-то важные кейсы - расскажите?
Принципиальные сценарии - перевод делает клиент, которому поставлено решение, возможно только для части функциональности.

Заранее спасибо.
источник

EB

Elena Baskakova in DocOps-сообщество
Phil Delgyado
Коллеги, а какие есть удобные инструмены для l18n со следующими требованиями:

1) Привязка локализации к ключам, а не тексту
2) Иерархия ключей ("ключи для экрана авторизации, ключи для оплаты услуг, ..."
3) Проверка целостности перевода по иерархии ("все ключи для формы воскрешения мертвых имеют перевод на старошумерский")
4) Ориентация на непрофессиональных локализаторов ("отдаем клиенту все на латыни, а на старошумерский он сам переведет")

И если я не указал какие-то важные кейсы - расскажите?
Принципиальные сценарии - перевод делает клиент, которому поставлено решение, возможно только для части функциональности.

Заранее спасибо.
Вот в этом @localizer
чате локализаторы сидят.
источник