История изменений

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

Далее тебе нужно передать данные в этот шаблон, получить .tex-файл и скомпилировать его. Тут у тебя возникнут несколько проблем. Начнем по порядку:

1. Учти что, допустим, знак процента (%) в LaTeX обозначает начало комментария; обратный слэш - спец. символ, ну и так далее. Короче, перед тем как скормить данные шаблонизатору - обработай.

2. Проверь что прямо все что нужно для компиляции .tex-файла у него гарантировано будет, потому что если компилятор застрянет и захочет пользовательского ввода, некому будет его предоставить.

3. Процесс компиляции относительно долог (в зависимости от сложности верстки, это может занимать даже десяток-другой секунд), так что создание билета и его отсылку я бы сделал асинхронной. Попутно, если ожидается что пользователей будет много, я бы выделил для этого дела вообще отдельную тачку.

Итак, теперь по последнему пункту. У меня устроено следующим образом - приложение на django получает команду что надо сгенерить резюме. Оно выдергивает данные из базы, быстренько фигачит из этих данных и шаблона содержимое .tex-файла и передает его, вместе с служебными данными (в твоем случае это должен быть как минимум адрес по которому потом вышлют этот билет), менеджеру заданий. Я выбрал в качестве менеджера заданий RQ (Redis Queue). К этому менеджеру заданий подключены воркеры. Они могут быть как на этой же машине, чего не советую, так и на других машинах. Там уже один из свободных воркеров принимает задание, сохраняет содержимое .tex-файла на диск, запускает через subprocess компилятор LaTeX, и после того как он отработал, делает уже все что нужно с результатом.

Далее все уже зависит от того что ты должен делать после этого. В моем случае надо было показывать прогресс операции, выводить результат на экран, генерить превьюшку и т.д. Для этого я через websocket сообщал клиенту о том что происходит и передавал результат, но думаю что тебе это не нужно.

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

Далее тебе нужно передать данные в этот шаблон, получить .tex-файл и скомпилировать его. Тут у тебя возникнут несколько проблем. Начнем по порядку:

1. Учти что, допустим, знак процента (%) в LaTeX обозначает начало комментария; обратный слэш - спец. символ, ну и так далее. Короче, перед тем как скормить данные шаблонизатору - обработай.

2. Проверь что прямо все что нужно для компиляции .tex-файла у него гарантировано, будет, потому что если компилятор застрянет и захочет пользовательского ввода, некому будет его предоставить.

3. Процесс компиляции относительно долог (в зависимости от сложности верстки, это может занимать даже десяток-другой секунд), так что создание билета и его отсылку я бы сделал асинхронной. Попутно, если ожидается что пользователей будет много, я бы выделил для этого дела вообще отдельную тачку.

Итак, теперь по последнему пункту. У меня устроено следующим образом - приложение на django получает команду что надо сгенерить резюме. Оно выдергивает данные из базы, быстренько фигачит из этих данных и шаблона содержимое .tex-файла и передает его, вместе с служебными данными (в твоем случае это должен быть как минимум адрес по которому потом вышлют этот билет), менеджеру заданий. Я выбрал в качестве менеджера заданий RQ (Redis Queue). К этому менеджеру заданий подключены воркеры. Они могут быть как на этой же машине, чего не советую, так и на других машинах. Там уже один из свободных воркеров принимает задание, сохраняет содержимое .tex-файла на диск, запускает через subprocess компилятор LaTeX, и после того как он отработал, делает уже все что нужно с результатом.

Далее все уже зависит от того что ты должен делать после этого. В моем случае надо было показывать прогресс операции, выводить результат на экран, генерить превьюшку и т.д. Для этого я через websocket сообщал клиенту о том что происходит и передавал результат, но думаю что тебе это не нужно.