Форум поддержки пользователей. LibreOffice, Apache OpenOffice, OpenOffice.org

Форум поддержки пользователей. LibreOffice, Apache OpenOffice, OpenOffice.org

25 Апрель 2018, 09:43 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
Новости: Здесь можно поблагодарить участников форума Улыбка
 
   Начало   Помощь Поиск Войти Регистрация    задать вопрос  
Страниц: 1   Вниз
  Печать  
Автор Тема: Определение расположения текстовых блоков на странице  (Прочитано 476 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Gismolik
Новичок
*
Offline Offline

Сообщений: 2


« Стартовое сообщение: 17 Март 2018, 08:15 »

Возможно ли каким либо способом программно, исследуя xml файлы пакета документа, вычислить в текстовом документе координаты и размеры абзацев на страницах. На данный момент есть преобразование odt->pdf->odg. При таком преобразовании  тексты в абзацах (частями) помещаются в текстовые блоки, и там уже можно определить их положение. Ну при применении больее сложных стилей форматирования идет сильное искажение документа. Можно как то решить эту задачу другим способом?
Записан
mikekaganski
Ветеран
*****
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 888


« Ответ #1: 17 Март 2018, 09:12 »

Возможно. Этот алгоритм реализован в OOo/AOO/LO. Достаточно реализовать его снова на основе стандарта ODF.
Записан

С уважением,
Михаил Каганский
economist
Ветеран
*****
Offline Offline

Сообщений: 859


« Ответ #2: 17 Март 2018, 11:32 »

Gismolik - опишите общую задачу, не совсем понятна цель, особенно последний формат ODG, и возможно есть более простой путь. Writer, на мой взгляд, обеспечивает за счет своих внутренних механизмов: разделов, условного и скрытого текста, врезок (+стили, конечно же) - ВСЕ мыслимые потребности по автоперепозиционированию текстовых блоков. Нужное должно быть получено до преобразований. Есть -headless режим запуска Офиса, то же что и GUI, но консоль. Есть UNO+Python, работающий со всей объектной моделью  и работающий очень быстро. Макросы нужны только в самом конце, и то для доп. плюшек типа записать в БД строку об успешном формировании документа. Синдром "недоизученности" программ - опасная шутка в среде айтишников, я сам от него страдаю :-)    

Глубокая, 100% реализация хотелок и красивостей - это ловушка, из которой можно не выбраться годами. Даже такие монстры как SAP, 1С и тд - плюнули на красоту и советуют пользователям "есть" их отчеты "как есть". При этом они стали монополистами и иконами стиля в мире ПО, 9 из 10 заработанных в РФ рублей - учитываются в этих программах. Это я к чему: большой договор или отчет, сделанный в CrystalReport или 1С - видно сразу, со всеми его огрехами, недопустимыми, скажем, в подарочном издании. Writer позволяет всё это сделать намного красивее, но для этого нужно использовать его интерактивно.

Прямая правка ODT/XML 100% показана при замене, скажем реквизита небольшой длины - ООО "Ромашка" на ООО "Березка". Если же захочется большего (обновления оглавлений, ссылок, переверстки итп) - этот путь тупиковый, быстро упрётесь в ограничения.
Записан

Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...
Gismolik
Новичок
*
Offline Offline

Сообщений: 2


« Ответ #3: 21 Март 2018, 13:55 »

Спасибо большое попробую на задачу посмотреть с помощью ваших вариантов)

Суть задачи очень так-то простая: отследить перекрытие каких либо объектов (будь то картинка или обычный текст). В графических элементах все определяется графическими блоками(вроде все) определенных координатами и размерами блока + все это легко и понятно разделено постранично = легко найти наложения. Также в электронных таблицах перекрытие ячеек вполне можно программно подсчитать: есть атрибуты высот строк и ширин столбцов + таблицы также просто разделены постранично = тоже вполне реализуемо) А вот в текстовых документах программное определение координат абзацев видится мне очень проблемным. Поэтому и искались альтернативы. Один из вариантов был как раз преобразование ODT в ODG - так те самые абзацы (точнее составные части абзацев) были помещены в те самые графические блоки (у которых определяются координаты и размеры). Но вот чуть большее форматирование (например фоновое изображение абзаца - превращалось в абракадабру в документе ODG, что не есть хорошо)
« Последнее редактирование: 21 Март 2018, 14:00 от Gismolik » Записан
mikekaganski
Ветеран
*****
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 888


« Ответ #4: 21 Март 2018, 14:02 »

Неясно, что за задача в общем, и какими средствами она решается. Если нужно, можно использовать функционал, который применён в debug-билдах и юниттестах, где есть возможность сделать дамп layout в XML (можно написать вывод и в любой другой формат, или подключить колбэки и обрабатывать на ходу). Но это - задача для разработчика, и если желаете двигаться в этом направлении, добро пожаловать на https://wiki.documentfoundation.org/Development и #libreoffice-dev на FreeNode.
Записан

С уважением,
Михаил Каганский
tagezi
Ветеран
*****
Offline Offline

Пол: Мужской
Расположение: Finland
Сообщений: 782



WWW
« Ответ #5: 21 Март 2018, 14:44 »

в электронных таблицах перекрытие ячеек
о_О что реально там есть перекрытие ячеек?
Записан

(x86_64) Kubuntu 16.04.3 - LibreOffice 6.0.2 / 6.1 alpha
mikekaganski
Ветеран
*****
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 888


« Ответ #6: 21 Март 2018, 14:47 »

Вероятно, OP считает перекрытие между листами...
Записан

С уважением,
Михаил Каганский
economist
Ветеран
*****
Offline Offline

Сообщений: 859


« Ответ #7: 21 Март 2018, 15:55 »

Gismolik - в текстовых документах простое нажатие Enter создает новый абзац, который подчиняется еще и стилям. Даже ввод одной буквы может переверстать весь документ (увеличить число страниц, переместить разделы итд). Будут проанализированы все привязки объектов. Это не графика и не таблицы, так что определять границы абзацев без открытия документа в основном приложении - мне кажется бесполезно.

Задачи компоновки уже "готовых" текстовых блоков решают специальные программы - верстальные DTP, CMS. И вы пытаетесь повторить их функционал. Рендер Writer-а непрерывно решает сложную задачу отображения текстовых блоков без наложений (иное просто не имеет смысла), и только врезки немного вклиниваются в этот процесс.

Если финальный результат собирается в DTP/CMS - вашу задачу стоит решать там, в рендере, а не в ODT-файле. А чтобы не работать на уровне plain-text - используйте имеющиеся наработки. Хороший пример - плагин-форматтер MediaWiki в LO. Или расширение odt2dokuwiki (PHP). 
Записан

Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...
Страниц: 1   Вверх
  Печать  
 
Перейти в:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!