When inserting a Formula Field (Insert...Field...More Fields...Variables...Insert Formula), Writer behaves differently depending on whether the current insertion point is or is not inside the table. When in a table, Writer treats the action as inserting a table formula. Outside a table, they insert a formula field. See the "TYP_FORMELFLD" case in SwFieldMgr::InsertField in fldmgr.cxx These two formula types is different. As an example, in the Formula field, variables are available - not so in the table formulas. If the field is inserted outside the table, it can be copied into the table, where it works correctly. However if the field is inserted directly into the table, it is likely to be invalid because it is using the wrong formula type. Additionally, table formulas that are not the only content in their cells appear not to generate any results. Because of this, when inserting a formula field in a table cell, other than as the only thing in the table, it appears that nothing has happened at all. The current behaviour is confusing and inconsistent. Suggested behaviour: 1. Inserting the field from the Insert field dialog should always insert the field, even if in a table. 2. If it is preferred to keep the current (different) behaviour with the formula bar, the UI should make it clear what is going on. I have not looked at whether the syntax for the two formula types is compatible at a high level, so that the table ones could be merged into the formula field.
Confirming on Windows 10 Pro 64-bit en-US with Version: 5.4.0.0.beta2 (x64) Build ID: 3cc1cdd8ee50f144e5514da51800a08119754d8f CPU threads: 8; OS: Windows 6.19; UI render: GL; Locale: en-US (en_US); Calc: group I have not traced it through the source but "Insert Formula" field objects are evaluated differently depending on placement into a Writer paragraph object or into a table object. Attaching a simple sample Flat ODF document .fodt Also wrong meta, adjusted to bug 107739
Created attachment 135343 [details] sample insert field insert formula into paragraph vs table cell
Within the table it's a true field too just not highlighted (field shading). You can modify the forumla per F2. Nevertheless both workflows should be the same. I would understand this as a bug. Or are there any technical restrictions?
Outside a table a <text:expression> is generated, which is child of a paragraph. This implies, that you can have text before and after the field. Strg+F9 toggles between value and field view. Inside a table an attribute table:formula of the <table:table-cell> element is generated. The <text:p> element in the <table:table-cell> reflects the value, so that consumers, which do not understand the specific formula language can show the current value. It is not possible to have text around the formula. If you have already text in the table cell and use this dialog, the text is removed. But that is an restriction of the UI. You can copy a paragraph including the field into a cell, and it will work the same as outside. (example file will follow) I think, that it is inconsistent and confusing, that the Insert > Fields > More fields > ... way does not insert a <text:expression> element into the cell but erases existing text, although a paragraph including such element works inside a table-cell too. The other way round is confusing too. The command .uno:InsertFormula (the icon with fx on it or shortcut key F2) opens the formula input bar. If the cursor is inside a table cell, the table:formula is inserted. That is the same behavior as in Calc. But if the cursor is outside the table, the formula input bar inserts a <text:expression> element. But inserting a field belongs to the .uno:InsertField command. My suggestion would be to make a strict distinction in the UI between .uno:InsertFormula and .uno:InsertField and not let one behave as it would be the other one.
Created attachment 135386 [details] mentioned example file Use Ctrl+F9 to toggle between value and field view. Notice, that the formulas of the formula cells are not affected by this command, because they are no fields.
(In reply to Regina Henschel from comment #4) > Outside a table a <text:expression> is generated... Inside a table an > attribute table:formula of the <table:table-cell> element is generated. Is there any good reason to make this distinction? I mean why not 'ignore' the table:formula and just use text:expression in the table as well.
(In reply to Heiko Tietze from comment #6) > Is there any good reason to make this distinction? I mean why not 'ignore' > the table:formula and just use text:expression in the table as well. (1) I think, the central idea is in the note in section "9.1.1 General", "Note: There is only one model for tables, although tables, such as for spreadsheets, may have additional capabilities when compared to tables in text documents." That means, that cell attributes, formula included, are treaded the same in Writer and Calc. Historically LibreOffice uses different syntax for formulas in Writer and Calc, but that is not a demand of the specification. (2) If you use a <text:expression> element, then it is child of a <text:p> element in the content of a cell. That adds two levels nesting to access the formula. (3) Each cell has a type, defined by the office:value-type attribute and a value, defined by one of the office:value, office:boolean-value, office:string-value,... attributes. Only in case of office:value-type="string" and missing office:string-value attribute the cell content itself is the "value" of the cell. The <text:expression> element is child of a <text:p> element in the content of a cell. The content of the cell can only be "value" of the cell, if the cell is of type string. But if it is a string, you cannot calculate with the value, at least not with the Writer formula syntax, which does not know any string-functions. If you provided an automatic conversion, you would get all the problems of text->number conversion and its language dependency known from Calc. (4) The office:value is faulty in <text:expression> in current implementation. Its value is always 0 but should be the result of the formula.=> bug 111674
Following Regina's arguments based on the format specification, the formula handling is intentionally different depending on whether its placed in a table or not.