Libreoffice не работает сумма

xlsxwriter и LibreOffice не показывает результат формулы

Я пытаюсь создать файл Excel с простой формулой:

созданный файл отлично работает в Excel, но при открытии в LibreOffice Calc формула не оценивается. Мне нужно повторно ввести числовые значения, и тогда это сработает.

что я делаю не так?

1 ответов

XlsxWriter не вычисляет результат формулы и вместо этого сохраняет значение 0 в качестве результата формулы. Затем он устанавливает глобальный флаг в файле XLSX сказать, что все формулы и функции должны быть пересчитаны при открытии файла. Это метод, рекомендованный в документации Excel, и в целом он отлично работает с приложениями электронных таблиц. Однако приложения, которые не имеют возможности для расчета формулы, такие как Excel Viewer или некоторые мобильные приложения будут отображать только 0 результатов.

Что касается того, почему пересчет не происходит автоматически, из ask.libreoffice.org ответ:

LibreOffice намеренно не пересчитывает старые электронные таблицы, потому что, поскольку формулы обновляются от версии к версии или между различными программами электронных таблиц, результаты могут быть разными. Перейти к инструментам-параметры-LibreOffice Calc, в разделе «пересчет при загрузке файла» измените два раскрывающихся списка: «Excel 2007 и новее» и «электронная таблица ODF (не сохраненная LibreOffice)» на «всегда пересчитывать». Нажмите кнопку ОК, закройте электронную таблицу и LibreOffice. Теперь откройте файл в LibreOffice, и вы увидите, что Формулы пересчитаны.

также перейдите в меню Сервис-содержимое ячейки и убедитесь, что Автокалькуляция выбранный.

Я подтвердил, что настройка «всегда пересчитывать «или» приглашение » работала для мне. Кроме того, вы всегда можете нажать control-shift-F9.

Источник

Коды ошибок в LibreOffice Calc

В следующей таблице описываются коды ошибок для LibreOffice Calc. Если ошибка происходит в ячейке, содержащей курсор, сообщение об ошибке отображается в строке состояния .

Ширины ячейки не хватает для отображения содержимого.

Символ в формуле недействителен.

Недопустимый аргумент функции. Например, отрицательное число в функции SQRT() (в этом случае следует использовать IMSQRT()).

Недопустимая операция с плавающей запятой

Вычисление приводит к переполнению определенного диапазона значений.

Ошибка в списке параметров

Недопустимый параметр функции, например, текст вместо числа или доменная ссылка вместо ссылки на ячейку.

Ошибка: нет пары

Отсутствует скобка: например, есть закрывающие скобки, но нет открывающих скобок.

Отсутствует оператор: например, в выражении «=2(3+4) * » нет оператора между символами «2» и «(«.

Нет переменной, например, в случае, когда два оператора стоят рядом «=1+*2».

Функция требует большего количества переменных, например, AND() и OR().

Слишком длинная формула

Компилятор: общее количество внутренних токенов (то есть операторов, переменных, скобок) в формуле превышает 8192.

Слишком длинная строка

Компилятор: идентификатор в формуле по размеру превышает 64 КБ. Интерпретатор: результат строковой операции по размеру превышает 64 КБ.

Операция сортировки, предпринятая на слишком большом количестве числовых данных (максимально 100000), или переполнение стека вычислений.

Внутренняя ошибка синтаксиса

В стеке вычислений предполагается матрица, но она недоступна.

Внутренняя ошибка синтаксиса

Неизвестный код: например, документ с новой функцией загружен в старую версию, не содержащую этой функции.

Внутренняя ошибка синтаксиса

Нет результата (в ячейке отображается #ЗНАЧЕН!, а не Ошибка:519)

Формула возвращает значение, не соответствующее определению, или ячейка, на которую ссылается формула, содержит текст вместо числа.

Внутренняя ошибка синтаксиса

Компилятор создал неизвестный код компиляции.

Внутренняя ошибка синтаксиса

Формула прямым или косвенным образом ссылается на себя, и не настроен параметр Циклы в разделе LibreOffice — Параметры Сервис — Параметры — LibreOffice Calc — Вычислить.

Процедура вычисления не сходится

Функция потеряла подбираемое значение или циклические ссылки не доходят до минимальных изменений для заданного максимального числа шагов.

недопустимые ссылки (вместо Ошибка:524 в ячейке содержится #ССЫЛ!)

Компилятор: не удалось определить имя описания столбца или строки. Интерпретатор: в формуле отсутствует столбец, строка или лист, содержащий ссылочную ячейку.

недопустимые имена (вместо Ошибка:525 ячейка содержит #ИМЯ?)

Идентификатор не может быть оценен (например, нет допустимой ссылки, нет допустимого доменного имени, нет подписи столбца/строки, нет макроса, неправильный десятичный разделитель, не найдена надстройка).

Внутренняя ошибка синтаксиса

Устарела, уже не используется, но может возникнуть из старых документов, если результатом является формула из домена.

Интерпретатор: ссылки (например, ссылка ячейки на ячейку) чрезмерно инкапсулированы.

Деление на ноль

Оператор деления/если знаменатель равен 0.
Эта ошибка возвращается некоторыми функциями, например:
VARP с менее чем 1 аргументом
STDEVP с менее чем 1 аргументом
ВАР с менее чем 2 аргументами
STDEV с менее чем 2 аргументами
STANDARDIZE с stdev=0
NORMDIST с stdev=0

Вложенные массивы не поддерживаются

Ошибка: Размер массива или матрицы

Неподдерживаемое содержимое встроенного массива

Внешнее содержимое отключено

Происходит, если встречается функция, требующая (повторной) загрузки внешних источников, а пользователь еще не подтвердил перезагрузку внешних источников.

Источник

Libreoffice Writer пропадают формулы

Иногда вставленная формула пропадает, а вместо нее остается просто прямоугольник. В этом году мне что-то с электроникой не везет. Доверять ответственную работу технике нельзя.

Ну и ССЗБ, что латехом не пользуешься!

напишите: номер версии libreoffice и последовательность действий, при которой наблюдается данная ошибка.

4.3.4.1 Какая последовательность? Просто пропадают неожиданно и все.

А почему в либре формулы работают чирижопу?

4.3.4.1 Какая последовательность? Просто пропадают неожиданно и все.

4.3.3.2. все работает. последовательность нужна для написания отчета об ошибке авторам, без неё ты просто пришел поныть.

Потому что либре- и прочие говноохфисы — порнография для абсолютных неосиляторов. А им пофиг, как формула выглядит: они все равно не понимают, что эта формула значит!

последовательность нужна для написания отчета об ошибке авторам

Вот тебе последовательность воспроизведения другой ошибки:

• открой LibreOffice Calc;
• выбери ячейку, контекстное меню, «формат ячейки»;
• во вкладке «обрамление» добавь сплошные границы дефолтной линией;
• во вкладке «выравнивание» поставь угол поворота текста 1 градус;
• примени изменения, нажав OK;
• наблюдай графические искажения.

Багу уже года полтора, наверное, если не больше. Описан, не исправлен.

Тут только ныть и остаётся, всё равно остальное не действует.

а в чем бага? в «выравнивании» есть Reference edge, поставь третий пункт. или я тебя не понял?

а в чем бага? в «выравнивании» есть Reference edge, поставь третий пункт. или я тебя не понял?

Да, третий пункт «чинит». Но это засовывание головы в песок. Ни при каких настройках выравнивания текста ободок не должен так выпирать, это баг.

Вот, кстати, ссылка: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=35510 . Ему уже три с половиной года, оказывается.

а как оно должно выглядеть для первых двух пунктов? на что надо это исправить?

а как оно должно выглядеть для первых двух пунктов? на что надо это исправить?

Когда я поворачиваю текст на один градус, я ожидаю, что он повернётся на один градус, но при этом останется внутри ячейки. И ожидаю, что на границы ячейки поворот никак не будет влиять. Сейчас же текст и границы выбрасывает далеко в сторону.

В багзилле (ссылка была в сообщении выше) есть два вложения-скриншота, «как выглядит» и «как ожидается».

Доверять ответственную работу технике нельзя.

А людям — и подавно. И вообще, 4.3.4.* ещё нестабильна, о чём плач-то? Кстати, как обстоит дело с аппаратным ускорением графики?

Лучи гнева.

Потребовалось набить определённое не самое малое количество формул. И тут эта свистопляска. Самое интересное, что картинка объекта сохраняется, но если попытаться её отредактировать, то в формуле пусто. При сохранении в формат docx вместо формул пусто.

Обновляю версию из debian experimental до 4.4.2-rc2, надеюсь поможет.

P.S. грош цена переведённым комментариям исходного кода с немецкого на английский язык, если на ровном месте пропадают данные.

Я не знаю, как там в Дебиане, но в Убунте сборка жутко падучая и какая-то кривая. Правда, формулы у меня не пропадали. Но иногда они рендерятся крайне странно.

Но, конечно, когда возникает такой баг с формулами, лучше всего сделать копию документа и посмотреть, что там происходит в оригинальном XML.

Обновляю версию из debian experimental до 4.4.2-rc2, надеюсь поможет.

Не помогает, увы.

Если с тебя требуют doc, пиши сразу в MSOffice. Если не требуют, пиши в latex.

Спасибо, буду иметь в виду, но вывод очевиден. Пока лучше обходить либру стороной.

Если с тебя требуют doc, пиши сразу в MSOffice.

Нюанс, что требуют docx, но docx с формулами, собственно, в либре набираю исключительно формулы, сохраняю в docx, дальше судьба документа меня не интересует — не мой фронт работы.

При сохранении в формат docx вместо формул пусто.

Это, как раз, возможно. По форматам полной совместимости никто не обещал.

Это, как раз, возможно. По форматам полной совместимости никто не обещал.

Нет, нет. Тут не в конвертере дело. Пропадают формулы, у которых

картинка объекта сохраняется, но если попытаться её отредактировать, то в формуле пусто.

Единственное, что радует. Пропадают, кажется, только новые формулы, старые не исчезают.

Как оказалось, по крайней мере в AOO, при такой последовательности действий по умолчанию (растяжение текста относительно нижней части канта) поворачивается не только текст, но и скашиваются боковые грани обрамления, что наглядно видно, если поставить угол поворота, например, 30 градусов. Поэтому сам текст на самом деле остаётся внутри обрамлённой области, отрисовка которой вываливается за пределы «ячейки». Похоже, что это фича такая. Поэтому при малом угле наклона «ромб» обрамления сильно вытягивает. Остаётся непонятным, с чего это вдруг боковые грани обрамления вообще меняют угол при повороте текста?

Это точно. Ло вообще непредсказуем своим поведением.

Ну надо же, почти два года прошло с того сообщения, я и забыть успел. А в свежем (5.2.3.1) LibreOffice всё ещё воспроизводится.

Ага. Не помню, было ли это тогда, но сейчас при выборе угла есть ещё выбор привязки. Можно выбрать привязку к нижней кромке, верней кромке и к середине. По умолчанию выбрана привязка к нижней кромке, что и приводит к такому выбросу. Если поменять на привязку к центру, поведение становится ожидаемым.

Непонятно, зачем только по умолчанию стоит привязка к кромке.

В libreoffice 5.2.3.3 формулы пропадают. Причем все симптомы те же, что описал человек, создавший тему. Последовательность действий установить не удается.

Источник

LibreOffice: страшный сон бухгалтера

LibreOffice — мощный офисный пакет, который бесплатен для частного, образовательного и коммерческого использования. Его разработчики делают замечательный продукт, который во многих сферах используется в качестве альтернативы Microsoft Office. Команде PVS-Studio всегда интересно взглянуть на код таких известных проектов и попробовать найти в них ошибки. В этот раз сделать это было легко. Проект содержит много ошибок, которые могут привести к серьёзным проблемам. В статье будут рассмотрены некоторые интересные дефекты, найденные в коде.

Введение

LibreOffice — очень крупный C++ проект. Поддерживать проект такого объёма — сложная задача для команды разработчиков. И, к сожалению, складывается впечатление, что качеству кода LibreOffice не удаётся уделять достаточного внимания.

С одной стороны, проект просто огромный, не каждый инструмент статического или динамического анализа осилит анализ 13к файлов исходного кода. Столько файлов участвует в сборке офисного пакета вместе со сторонними библиотеками. В основном репозитории LibreOffice хранится около 8к файлов исходного кода. Такой объём кода создаёт проблемы не только разработчикам:

С другой стороны, у проекта много пользователей и требуется найти и исправить как можно больше ошибок. Каждая ошибка может причинять боль сотням и тысячам пользователей. Поэтому большой размер кодовой базы не должен становиться поводом отказаться от использования тех или иных инструментов, способных обнаружить ошибки. Думаю, читатель уже догадался, что речь идёт о статических анализаторах кода :).

Да, использование статических анализаторов не гарантирует отсутствия ошибок в проекте. Однако такие инструменты, как PVS-Studio, способны найти большое количество ошибок ещё на этапе разработки и тем самым уменьшить объём работ, связанных с отладкой и поддержкой проекта.

Давайте посмотрим, что можно найти интересного в исходных кодах LibreOffice, если взять статический анализатор кода PVS-Studio. Возможности запуска анализатора обширны: Windows, Linux, macOS. Для написания этого обзора использовался отчёт PVS-Studio, созданный при анализе проекта на Windows.

Изменения с последней проверки в 2015 году

В марте 2015 года был выполнен первый анализ LibreOffice («Проверка проекта LibreOffice») с помощью PVS-Studio. С тех пор офисный пакет сильно развился как продукт, но внутри всё также содержит множество ошибок. А некоторые паттерны ошибок вообще не поменялись с тех пор. Вот, например, ошибка из первой статьи:

V656 Variables ‘aVRP’, ‘aVPN’ are initialized through the call to the same function. It’s probably an error or un-optimized code. Consider inspecting the ‘rSceneCamera.GetVRP()’ expression. Check lines: 177, 178. viewcontactofe3dscene.cxx 178

Эта ошибка исправлена, но вот что нашлось в самой последней версии кода:

V656 Variables ‘aSdvURL’, ‘aStrURL’ are initialized through the call to the same function. It’s probably an error or un-optimized code. Consider inspecting the ‘pThm->GetSdvURL()’ expression. Check lines: 658, 659. gallery1.cxx 659

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

Ещё один интересный пример из старого кода:

V656 Variables ‘nDragW’, ‘nDragH’ are initialized through the call to the same function. It’s probably an error or un-optimized code. Consider inspecting the ‘rMSettings.GetStartDragWidth()’ expression. Check lines: 471, 472. winproc.cxx 472

Этот фрагмент кода действительно содержал ошибку, которая сейчас исправлена. Но ошибок в коде меньше не становится… Сейчас выявлена похожая ситуация:

V656 Variables ‘defaultZoomX’, ‘defaultZoomY’ are initialized through the call to the same function. It’s probably an error or un-optimized code. Consider inspecting the ‘pViewData->GetZoomX()’ expression. Check lines: 5673, 5674. gridwin.cxx 5674

Ошибки вносятся в код буквально по аналогии.

Не дай себя обмануть

V765 A compound assignment expression ‘x -= x — . ‘ is suspicious. Consider inspecting it for a possible error. swdtflvr.cxx 3509

Вот такой вот интересный «Hack» был найден с помощью диагностики V765. Если упростить строку кода с комментарием, то можно получить неожиданный результат:

И в чём тогда заключается Hack?

Ещё один пример на эту тему:

V567 The modification of the ‘nCount’ variable is unsequenced relative to another operation on the same variable. This may lead to undefined behavior. stgio.cxx 214

Выполнение кода в таких ситуациях может зависеть от компилятора и стандарта языка. Почему бы не переписать этот фрагмент кода проще, понятнее и надёжнее?

Как не надо использовать массивы и векторы

По какой-то причине кто-то понаделал множество однотипных ошибок при работе с массивами и векторами. Давайте разберём эти примеры.

V557 Array overrun is possible. The ‘nPageNum’ index is pointing beyond array bound. pptx-epptooxml.cxx 1168

Последним валидным индексом должно являться значение, равное size() — 1. Но в этом фрагменте кода допустили ситуацию, когда индекс nPageNum может иметь значение mpSlidesFSArray.size(), из-за чего происходит выход за пределы массива и работа с элементом, состоящим из «мусора».

V557 Array overrun is possible. The ‘mnSelectedMenu’ index is pointing beyond array bound. checklistmenu.cxx 826

Интересно, что в этом фрагменте кода написали проверку индекса более понятно, но при этом допустили такую же ошибку.

V557 Array overrun is possible. The ‘nXFIndex’ index is pointing beyond array bound. xestyle.cxx 2613

А эта ошибка вдвойне интереснее! В отладочном макросе написали правильную проверку индекса, а в другом месте снова сделали ошибку, допустив выход за пределы массива.

Теперь рассмотрим ошибку иного рода, не связанную с индексами.

V554 Incorrect use of shared_ptr. The memory allocated with ‘new []’ will be cleaned using ‘delete’. dx_vcltools.cxx 158

Этот фрагмент кода содержит ошибку, приводящую к неопределённому поведению программы. Дело в том, что память выделяется и освобождается разными способами. Для правильного освобождения памяти необходимо было объявить поле класса таким образом:

Как дважды ошибиться в макросах

V568 It’s odd that the argument of sizeof() operator is the ‘bTextFrame? aProps: aShapeProps’ expression. wpscontext.cxx 134

К сожалению для многих разработчиков, аргументы макросов ведут себя не как аргументы функций. Игнорирование этого факта часто приводит к ошибкам. В случаях #1 и #2 используется почти одинаковая конструкция с использованием тернарного оператора. Но в первом случае — макрос, во втором — функция. Однако это только вершина проблемы.

В случае #1 анализатор на самом деле обнаружил следующий код с ошибкой:

Это наш цикл с макросом SAL_N_ELEMENTS. Оператор sizeof не вычисляет выражение в тернарном операторе. В данном случае выполняется арифметика с размером указателей, результатом которой являются значения, далёкие от реального размера указанных массивов. На вычисление неправильных значений дополнительно влияет и разрядность приложения.

Но потом оказалось, что существует 2 макроса SAL_N_ELEMENTS! Т.е. препроцессор раскрыл не тот макрос, как же это могло произойти? Нам поможет определение макроса и комментарии разработчиков:

Другая версия макроса содержит безопасную шаблонную функцию, но что-то пошло не так:

1. Безопасный макрос не включился в код;
2. Другим макросом всё равно невозможно пользоваться, т.к. успешное инстанцирование шаблонной функции выполняется только если в тернарный оператор передать массивы одинакового размера. А в этом случае использование такого макроса теряет смысл.

Опечаточки и copy-paste

V1013 Suspicious subexpression f1.Pitch == f2.CharSet in a sequence of similar comparisons. xmldlg_export.cxx 1251

Ошибка является достойным кандидатом для пополнения статьи «Зло живёт в функциях сравнения», если мы когда-нибудь решим её обновить или расширить. Думаю, вероятность найти такую ошибку (пропуск f2.Pitch) самостоятельно крайне мала. А вы как считаете?

V501 There are identical sub-expressions ‘mpTable[ocArrayColSep] != mpTable[eOp]’ to the left and to the right of the ‘&&’ operator. formulacompiler.cxx 632

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

V517 The use of ‘if (A) <. >else if (A) <. >‘ pattern was detected. There is a probability of logical error presence. Check lines: 781, 783. mysqlc_databasemetadata.cxx 781

В результате копирования условных выражений, в коде была допущена ошибка, из-за которой значение 8 для переменной nColumnSize никогда не выставляется.

V523 The ‘then’ statement is equivalent to the ‘else’ statement. svdpdf.hxx 146

Тут перепутали функции min() и max(). Наверняка из-за этой опечатки в интерфейсе что-то странно масштабируется.

Странные циклы

V533 It is likely that a wrong variable is being incremented inside the ‘for’ operator. Consider reviewing ‘i’. javatypemaker.cxx 602

Выражение ++i в цикле выглядит очень подозрительно. Возможно, там должно быть ++j.

V756 The ‘nIndex2’ counter is not used inside a nested loop. Consider inspecting usage of ‘nIndex’ counter. treex.cxx 34

Есть какая-то ошибка во внутреннем цикле for. Т.к. переменная nIndex не изменяется, происходит перезаписывание одних и тех же двух элементов массива на каждой итерации. Скорее всего, везде вместо nIndex должна была использоваться переменная nIndex2.

V1008 Consider inspecting the ‘for’ operator. No more than one iteration of the loop will be performed. diagramhelper.cxx 292

Цикл for намеренно ограничивается до 1 итерации. Непонятно, зачем это сделано именно таким способом.

V612 An unconditional ‘return’ within a loop. pormulti.cxx 891

Пример более простого странного цикла из одной итерации, который лучше переписать на условный оператор.

Ещё несколько таких мест:

• V612 An unconditional ‘return’ within a loop. txtfrm.cxx 144
• V612 An unconditional ‘return’ within a loop. txtfrm.cxx 202
• V612 An unconditional ‘return’ within a loop. txtfrm.cxx 279

Странные условия

V637 Two opposite conditions were encountered. The second condition is always false. Check lines: 281, 285. authfld.cxx 281

Анализатор обнаружил противоречивые сравнения. Что-то с этим фрагментом кода явно не так.

Такой же код замечен и в этом месте:

• V637 Two opposite conditions were encountered. The second condition is always false. Check lines: 1827, 1829. doctxm.cxx 1827

V590 Consider inspecting this expression. The expression is excessive or contains a misprint. fileurl.cxx 55

Проблема приведённого фрагмента кода заключается в том, что первое условное выражение не влияет на результат всего выражения.

По мотивам подобных ошибок я даже написал теоретическую статью: «Логические выражения в C/C++. Как ошибаются профессионалы».

V590 Consider inspecting this expression. The expression is excessive or contains a misprint. unoobj.cxx 1895

Сразу не понять, в чём проблема данного условия, поэтому из препроцессированного файла был выписан развёрнутый фрагмент кода:

Получилось так, что ни одно число не входит одновременно в 4 диапазона, заданных в условии числами. Разработчики допустили ошибку.

Источник