Регрессия - fdo#73609

[ape]

Есть, имхо, необходимость посмотреть эту ошибку импорта XLS (файл во вложенном архиве) - Bug 73609 - Other: wrong autofill of cell ranges in functions
Её статус, NEEDINFO, не позволяет надеяться на исправление. Явная регрессия - LibO-3.6.7 и 4.0.6 открывают файл без проблем.
Но, начиная с 4.1.5, есть проблемы (только OS Windows):
- попытка открыть файл из Центра запуска вызывает авост Офиса;
- если открыть файл из Проводника, то всё ОК, кроме одного (см. скрины)

[вложение удалено Администратором]

[ape]

LibreOfficeDev 4.1.6.0.0+ (ID: b6d9aa63ab63f3236712b2b68155e6b0d129a68) работает нормально. Извините за неточность: пришлось править реестр, т.к. файл демонстрирует 2 разных ошибки.

[ape]

По следам этого сообщения http://forumooo.ru/index.php/topic,4104.msg25066.html#msg25066 посмотрите, пожалуйста, XLS-файл 1-го сообщения этой темы. При этом:
- его нужно и можно открыть Калком (лучше всего 4.0.6-4.1.3) из Проводника и параллельно в Excel;
- обратите внимание на $Sr.G10: в Калке значение правильное, в Экселе - нет.
Дополнительно посмотрите и этот файл (http://forumooo.ru/index.php?action=dlattach;topic=4104.0;attach=6431), который при использовании 4.1.4 и более новых надо открывать из Проводника.
Я не могу понять:
Книга Эксель создана не в Эксель, а в АОО\ЛО? Мнение сложилось из-за $Sr.G10 - номер колонки, $TPM.FA349, для XLS выходит за пределы допустимого.
Если XLS создаётся в ЛО экспортом ODS в бинарный формат, то почему нет обрезки колонок, выходящих за предел, допустимой для этого формата?
Почему мой ODS (сохранил в LibO-4.0.6 приложенный XLS-файл как ODS) в LibO-4.1.4 и последующих открывается только из Проводнка? Изменён порядок запуска и что-то теперь не грузится?
--
Я нашёл несколько "подъёмов" этой ошибки, но всё, похоже, присоединяют к этой: https://bugs.freedesktop.org/show_bug.cgi?id=76611
Маркус снизил её до важной. Мне кажется, что отделив мух от котлет, надо заводить несколько ошибок:
- по вылету Офиса на партикулярном ODS при открывании оного не из Проводника;
- по экспорту в *.xls без ограничения числа колонок;
- ну и собственно на безобразии $Sr.L->>>
--
Валек, мне будет крайне сложно объяснять это Маркусу. Возможна ли Ваша поддержка в Багзилле в виде пояснений, если мой английский опять будет кривоват?

[frob]

по экспорту в *.xls без ограничения числа колонок

В какой-то из непоследней свежести версии XL были изменены максимальные размеры таблицы. Правда не помню касалось ли это XLS или только XLSX.

[ape]

- по вылету Офиса на партикулярном ODS при открывании оного не из Проводника;

Здесь есть уточнение.
Скорее всего, есть какое-то нарушение формата файлов или\плюс изменение параметров запуска Калка последних версий. Я перепробовал открывать все производные (.xls; .xlsx; .ods_v1.0/1.1/1.2ext) от исходного DEH Sr31 Feb  2014.xls. Офисы не падают: soffice.bin  и soffice.exe ЗАПУЩЕНЫ(!-?). Но почему-то включается процесс восстановления этих файлов. Все открытые в других окнах файлы, с которыми работаешь в это время закрываются без попытки записи внесённых в них изменений.

по экспорту в *.xls без ограничения числа колонок

В какой-то из непоследней свежести версии XL были изменены максимальные размеры таблицы. Правда не помню касалось ли это XLS или только XLSX.

Мне кажется, что нарушение формата - выход за допустимое число колонок, доступных для электронных книг XLS формата, всё-таки есть:
- откройте DEH Sr31 Feb 2014-406.ods;
- сохраните его как XLSX;
- откройте экспортный XLSX в МСО;
- посмотрите на ячейку $Sr.G10 - она показывает правильное значение =TPM!FA349, т.е. число, содержащееся в ячейке $TPM.FA349.

[ape]

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

Восстановление файла DEH Sr31 Feb  2014.xls заканчивается ничем - XLS файл не открывается, запускаются только другие файлы, но с утерянными изменениями.

[ape]

Мне кажется, что нарушение формата - выход за допустимое число колонок, доступных для электронных книг XLS формата, всё-таки есть:

Подтверждение на скрине: не только Excel_2007, но и Gnumeric_1.12.12 дают одинаковый результат невозможность считывания данных ($Sr.G10) и вычисления суммы ($Sr.О10) в DEH Sr31 Feb  2014.xls.
--
22:00 Нашёл домашнюю машинку с МСО-2003.3 (все возможные обновления выполнены + ODF_Add-in). Максимальное число колонок так и осталось 256, т.е. - "IV". Думаю, что надо "столбить" баг. Но чем аргументировать "критический" уровень: несоответствием файловому стандарту из-за чего возможна потеря информации, которую автор, использующий ЛибО не заметит, а адресат, получивший такой файл и использующий Гнумерик или МСО увидит сразу?

[вложение удалено Администратором]

[ape]

- по экспорту в *.xls без ограничения числа колонок;

Это моя ошибка..
Нет, подрезка "ширины" листов до 256 строк  была и есть сейчас. Но один дефект всё-таки нашёл. Он появился в LibreOffice-3.6.
Дело в том, что LibreOffice-3.5, прежде чем сохранять слишком "широкий" XLS, выдавал предупреждение, которого сейчас нет (см. вложение). Поэтому пользователь может не знать, что потерял строки при экспорте ODS файла в XLS формат.
--
По файлу "DEH Sr31 Feb  2014.xls" - похоже, что он всё-таки экспортирован их ODS формата с помощью LibreOffice-3.6 или более поздней. Исходя из листа Sr, строки Е, ряды 69-100, первоначальный файл имел 33 листа, т.е. более доустимой нормы. В результате, без предупреждения пользователя, лишний 33-й (ЕСЕ - см. Е100) лист был удалён при экспорте файла.

[вложение удалено Администратором]