Честная генерация DOCX файлов на PHP. Часть 2

[vasilisc]

профи скажите плиз
если docx, образно говоря файл xml + zip, то в чём сложности при открытии сложноформатированных документов при открытии в LibreOffice?

[hom9k]

Напрашивается логичный ответ, что в LibreOffice спецификация docx реализована не полностью

[sidristij]

Могу предположить что в типографике. Довольно сложно отрендерить 1-в-1. Есть же множество правил, переносов в случае обтекания изображений, идентичность рендеринга шрифтов и прочего, прочего

[sidristij]

Плюс LibreOffice довольно сумбурно написан. Видно что его писало огромное множество людей. Когда понадобилось вставить поддержку DOCX, ее вставили, а рендер остался старым. Как старый рендер работал по-другому, нежели MS, так и работает. Поддержка формата тут, IMHO, не при чем

[snizovtsev]

У формата есть синтаксис и семантика рендеринга. OpenOffice реализует только семантику рендеринга ODF. Для работы с другими форматами просто используются конвертеры из/в ODF.

[FSA]

У меня аналогичный вопрос: почему мои сложные документы odt не открываются корректно M$ Office?

[vasilisc]

не могу вам ответить… я убунтоид и меня интересует как можно более корректное открытие форматов MS в LO
vice versa меня не интересует… извините

[FSA]

Коллега. Тогда вы точно знаете, что документация docx содержит множество неточностей судя по новостям. Ну а пока другие разбираются в стандарте M$, сама M$ клепает новые продукты с новыми «особенностями».

[vasilisc]

просто «открытость» docx давала надежду, что наконец-то можно нормально обмениваться документами без косяков

[norguhtar]

Ага. docx — спецификация 6 тысяч страниц. odf — тысяча страниц на все.

[VolCh]

Вы правильно заметили в прошлом посте, что WordDocument может быть наследником другого класса. Я имел в виду, что он может быть наследником/реализацией какого-то абстрактного класса/интерфейса Document, а от него наследоваться WordDocument (вернее DocxDocument), DocDocument, OdtDocument, PdfDocument, RtfDocumnt и т. п., чтобы пользователь мог прозрачно выбрать соответствующий формат.

У вас же, видимо другие задачи. У вас получается, что OfficeDocument, WordDocument и будущий ExcelDocument все реализуют интерфейс ZipArchive, давая, кроме всего прочего пользователю нарушить целостность документов, сформировать их так, что они открываться не будут. Да и вообще, мне как пользователю класса WordDocument неинтересно представлен он физически zip-файлом или в каком-то бинарном формате, а вы на меня эту информацию вываливаете без всякой надобности (хотя бы в куче методв при автодополнении в IDE). Получая выгоду от наследования, вы нарушаете инкапсуляцию.

[alexios]

Спасибо за хорошие комментарии.
Я вас, кажется, понимаю. У всех этих документов (doc, odt, pdf) есть что-то общее, а именно, создание файла, добавление контента, упаковка. Ключевое слово — инкапсуляция. Здесь вы совершенно правы.
Сдружить наследование с инкапсуляцией, как мне видится, можно двумя способами:

1. Использовать геттеры/сеттеры

2. Написать костылей:

protected function addFile( $params ){
  return $this->addFile( $params );
}

[alexios]

Я хотел сказать

protected function addFile( $params ){
  return parent::addFile( $params );
}

[seriyPS]

class OfficeDocument {
protected $zip;
function __construct($filename, $template_path = '/template/' ) {
    $this->path = dirname(__FILE__) . $template_path;
    $this->zip = ZipArchive();
    $this->zip->open($this->path);
    #.....
}
}

$this->zip доступен и в дочерних классах.

[DeusModus]

Мне кажется, что VolCh имел ввиду, что пользователю совершенно необязательно знать и иметь представление, что обьект имеет методы работы с zip ахивом.

$storge = new DocFileStorage('temp/file.doc'); // Этот класс реализует механизм сохранения/создания/модификации файла
$doc = new WordDocument($storage); // получает аргументом что-то вроде Interface IDocStorage
$doc->assign('image.jpg');
$doc->assign('Кто узнал эту женщину - тот настоящий знаток женской красоты.');

Туда бы еще try{}catch(){} добавить и вообще шоколадно было бы.

И теперь мы можем хоть в БД их писать(просто подменяя IDocStorage), хоть в файл, хоть в гугл докс отправлятью.

[VolCh]

Более того — опасно ему давать эти знания :)

Но вообще немного другую схему имел в виду, о выделении storage не думал, думал только о том чтобы docx, doc, odt, pdf, rtf, txt,… имели общий интерфейс вроде IDocument с assign и т. п., но ничего больше. Если ещё и с вашей стороны смотреть, то это нам наверное мост нужен будет, который будет определять какую имплементацию IDocumentStorage нам подсовывать в конкретную имплементацию IDocument. Без чёткого указания на это в ТЗ ябы не спешил с этим, достаточно для начала IDocument::getСontent(), которое выдаёт бинарное представление, а уж его хоть прямо в вывод (с getMimeType соответствующим), хоть в файл, хоть в БД блобом.

[atd]

> Кратко: можно получить EMU из px умножением на число. Только вот на википедии написано, что это число равно 12700. Я же экспериментально выяснил, что оно равно 8625.

Потому что в википедии написано про pt, а не про px

[sidristij]

Тут тоже. Вполне возможно число правильное, а вот DPI у вас другой. Хотя может я не так понял о чем речь

[seriyPS]

XML — парсером так и не научились пользоваться…

$w->assign('> < > < > pwned!!!111 < > < > < ');