Вот любителям порассказывать о жирноте kde-libs: http://ingwa2.blogspot.com/2012/05/overhead-of-kde-software.html

Если лень читать или с инглишем не сложилось - пост о том, что kde-libsв не-КДЕ среде кушают аж целых 48 Мб оперативки. Если для Вас это - много - пользуйтесь только консольными текстовыми редакторами.

Очевидно, что какое-то количество ранее работающего было поломано в результате изменений.

Могу привести конкретный пример. При переходе с 3.4 на 3.5 в либре изменилась конфигурация порядка кнопок на панели. В итеге настроенные панели у меня полетели и пришлось их заново перенастроить (убрать разделители в конце каждой панели). Но при этом я не могу утверждать, что новый способ хуже старого, ибо так вроде даже логичней.

http://office.microsoft.com/ru-ru/ctndirectdownload.aspx?AssetID=TC010206070

Аа, понятно, ты казачок из стада МСО. А я уже ожидал одф документ, сделанный в ЛО и рушащий ОО. Этот документ и ЛО не открывает.

Что значит уже? ещё Sun жив был, уже 100 лет как умело

добавлена поддержка векторного формата SVG во всех приложениях пакета

ураа!
теперь вместо мыльного PNG можно будет вставлять годный вектор из инскейпа!

И где? Реально интерестно, с ним как то удобней было.

http://office.microsoft.com/ru-ru/ctndirectdownload.aspx?AssetID=TC010206070

Ага, в ЛО надо было доставить draw, тогда открывает. Но по-любому, это не тот случай. Давай родной формат.

учитывая несравнимо большую ресурсоёмкость по сравнению с MS-Office на сколь нибудь больших и сложных файлах, ...

Спорный и неоднозначный вопрос. На ОЧЕНЬ больших файлах да, МСо лучше. А на малых файлах или просто большом количестве файлов экономичней ЛИБо. Плюс у МСо рендеринг встроенных объектов в процессе прокрутки, а у ЛИБо всё за один раз, что быстрее.

Этот документ и ЛО не открывает.

В криокамерах подешевели места, уже и анонимусов пускают?

http://farm8.staticflickr.com/7214/7164245862_d0f817c05b.jpg

Ну предположим амарок, дельфин, кдешный органайзер и реконк с копитом не должны являться жёсткой зависимостью для офисного пакета. Или вы считаете по другому?

VST — «родной» формат MS Visio.

А не тот случай — это ты.

Плюс у МСо рендеринг встроенных объектов в процессе прокрутки,
а у ЛИБо всё за один раз, что быстрее.

Хмм... Недавно файлил баг за кого-то — writer тормозит при прокрутке документа натыкаясь на вставленное что-то.

Не поддерживаю закапывателей.

Всё верно. Проще перечислить что ещё не предлагали закопать. Но к сожалению что то такое почти не реально вспомнить.

Ну, есть такое. А в МСо (по крайней мере том, что у меня стоит) это штатный режим работы.

Я вообще не про то, что он тормозит при прокрутке, а про то что в МСо формулы и картинки расшифровываются и вставляются в документ только в процессе прокрутки, а в ЛИБо после загрузки они уже на местах и дополнительного времени для открытия не надо, только прокрутить.

Сколько виндусятников. Там же из-под линукса этот файл даже не отображается для скачки.

Зависимости определяет мантейнер пакетов в твоем дистрибутиве - претензии к нему.

Я не знаю как устроен МСО, но предполагаю, что для рендеринга вставленных объектов используется хранящаяся рядом EMF-ная превьюшка. А EMF — это +/- запись GDI-шных команд в файле, т.ч. рендериться должно довольно быстро. Хотя если это дело отрендерить и закэшировать растр, то может и быстрее будет.

Хмм... MS какую-то активно-куковую мутотень развёл у себя.

http://visio.microsoft.com/ru-ru/Templates_And_Downloads/Sample_Diagram_Templ...|a37176ad-3309-4715-a814-37c68e08f729

Так лучше?

Открываешь OpenOffice Writer - сервис - параметры - OpenOffice.org - память - использовать быстрый запуск(поставить галочку). Но смысла в нем нет, т.к. если кликнуть на любой документ, то он так же долго будет открывать. Единственное, только, если запускать этот документ через меню файл(. В общем бредовая реализация это функции, разве что с трея быстрый запуск голого файла.

Просто ещё с 2.4 и до 3.1 или 3.2 был прелоад, и было реально быстрее, т.к. 2.4 запускался довольно долго. А потом его вырезали, а я как то привык.

НЕ НУЖНО

«НЕ НУЖНО!» - уже говорили? Оно нужно только бюрократам, а бюрократы всё-равно будут использовать мсОфис

Толсто же.

А заморочки с лицензиями меня как-то не интересуют

ну вот и иди обратно в стойло, не мешай умным людям общаться.

OpenOffice? 0_o

код перелицензирован под лицензией Apache License 2

Не надоело ещё их маркетологам ерундой заниматься? Лучше бы код писали, чем всю эту маркетологическую лицензионную муть разводить.

Я вижу, апачи, как и бздуны, любят открытый код выкладывать так, чтобы какой-нибудь Гейц взял, сделал закрытый форк под EULA и выпустил как Super Mega Software Всяко Edition, продавал за большие деньги и большие же деньги экскаватором загребал. iZEN, случайно, не рассказывал, откуда в Windows, до того поддерживавшем только IPX, взялся полноценный TCP/IP стек?

откуда в Windows, до того поддерживавшем только IPX, взялся полноценный TCP/IP стек?

ну взялся, а что в этом плохого?

Пакетный менеджер у меня там уже есть :)

Эпик фейл, от бзди там микроскопический кусок какой то утилиты типа ping. Да, они поглядели и изучили бздишный стек, но что то не понравилось и за базу взяли что то другое (не помню, какая то экзотика типа VAX VMS). Очень гордились что сами много что приумали.

ага, то-то там даже /etc/hosts есть.

C:\WINDOWS\system32\drivers\etc\hosts тоже сами придумали?

Вот и не утверждай, если не помнишь.

Маленький список нововведений. Я читал вчера на одном ресурсе, там ими целый A4 заполнить можно было.

откуда в Windows, до того поддерживавшем только IPX, взялся полноценный TCP/IP стек?

А что есть достоверные подтверждения что вот так взяли и скопипастили? Стек из BSD послкжуил для многих эталонной моделью.

Продолжу мысль.

1. https://en.wikipedia.org/wiki/Spider_Software 2. http://technet.microsoft.com/en-us/network/bb545475.aspx

Возьми Windows до Vista, утилиту findstr и файл ping.exe. Попробуй найти в нём слово BSD.

Эталон и МыВотЭтоВозьмёмСделаемСвоим это разные вещи.

Маленький список нововведений. Я читал вчера на одном ресурсе, там ими целый A4 заполнить можно было.

А где можно прочесть, не поделитесь ссылкой?

А где можно прочесть, не поделитесь ссылкой?

вот здесь можно, но ссылку на тот ресурс тоже хочу, на всякий случай )

«Windows Sockets ... является реализацией в среде Windows широко распространенного интерфейса Berkley Sockets, используемого для создания сетевых приложений.»

Пруф: Windows Server 2003 из серии «В подлиннике», стр. 482. http://www.ozon.ru/context/detail/id/1580451/

Не 1с, а pyExelerator. К сожалению, автор последнего потерял интерес к проекту.

проблемы исчезают и после пересохранения в ООо

А чем оно хуже LO?

Две ссылки. Одна на английском. Вторая на opennet.ru, но не так подробно описаны все нововведения.

НОрмально открывает документы MSO

Это прискорбно, но победит, как всегда, маркетинг. У Apache™ и OpenOffice™ неплохая фора.

В общем расклад вот какой: 1. В твоих файлах pyExcelerator прописал в записях Row в качестве miyRw значение 33023, иначе говоря — приблизительно 23 дюйма для высоты строки. 2. Спецификация XLS говорит, что значение miyRw должно быть signed int от 1 до 8192 включительно. <в принципе на этом месте можно было бы сказать «так что сам дурак» и уплыть в бесконечность с гордо задранным носом> 3. Если нагло выставить в этих же записях fUnsynced, то наплевав на свою спецификацию XL читает unsigned int и выдаёт строку дикой высоты =)

Предположительно, в случаях когда fUnsynced сброшен, значение высоты строки надо пересчитывать исходя из необходимого для того, чтобы текст влез. Возможно автор pyExcelerator словчил специально, чтобы не заморачиваться с высотой строк, а свалить пересчёт на XL. Кохей почему-то считает, что такой пересчёт обойдётся довольно дорого и будет отжирать от 5 до 50 секунд при импорте файла. Откуда взялись такие предположения не знаю. Андреас считает, что аналогичный хак для гнумерик будет мало влиять на время импорта (однако патч не накатил).

Что решат в LO пока неясно. Если без pyExcelerator жизни нет, то я бы посоветовал посмотреть где/как оно пишет Row->miyRw. Ну или поковырять ssconvert из gnumeric. К нему вроде бы и питонский биндинг был.

Я склоняюсь к переделке необходимого API pyExcelerator-а, но с завязыванием на jython и POI.

Кохей почему-то считает, что такой пересчёт обойдётся довольно дорого и будет отжирать от 5 до 50 секунд при импорте файла.

Зря он так считает. Я, после коммента № 5 специально пробовал открывать большие файлы в LO и OOo. На глаз большого проседания по перфомансу я не обнаружил.

Еще один, делающий выводы за меня? Где это сказал, что это единственный пример? ;-)

И да, дальнейший поток сознания я не распарсил. Может еще не проснулся...

s/Где это сказал/Где это я сказал/

быстрофикс