https://bugs.documentfoundation.org/show_bug.cgi?id=92256
--- Comment #19 from Christoph Lutz <[email protected]> --- (In reply to Markus Mohrhard from comment #17) > (In reply to Christoph Lutz from comment #15) > > Thanks bubli, for this summary. > > > > I abbreviate "formula syntax for string references" as FSFSR > > > > my +1 for 1a, 1b, 2a and 3 > > > > this also means that we have no longer a global FSFSR-setting, because this > > setting is always derived from a document by some logics (read explicit > > setting if present, heuristics for documents without explicit setting) > > We still need it for new documents. So the current global setting becomes > the default value for new documents. ok, agree. Question: how to represent and distinguish document specific FSFSR and default FSFSR settings in the GUI? I first thought, we could reuse the existing "global FSFSR" dialog and just make it document specific. Should we add another option "formula syntax for string references in new documents"? (have no better idea ATM) > > regarding 2b and 4: > > > > I think an alternative solution for Export to excel could be to treat xls(x) > > documents always as FSFSR=EXCEL A1, in both directions, import and export. > > > > This would also de facto prevent the users from storing documents with > > FSFSR=CALC A1 to xls(x): > > > > 0) let's asume I have got a spreadsheet with Indirect-Functions that uses > > strings in calc syntax. If this document is stored to xls(x), then the > > following things happen: > > > > 1) I get the typical "would you really like to export to an alien format" > > dialog > > > > 2) FSFSR is automatically switched to EXCEL. > > > > 3) Now some formulars in the document are no longer evaluated as (possibly) > > expected. The user is forced to change the syntax of the strings in order to > > make the document running with EXCEL syntax evaluation. > > > > 4) if the file is stored for a second time, it is also interoperable with MS > > Excel. > > > > With this idea, I would not store any settings to xls(x) documents, because > > it is automatically fixed to EXCEL. > > I'm sorry but this solution is unacceptable from several points. > > The first one is obviously legacy documents, there are millions of documents > out there created by Calc that use Calc A1 in OOXML documents. wow, this confuses me. Isn't this exaclty the situation that you wanted to prevent by introducing this global FSFSR setting? OOo had no problems with So it is clear, that these Excel documents will never be shown correctly by the typical default application MS Excel. Clear, this could happen in legacy documents, but I think this was a mistake of the past and we should do better in future. I still think it would be better to prevent users from creating MS Excel incompatible XLS(X) documents. > Next it is not possible to automatically convert between Calc A1 and Excel > A1 in the indirect function. As a result the only thing we could do is to > issue a warning during saving that this will cause interoperability issues > (well we are doing that already with the "alien format" warning. I don't like the current "alien format" warning dialog. It misses transparency. As a user I would like to know, which exact features of my current document will be lost during export. I think I once saw that MS Office showed me a dialog with a list of features that will get broken during export into an "old format" like rtf. If we had such list in LibreOffice, too, It would be easy to add a new list entry like "your formula syntax for string references is changed to EXCEL A1, please check your strings". This is what I would expect if I export into an alien format. But ok, such a feature would cost a lot of time (probably too much time) and is of course a completely different tasks, so we don't need to deepen that here. But this should be no excuse for not improving the above situation. > > Changing the setting of the in-memory version is an absolute no-go from a UX > and Calc perspective. I don't stick at the suggestion to automatically change the FSFSR during export. Maybe we could find another way of forcing the user to change FSFSR manually? But we first need to get to a common sense whether we want to avoid the future creation of non interoperable XLS(X) documents (with FSFSR =! EXCEL A1)? > A user would not expect that saving changes the in-memory version of the > document. Therefore it would silently introduce errors in the document which > is unacceptable. It is not "silently" due to the "alien format" warning. With the current LO version, it is possible to silenty produce non interoperabe XLS(X) documents (if FSFSR != EXCEL A1). The question here is: when does the user recognize that something is wrong? I suggest to force the user (in either way) to recognize the really existing interop issue as soon as possible - which means best in the current calc session. At the moment, you need first to open the document in Excel (which could be months later) before you recognize the interop issue (maybe you hope that the issue is never discovered?). > Additionally it will cause issues if you save the document > the next time in ODS as you are not saving the same document that you > originally created. agree for the workflow: open an existing ODS document with FSFSR=CALC, export the document to XLS(X); do nothing else with the XLS(X); open the XLS(X) document in LO and store it back to ODS. How important is this workflow? Why are you exporting it to XLS(X) if you want to do nothing with it inbetween? > All in all the only acceptable solution to mitigate the problem a bit is to > move forward with a ref string syntax element for OOXML as well. Just thinking about bubli's "I'm afraid we can't do much for binary xls here". I would prefer a solution that is consistent for XLS and XLSX. The above suggestion is. > The > interesting thing is to write the algorithm for detecting the ref string > syntax when there is no such element in an ods or xlsx document. OK. Since we should get a common sense about the heuristic for the case that ODS and XLSX documents don't have got a FSFSR setting, I will write down some suggestions: docFSFSR is the FSFSR-setting that comes with the document Import-heuristic 1) 1.a) if XLS(X) document, set FSFSR=EXCEL A1 1.b) if ODS && !docFSFSR, set FSFSR="CALC A1 or EXCEL A1" 1.c) if ODS && docFSFSR, set FSFSR=docFSFSR 1.d) if new document, set FSFSR=default-Value from profile Import-heuristic 2) [try to be more case/creator specific] 2.a) if XLS(X) && !docFSFSR && creator=MS, set FSFSR=EXCEL A1 2.b) if XLS(X) && !docFSFSR && creator=LO, set FSFSR="CALC A1 or EXCEL A1" 2.c) if XLS(X) && docFSFSR, set FSFSR=docFSFSR 2.d) if ODS && !docFSFSR && creator=LO, set FSFSR=CALC A1 2.e) if ODS && !docFSFSR && creator=OOo, set FSFSR="CALC A1 or EXCEL A1" 2.f) if ODS && docFSFSR, set FSFSR=docFSFSR 2.g) if new document, set FSFSR=default-Value from profile another suggestion? more cases that we should consider? For clearness I would prefer heuristic 1) but I'm open for discussion. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
