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

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

23 Май 2022, 07:52 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
Новости: Часто задаваемые вопросы по LibreOffice и Apache OpenOffice.org
 
   Начало   Помощь Поиск Войти Регистрация    задать вопрос  
Страниц: 1   Вниз
  Печать  
Автор Тема: проблемы экспорта  (Прочитано 5642 раз)
0 Пользователей и 1 Гость смотрят эту тему.
MinasFilm
Форумчанин
***
Offline Offline

Сообщений: 86


« Стартовое сообщение: 1 Август 2015, 15:06 »

(Ubuntu 14.04.2 LTS, Libre Office 4.4.5.2)
только что попытался найти сколь-нибудь подходящий из универсальных форматов для экспорта из .odt более-менее сложного документа (многоуровневые списки, перекрестные ссылки, рисунки и т.д. - по сути, даже не средний уровень сложного форматирования)

делюсь впечатлениями:
в .docx:
перекрестной ссылкой не идет номер рисунка, текст названия рисунка
абзацы внутри списков, вставленные как элемент без номера, теряют выравнивание
строка-элемент списка иногда захватывает форматирование номера (который слева от нее)
в .doc:
номер рисунка идет не как перекрестная ссылка, а просто текст
перекрестные ссылки на текст (не номер!) элементов нумерованных списков не вставляются вообще
абзацы внутри списков, вставленные как элемент без номера, теряют выравнивание
строка-элемент списка иногда захватывает форматирование номера (который слева от нее)
в .rtf — страх и ужас вообще

итого - задача сделать файл, созданный во Writer-е, доступным для нормального просмотра в других офисных пакетах, оказалась неразрешимой

есть идеи, что еще можно попробовать?
Записан
denkin
Опытный пользователь
***
Offline Offline

Сообщений: 298


« Ответ #1: 1 Август 2015, 16:02 »

pdf

что касается doc, docx, rtf - попроси M$ открыть исходники - и поддержка в ЛО значительно улучшится.
« Последнее редактирование: 1 Август 2015, 16:05 от denkin » Записан
frob
Гость
« Ответ #2: 1 Август 2015, 17:20 »

что касается doc, docx, rtf - попроси M$ открыть исходники - и поддержка в ЛО значительно улучшится.

С чего бы?
Записан
kompilainenn
Мастер
*****
Offline Offline

Сообщений: 3 447



« Ответ #3: 1 Август 2015, 17:38 »

С чего бы?
а почему бы и нет?
Записан

Поддержать разработчиков LibreOffice можно тут, а наш форум вот тут
denkin
Опытный пользователь
***
Offline Offline

Сообщений: 298


« Ответ #4: 2 Август 2015, 00:06 »

что касается doc, docx, rtf - попроси M$ открыть исходники - и поддержка в ЛО значительно улучшится.

С чего бы?
для вас персонально попрошу чтобы не делали.
Записан
frob
Гость
« Ответ #5: 2 Август 2015, 03:09 »

для вас персонально попрошу чтобы не делали.

Если не секрет, кого попросите?
Записан
frob
Гость
« Ответ #6: 2 Август 2015, 05:09 »

а почему бы и нет?

Код сам собой не напишется.
Записан
MinasFilm
Форумчанин
***
Offline Offline

Сообщений: 86


« Ответ #7: 3 Август 2015, 11:22 »

pdf

ну собственно так и сделал уже
результат неплохой да
но это явно не то пальто - в текстовый редактор из него нормально содержимое не вставишь
Записан
kompilainenn
Мастер
*****
Offline Offline

Сообщений: 3 447



« Ответ #8: 3 Август 2015, 11:39 »

а почему бы и нет?

Код сам собой не напишется.

но при этом наличие исходников здорово упростило бы задачу, правда?
Записан

Поддержать разработчиков LibreOffice можно тут, а наш форум вот тут
frob
Гость
« Ответ #9: 3 Август 2015, 15:03 »

но при этом наличие исходников здорово упростило бы задачу
Приходится повторяться... С чего бы?

Допустим случилось странное и MS открыл исходники офиса.
Во-первых, "открыл" и "освободил" -- это разные вещи.
А значит "смотреть, но не трогать". Практически же это означает, что каждому "офисному" свободному проекту придётся придумывать механизмы защиты от вноса MS-овского кода, например изрядно изменить политику предоставления доступа на запись в репозиторий.
(Сейчас в LO достаточно предложить несколько адекватных патчей, для того чтобы получить доступ.) Как вариант, можно выделить специальных людей, которые сами ПИСАТЬ КОД НЕ БУДУТ, но будут по поводу потенциально проблемного кода производить анализ не спи...чки ли это у MS.

Во-вторых, код MSO и прилегающих библиотек, это наверняка десятки миллионов строк. Кто и как будет в этом разбираться?
И главное: зачем? (Мне представляется, что интерес к коду MSO проявят прежде всего вирусописатели и им подобные.)

В-третьих.
MS выложил вполне приличную документацию на большинство своих форматов. Для документированных форматов большинство проблем состоит не в том, что не известно что должно быть сделано, а в том, что соответствующая функциональность вообще не реализована.
То есть "отобразить" какие-то элементы формата не представляется возможным (ЧБ телевизор не покажет цветную картинку независимо от того, как много ты знаешь про цветной сигнал и схемотехнику цветного ТВ).
Недодокументированность проявляется в тех нечастых случаях, когда файлы созданы сторонним софтом -- все эти выгрузки таблиц из 1C и прочие перло-пайтоновские веб-модули для генерации прайсов. В таком случае у MS в документации может быть написано как "можно", но не написано, что конкретно происходит если в файле как "нельзя". Например, линия может быть или пунктирной или двойной, но не то и другое сразу. Если MS-у подать на вход файл с "двойной пунктирной линией", то оно не обвалится, не откажется читать файл и не проигнорирует линию (в большинстве случаев). Даже в таких случаях подсунуть файл в MSO и посмотреть на поведение будет быстрее чем пытаться найти соответствующее место в коде (тем более что его ещё и скопировать будет нельзя).

Итого: вместо совета уговаривать MS открыть код, можно сразу предлагать обращаться в лигу сексуальных реформ. Смысл и результат будут одинаковыми.
Записан
Страниц: 1   Вверх
  Печать  
 
Перейти в:  

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