Вопрос касаемо WYSIWIG-текстовых процессоров, типа документов и совместимости.
Не так давно по дури ввязался в написание подобным образом документика в котором необходимо использовать вложенные списки (предполагалось, что он будет совсем небольшим, следовательно разбираться с ТеХ’ом было лениво).
И тут выяснилось, что…
Рулезность ОО сильно преувеличена.
GNOME Office AbiWord рулит!
Но…
ТОЛЬКО в своём родном формате (или для записанных им же файлов).
Никто другой (единственное — KWord не проверял) не воспроизводит итоговый документ корректно. :(
Такая вот печатльная сказка.
На заметку публике для демонстрации того, что при изменении базового формата мелкомягкий охфис теряет всю свою рулезность.
Последние комментарии
-
OlegL, 17 декабря в 15:00 →
Перекличка
21
-
REDkiy, 8 июня в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.
в данном случае наиболее предпочтительно использовать text/html.
совместимо с чем угодно. :)
ну или rtf.
Согласен
А что с другими форматами. У меня док вроде нормально открывался.
Были проблемы только с графикой вставленной в доки. Немного сдвигал их AbiWord.
Про html не думал.
Для .rtf перечисленные замечания справедливы в полный рост.
То, что мсворд некорректно интерпретировал файлы созданные AbiWord.
И наоборот.
Явление существенно зависящее от содержания документа (использования графики, вложенных списков /etc).
Кстати, надо бы проверить как ОО и AbiWord насчет обмена своими родными форматами. Тогда будет видно, редакторы некорректно работают или проблема с форматом M$ Word
Ещё раз на бис: использовался вроде как стандартны .rtf. .doc — только после устойчивой демонстрации эффекта в качестве дополнительной проверки.
В том-то и дело, что:
1. ОО и AbiWord используют разные родные форматы.
2. Ни тот, ни другой в поддержке чужих открытых форматов не замечены.
Полагаю, что замечание также справедливо и к KOffice.
Как насчет обмена в odf(odt)? Вроде и тот и другой его поддерживают.
Утверждение не соответствует действительности.
Конкретный пример? Специально поставил abiword, сохранил в нем файл в odt и открыл в OpenOffice, никаких проблем не обнаружил.
Ни фига :)
> Ни фига :)
При умении писать хороший HTML-код — фига.
P.S. Со всякими AbiWord есть такая проблема, что doc в них поддерживается сильно хуже, чем в OOo. А к сожалению, по жизни среднестатистическому пользователю приходится открывать больше всего doc’ов. Поэтому рулит OOo. Сейчас со всеми этими форматами намечаются хорошие сдвиги, но на практике пока все именно так (в России).
не рассказывай людям про что не в курсе, а?
в бытность набора/верстки пособий (страниц по 100/200), именно предоставление грамотно созданного html позволяло открыть его в продуктах MS (Word, Publisher) и без корректировок (!!!) отправить на печать.
да, это стоило мне написания собственного конвертора и использования мета-языка разметки для ускорения набора/подготовки :)
поэтому — как раз таки text/html — наиболее кросс-платформенный формат на данный момент. при сильном желании OLE можно заменить ActiveX или прочим подобным инструментом.
На каком основании сделан столь далеко идущий вывод?
Встречное предложение аналогичного содержания.
Версталось с использованиям WYSIWYG?
Ну ты не ленив, я скажу…
И главный вопрос: *на фига здесь m$o?!?*
Об чём и речь.
Я ведь не утверждаю невозможности создания .html с требуемыми элементами форматирования.
Я только говорю, что штатными средствами оно не обеспечивается.
Ни .dvi, ни .pdf, ни даже .ps уже не канают?
Угу.
Вопрос в конвертере.
Ага.
Проблемы ОО я описал.
Хотя, здесь возможно проблема в сборке, но не уверен.
Поэтому между шашечками (степенью совместимости, априори не 100%, с ненужным мне форматом) и ехать (функциональностью и ресурсоёмкостью_ я выбираю последнее.
Вероятно у меня AbiWord собран иначе.
.odt в списке вариантов сохранения отсутствует.
Думаю, у тебя нет необходимого пакета, предположительно OpenWtirer.
Не-а :)
В моём случае это:
Только сути вопроса это не меняет:
с поддержкой сложного форматирования, независимо от формата — жопа.
Хотя есть подозрение, что при сборке ОО что-то пропущено…
Ты попробуй в твоей сборке ОО поработать с многоуровневыми списками.
Работа с многоуровневыми списками и в abiword и в OO просто ужасна! Мне удалось создать многоуровневый список в OO, сохранить, открыть в AW подредактировать и снова в ОО. При открытии ОО написал «общая ошибка», но открыл. Изначально кривой список:) (разный отступ для второго уровня у разных пунктов первого уровня), таким я его сделал в AW, стал ровным!
Кое-какие проблемы есть безусловно.
Интересно…
По мне: если не заморачиваться проблемами совместимости с m$o и альтернативными проектами — то многоуровневые нумерованные списки в AbiWord реализованы очень неплохо. Как минимум не хуже, чем в m$o.
Ты лучше расскажи как тебе удалось создать многоуровневые списки в ОО.
По умолчанию он одноуровневый, жмешь таб, делается отступ но нумерация все-рвано одонуровневая. Кликаешь на сервис->структура, выбираешь там желаемый вид.