В чём делать шаблоны документов?

HTML, ясен пень. А заполненная форма передается в CGI, который компилит pdflatex'ом.

А заполненная форма передается в CGI, который компилит pdflatex'ом.

Заполненную печатную форму надо отредактировать перед выводом на печать. И если ожидается компиляция pdflatex'ом, то пользователю давать исходник latex для редактирования?

Или ты имеешь в виду весь исходник документа в HTML с заполненными из шаблона полями, затем html -> html2latex -> latex -> pdflatex? Тогда как на стадии HTML увидеть разбивку по страницам? И вообще тогда зачем latex? HTML и сам на печать неплохо выводится (с правильным CSS).

Нет же! Пользователь заполняет данные в веб-формочке. Потом они подставляются CGI-скриптом в шаблон и компиляются. Я уже как-то раз на ЛОРе приводил пример такого CGI. Если тебе нужно иметь preview, отдавай пользователю готовый pdf — коли ему понравится, он себе и распечатает.

HTML и сам на печать неплохо выводится (с правильным CSS).

Посмотрел бы я, как ты будешь в хытымыэле стандартные бланки делать...

если

Под оффтопиком естественный выбор

то OpenOffice самое оно, в т.ч. и для оффтопика, т.к. кроссплатформенно.

html, все же, не для печати (печать вообще пережиток прошлого).

Есть куча типовых деловых документов: служебные записки, накладные, приказы...

По ним есть утверждённые формы (шрифты, отступы, изображения...).

очередной наколенный docflow/ERP ? :-)

в таких системах содержательная часть документов описывается xml-схемами, ядро умеет только импортировать/экспортировать валидные xml-ки. Вывод печатных форм это внешний фильтр-модуль и задача верстальщика/дизайнера документов написать шаблоны для конвертации во внешние представления.

Простейшая конверсия это xml=>xhtml (её может делать непосредственно броузер или webkit). С неё пожалуй и стоит начинать.

Конвертация в OpenOffice document (тот-же xml) чуть сложнее - просто надо будет изучить схему OO документов. Зато формы достаточно просто готовятся

Генерация TeX, по идее должна дать наиболее красивый на печати результат, но и более гиморна по сути; простым xslt преобразованием можно не обойтись - придётся делать какие-то скрипты

pdf-ки можно получать косвенно из первых трёх, или путём xml=>xsl-fo=>pdf

Хотя.. html, очевидно, проще.

Тащемто, я бы выбирал между html и odt.

Советовать xsl это все равно что сказать: «тебе обязательно надо использовать extjs». Какая разница как именно данные будут оборачиваться в html.

Советовать xsl это все равно что сказать: «тебе обязательно надо использовать extjs»

с хрена-ли ?

Какая разница как именно данные будут оборачиваться в html.

проще и технологичнее оборачивается xml. Дизайнер получает привычное ему ТЗ, программист использует стандартные средства (xml-ки все умеют генерить). Зона взаимных конфликтов, споров и обсуждений - только утверждаемая схема содержательной части.

вторично

Автор спрашивает что использовать для формирования шаблона, а не как.

проще и технологичнее оборачивается xml

extjs работает и с xml

extjs работает и с xml

я рад что вы в курсе возможностей extjs ;-)

но броузеры и без него умеют отображать xml документы и формы.

и без xsl

и без xsl

и с ним(что удобнее) и без него. Броузеры умеют xslt (в xml или xhtml) и css для xml и html. И для media=print в том числе. Вот как конкретно они будут разбивать документ на страницы при печати - это скорее вопрос к профессиональному верстальщику чем к технологу.

Однозначно опенофис т.к. редактировать руками. Его можно программно генерить/печатать. HTML для печати — плохой выбор.

не юниксвейно

Лол.

проще и технологичнее оборачивается xml. Дизайнер получает привычное ему ТЗ, программист использует стандартные средства (xml-ки все умеют генерить).

Что получает пользователь перед печатью? Ему надо редактировать результат подстановки в шаблон. XML в текстовом редакторе — страшно.

Однозначно опенофис т.к. редактировать руками.

В него тяжело загнать шаблон с твёрдыми размерами (в мм)... Хотя API я ещё не очень ковырял, может что-то пропустил.

Ну и запускается не быстро.

Хотя в этом случае проще открывать шаблон из опеноффиса и макросом заполнять. Но как-то... Windows-way.

очередной наколенный docflow/ERP ?

Почти. Генерилка договоров.

Вывод печатных форм это внешний фильтр-модуль и задача верстальщика/дизайнера документов написать шаблоны для конвертации во внешние представления.

Проблема в том, что шаблон должен после подстановки быть доступен для редактирования пользователем (хотя бы текст) и видна разбивка по страницам (хотя это можно и через предпросмотр в pdf сделать).

Генерация TeX, по идее должна дать наиболее красивый на печати результат,

Для себя так и делал. Но у меня создаётся .tex, который я в vi потом правлю как мне надо и печатаю. Кроме того, разбивка по страницам и выравнивание ширины таблицы делается методом «перелёт/недолёт», так как при редактировании страниц и текста в ячейках не видно. Мне нормально, но юристам, боюсь, будет неудобно.

OpenOffice ... Зато формы достаточно просто готовятся

Правда? Замена текста — да, а, например, сделать многостраничную таблицу с подитогами на страницах — задача почти нерешаемая.

Что получает пользователь перед печатью? Ему надо редактировать результат подстановки в шаблон. XML в текстовом редакторе — страшно.

по вашему use-case «потом иметь возможность перед печатью исправить произвольный текст на форме. Например: добавить или удалить абзац из текста, изменить масштаб или уменьшить шрифт в таблице, чтобы не было висящей сроки на последней странице и т.д.» пользователь работает уже с результатом преобразования xml->(шаблонизатор)->целевой формат.

В случае OO с текстовым документом; но тут юзер может такого натворить :) Или с жёсткой формой и редактируемыми полями данных из базы - такая возможность есть, но чисто теоретически (не видел живых реализация).

Если платформа а-ля Web, то юзер видит html срендеренную для экрана (и опционально print-preview). Тут вы жёстко можете контроллировать что может поменять юзер, а что нет - например понавесив js на редактируемые элементы.

Но это уже вопросы и детали реализации.

rtf генерируется руками, открывается офисами

В него тяжело загнать шаблон с твёрдыми размерами (в мм).

Нет. И в опенофисе можно прямо в его гуе подготовить этот шаблон, при желании отредактировать руками XML (для твёрдых размеров в чём угодно) и потом отдельным от самого опенофиса API заполнить пропуски в нём. Во всяких питонах это делается, например, так (есть и другие готовые решения). Установленный опенофис для этого не нужен, поэтому

запускается не быстро

побоку. Опенофис нужен только для подготовки шаблона и ручной подгонки при желании. Впрочем, можно и подгонку автоматизировать, но это сложнее.

макросом заполнять

ОМГужас.

но тут юзер может такого натворить

Это скорее достоинство, чем недостаток. Всё таки шаблон для юзера, а не юзер для шаблона.

то юзер видит html срендеренную для экрана

Вот здесь проблема с шрифтами. На экране в клетке

+----------+
| № строки |
+----------+

+----------+
| № строк  |
| и        |
+----------+

+----------+
| №        |
| строки   |
+----------+

потому что при разном dpi шрифт требует разное место в ширину.

Был бы какой-то GUI редактор для Latex, скрывающий разметку (но не портящий), было бы идеальное решение. Предпросмотр в dvi работает быстро и гарантированно показывает результат на странице. И шрифты хорошие. Но писать (или даже видеть) разметку руками в текстовом редакторе — не для нормального пользователя

rtf генерируется руками

Он сильно порезанный. Там вроде даже таблиц нет.

OpenOffice ... Зато формы достаточно просто готовятся

Правда? Замена текста — да, а, например, сделать многостраничную таблицу с подитогами на страницах — задача почти нерешаемая.

хреноватая задача :-) в принципе делается OO скриптом прибиваемым в шаблон и работающим по требованию (а-ля «обновить таблицы»). Учитывая уровень документированности OO - тяжко..

генерация документов ОО «в промышленных масштабах» делается почти так-же как (x)html - прямое создание одних xml-ок из других xml-ок по шаблонам. Готовым процессором xslt или своей тулзой которая будет строить dom - не важно, но надо детально разобраться со схемой OO документов (а она мягко говоря посложнее чем xhtml) и это долго и нудно :-)

не. и таблицы есть. и картинки есть. но что-то сложное конечно тяжело...

И в опенофисе можно прямо в его гуе подготовить этот шаблон, при желании отредактировать руками XML

Установленный опенофис для этого не нужен

Да. Похоже на самый разумный вариант. Спасибо.

потом отдельным от самого опенофиса API заполнить пропуски в нём

а можно заставить OO в пакетном режиме из odt сгенерировать pdf? Или узнать на сколько страниц получился документ?

Мне нормально, но юристам, боюсь, будет неудобно.

кстати если у вас генерируемые документы исключительно формальные (а-ля договора,приказы,отчёты), то есть нет нужды делать уникальные опросные листы и прочего дизайна - то посмотри, должны быть готовые коммерческие ReportWriter`ы с нужным тебе функционалом. Их по идее дохрена, это типичная задача :-)

если ориентировочно выходит (ставка_разработчика * дней_разработки) * 1,5 >= (цена_готового + ставка_разработчика * дней_подгонки_готового) то имеет смысл подумать о покупке

PyUNO, но я не видел достаточно простых туториалов по нему. Можно headless. Число страниц в UNO должно быть, но я в своё время не осилил документацию по этому UNO.

Был бы какой-то GUI редактор для Latex, скрывающий разметку (но не портящий)

Ну есть, скажем, lyx.

должны быть готовые коммерческие ReportWriter`ы

Для Linux'а ?

документы исключительно формальные (а-ля договора,приказы,отчёты), то есть нет нужды делать уникальные опросные листы и прочего дизайна

Документы формальные. Но вверху шапка-фирменный бланк организации. Формулировки в договоре — утверждённые юристами. В общем, 99% работы будет не настройка генератора, а банальная подготовка шаблонов в выбранном формате.

должны быть готовые коммерческие ReportWriter`ы

Для Linux'а ?

Отчего нет? Мир большой, Linux уже не маленький и в делопроизводстве используется. Тем паче сейчас в моде мульти и кросс-платформы со всякими web/java/js. Изучите рынок..

Если найдётся готовый достойный кандидат - почему не купить? В противном случае можно своему уделить чуть другое внимание и потом попробовать продать.

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

Если чувствуете заинтересованность рынка, но нет ресурсов/настроя/желания/опыта продавать, то можно открыть свой код - всё не в одиночку ловить баги и развивать

Ну есть, скажем, lyx.

А он разве .tex редактирует? [href=http://www.lyx.org/Features]Там[/href] написано импорт/экспорт. Боюсь, сломает

Но вверху шапка-фирменный бланк организации. Формулировки в договоре — утверждённые юристами. В общем, 99% работы будет не настройка генератора, а банальная подготовка шаблонов в выбранном формате.

я бы для такого точно брал целевой html, может ещё для красивой шапки где логотипы и выверенные мм - svg; Единственное - смотреть чтобы стили не сильно коверкались при импорте html`я в привычные рядовым юристам Ворды и ОО-writer`ы.

исключительно из соображений чтоб не порождать лишних зависимостей и большую часть времени заниматься основной логикой.

я бы для такого точно брал целевой html,

а редактировать заполненный потом чем?

стили не сильно коверкались при импорте html`я в привычные рядовым юристам Ворды и ОО-writer`ы

Такое бывает? Даже банковская платёжка, в которой простой table с правильными размерами при открытии в MS Word'е выглядит как кошмар.

а редактировать заполненный потом чем?

если результаты правок не надо возвращать в какую-то базу - то тем, что есть у юзера и ему привычно.

Такое бывает? Даже банковская платёжка, в которой простой table с правильными размерами при открытии в MS Word'е выглядит как кошмар.

то у вас формальные типовые договора, то сложные печатные формы..вы уж определитись :)

и сдаётся мне, что та платёжка просто криво свёрстана. К сожалению недостаточно просто указания размеров.

и сдаётся мне, что та платёжка просто криво свёрстана. К сожалению недостаточно просто указания размеров.

При выводе в PDF или принтер всё идеально. Поэтому предполагаю, что Office часто ломает внешний вид HTML.

то у вас формальные типовые договора, то сложные печатные формы..вы уж определитись

Договор — это и есть сложная печатная форма: шапка с картинкой сверху, таблицы в тексте, реквизиты. И только попробуй вместо утверждённого

+------+
| Коли-|
| че-  |
| ство |
+------+

на печать отправить

+---------+
| Коли-   |
| че-ство |
+---------+