На правах «плюсовика», который не знает код LibreOffice.

сам документ экспортируется в pdf непосредственно из некоторого потока в памяти (ОЗУ) машины?

Он же у них есть в памяти, так что должен отсюда.

Дальше используются ли какие-либо виртуальные устройства для вывода конечного pdf

vcl::PDFWriter какой-то виднеется, необходимости в виртуальных устройствах нету (и хорошо, т.к. они могут часть PDF-данных потерять при «печати»), оно же всё в одном приложении.

каково его (документа) промежуточное представление перед конвертацией

Думаю, что ровно то же, что и до конвертации. Раз там Writer, то у него должны быть методы вроде

• drawLine
• drawText
• drawAnything

Соответственно, надо обойти элементы документа в правильном порядке и повызывать эти методы, а Writer разберётся с остальным.

Спасибо.

Буду ждать, может еще кто подтянется, чего дельного напишет.

Интересно - посмотри ;)

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

Экспорт всего документа, через api производится прямо в файл, доступный по uri.

Экспорт выделенной части документа, делегируется виджету pdfwriter. Судя по всему, через ui всегда работает именно эта ветка, с частным случаем выделить всё.

Второй кейс видимо новвоведение в libre и жёсткий не продуман, ибо выделить часть документа можно и программно, через api, а вот сохранить можно будет только показав пользователю стандартный диалог из libre.

А вот то что дока у libreoffice так испортилась по сравнению с openOffice, это плохо :)

Интересно - посмотри ;)

Ну да, раз дока не очень, пошел я рыться в исходниках.

необходимости в виртуальных устройствах нету

#include "vcl/virdev.hxx"

Я под виртуальным устройством имел в виду то, которое регистрируется в системе в виде драйвера и использует его интерфейс для захвата входных данных (виртуальный принтер, который принимает PostScript или нечто подобное, что он потом преобразует в PDF). Абстракция внутри приложения это же не настоящее устройство.

Просто зачем я начал этот тред, хочется узнать, а нет ли где-то в «глубинах кодаx» преобразования xml, xslt процессором перед отдачей api-интерфейсу... вот и роюсь в исходниках

Понял.

Вот еще интересное место в документации. Я так понимаю, это перечисление форматов, в которых сохраняет,экспортирует, этот самый PDFWriter?

Боюсь я смотрел только на интерфейсы, а в твоём случае скорее всего нужно смотреть реализацию. Скачай кодовую базу да поищи по ней.

а в твоём случае скорее всего нужно смотреть реализацию.

Именно это я сейчас и делаю :-)

Просто, насколько я понимаю своим скудным умишком судя вот по этому

public:
          PDFWriterImpl( const PDFWriter::PDFWriterContext& rContext, const css::uno::Reference< css::beans::XMaterialHolder >&, PDFWriter& );
         ~PDFWriterImpl();

Входные данные для преобразования мы получаем в качестве ссылки на UNO-объект

css::uno::Reference< css::beans::XMaterialHolder >&

Что является неким общим, универсальным для офиса промежуточным представлением данных.

Навроде COM-объектов у мелкомягких ;-) Так или нет?

css::beans

А это, плюс вот это наводит на мысль, что без css там точно не обошлись.

Короче говоря, народ, нашел вот ЭТУ доку и отмечаю тему решенной.

Всем спасибо!

До кучи: https://www.openoffice.org/udk/common/man/uno_the_idea.html

Эврика!

Здесь подтверждение моих догадок

Вот еще полезный туториал: https://wiki.openoffice.org/wiki/API/Tutorials/PDF_export

Разработчик отозвался

Немного информации по теме от одного из разработчиков LibreOffice:

http://opengrok.libreoffice.org/xref/core/vcl/README#170

http://opengrok.libreoffice.org/xref/core/sc/inc/document.hxx

http://opengrok.libreoffice.org/xref/core/sc/source/ui/unoobj/

The only module that has basically a pure UNO model is the chart module and that was a horrible design decision.

Профиль отвечавшего спеца: http://stackoverflow.com/users/553596/moggi