Scenario: User opens a non-ODT document for editing, starts making edits, and at some point introduces something into the document which would be lost when saving the file in its original format. Examples: * An XLSX is edited, and a function is used which MS Excel does not support, or a chart type it's missing. * A DOCX is edited, tracked changes are made, and a comment is made on a tracked change (i.e. not Insert > Comment). At the moment - the user is none the wiser, until they try to save the document, and will then be warned that the save will be destructive because of format limitations. But by then, it is very late to do something about - some time may have passed, many such items or aspects may have been introduced, and further editing done which relies on them. Also, IIANM, the user does not get an exhaustive list of unsupported aspects/pieces of the document to review. For that reason I suggest that, when editing a file in a given format, and when we first introduce something into the document unsupported by the format, we could alert the user to this through: * An info-bar * A pop-up dialog * Some kind of visual indication in the status bar this alert could ask the user "do you really want to do XYZ?" Or it could just tell them that the last change breaks the file format.
(In reply to Eyal Rozenberg from comment #0) > For that reason I suggest that, when editing a file in a given format, and > when we first introduce something into the document unsupported by the > format, we could alert the user to this through: > > * An info-bar > * A pop-up dialog > * Some kind of visual indication in the status bar > > this alert could ask the user "do you really want to do XYZ?" Or it could > just tell them that the last change breaks the file format. Pointing out differences by individual warnings is as good as pointless. At least for Writer. The document-model of LibreOffice being inherently different. There are so many area's common cases where 'conversions occur' From image an anchor conversion, styles, highlighting A nice example: bug 125268. It's including a bunch of comments of handling the compatibility matter.. Importing a file generated by MSO in LibO and saving it back to DOCX without any change does already create quite a lot of differences.
We pondered over this in the ESC considering the warning on save. Would be nice to learn what exactly is not compatible. But it requires every single aspect to be listed somehow in a table, hard to imagine. Your proposal goes even further. You assume users load _and save_ alien formats thinking only of Microsoft's proprietary file types. But how about reading a simple text file in order to store as ODF? Or to improve an alien document and eventually saving as ODF? Or CSV => ODS, MD => ODP, etc. Sound to me like a hHuge effort with limited benefit, obviously over-engineering.
(In reply to Heiko Tietze from comment #2) > We pondered over this in the ESC considering the warning on save. Would be > nice to learn what exactly is not compatible. But it requires every single > aspect to be listed somehow in a table, hard to imagine. ... which is exactly why I would not suggest that. > Your proposal goes even further. But it's not going in the same direction :-( > You assume users load _and save_ alien > formats thinking only of Microsoft's proprietary file types. But how about > reading a simple text file in order to store as ODF? Or to improve an alien > document and eventually saving as ODF? Or CSV => ODS, MD => ODP, etc. The question of what format will eventually be saved is something I suggest explicitly not caring about here. The reference is just the original format. So, for example, if you open a CSV and, say, change the font size or text color, - you would get notified that you won't be able to save those changes in the open file's original format. Yes, you might intend to save it as an ODS, but LO doesn't know about that while you're only editing and have not saved-as. Once you _have_ saved as - this is a non-issue. So, if you first save as ODS, then change the font size - no warning. Same for MD => ODP or any other change. So, what's the big benefit here? If we have a warning-on-save anyway? It's the fact, for at least one change - the first format-breaking change, the user will be _fully_ aware of what they're doing and what they're risking. Yes, it might not be the most critical change that might be lost, but we would not need to keep track of different kinds of changes, nor will the user need to rummage through their memory and decide what's important. The first format-breaking change is the _best_ time to warn the user, and when they are the least invested in format-breaking change and will be the least frustrated.
I would stick with warn-on-save. Aside of effort of implmentation, wanr-on-incompatible-change seems to introduce a lot of open questions like how "incompatible change" is defined, when we assume "editing" (with intent to change the file in place) and when we assume "import" (with intent do store in another format). (an alternative pattern to warn-on-save is what some image editors do – differentiate between "save" (native format) and "export" (andthing else))
(In reply to Eyal Rozenberg from comment #3) > It's the fact, for at least one change - the first format-breaking change, > the user will be _fully_ aware of what they're doing and what they're > risking. Yes, it might not be the most critical change that might be lost, > but we would not need to keep track of different kinds of changes, nor will > the user need to rummage through their memory and decide what's important. > The first format-breaking change is the _best_ time to warn the user, and > when they are the least invested in format-breaking change and will be the > least frustrated. This would be the solution in the ideal world. However there is not even a list of format-breaking changes. And in case of Writer it's likely so common, that's rather absurd to do this on case basis. At least if you take full compatibility as the norm. There is so much emulation going on. So you might get file which looks the same, but acts differently compared to native generated one. Say a single style in Writer, becoming split 20 (paragraph) styles on docx export. Looks fine, but less useable. Defying the point main for using (paragraph) styles. Other alternatives * Info bar appearing when you start editing a foreign format, some general warning about non-standard file format * Foreign formats opening in read-only. Forcing/proposing to save as native format before editing. Related: Being able to (directly save (as) foreign format XYZ suggest (full) compatibility. Save as should be limited to fully supported formats. Else it would be better to put it under export. Technically speaking; not sure if this being feasible from real world perspective
I broadly agree with the statement/request that Eyal is making, if part of your reason for using a particular file format is to ensure that any changes made to the document be compatible with the original used file format then an info bar like message could be helpful. I understand the logic of this request, as an example, if I have spent an hour working on something and then my changes made are "useless" because I will need to switch to another format that I did not intend to use. I would propose an info bar like message to explain this to the end user, if the users then does not want these further dialogs displayed in the then provide an option to dismiss them permanently.
A default pop-up warning at start up, or during the edit, would be a good thing before investing time with edits only to find out at SAVE TIME that the end result would be undesirable.
(In reply to Eyal Rozenberg from comment #3) > It's the fact, for at least one change - the first format-breaking change, > the user will be _fully_ aware of what they're doing... Another example: You can direct format text as bold or via character style, both are saved as <b> to HTML (and I would argue this is always DF). IOW, you have a technical perspective on data and a user POV, depending on expertise and workflow. If you warn the first time about "styles are not stored with HTML" users might not care but if it comes to another incompatibility they will for sure. So you have to do it for every single attribute. Same argument in comment 5. I doubt the use case of Benjamin loading an "extra format", something that is not primarily suited for text processors or spreadsheet apps like html, rtf, csv etc., expecting a different function set works the same way. Expert users probably not invest "hours of working" ending up in being surprised on save. When it comes to "similar formats" like odf - docx, we should rather aim for 100% compatibility - and still get into situations where the proprietary format has its limitation. More generally: Why do we always care about other applications? We should proudly present our work and only secondarily consider other tools. User running LibreOffice are supposed to work with ODF - period.
(In reply to Heiko Tietze from comment #8) > More generally: Why do we always care about other applications? We should > proudly present our work and only secondarily consider other tools. User > running LibreOffice are supposed to work with ODF - period. I fully support this in principle. Would give more freedom, instead of constant compromising functions and such on foreign formats. And well file formats become probably less of an issue with cloud solutions. A bold move would be that instead the naging non-standard file format dialog forcing to save into native format. With some setting in the options dialog "Load and Save" to overrule this setting. This would prevent irreversibel dataloss because of file-format differences However this still doesn't fix the case of newbie opening/editing using foreign format and expecting to be able to (a) save it back into that format (b) with 100% compatibility
(In reply to jan d from comment #4) > Aside of effort of implmentation, This would certainly require some work. But - not being an LO developer myself, I want to ask you to elaborate: How much of an effort would you estimate this to be? That is, considering we do need to know about what a format will and won't support, for doing warn-or-save? And given that we have some support for "compatibility modes" (which are with applications, but still). > warn-on-incompatible-change seems to introduce a lot of open questions like > how "incompatible change" is defined, when we assume "editing" (with intent > to change the file in place) and when we assume "import" (with intent do > store in another format). When I think about this feature, the criterion for warning is: "If I were to save the document (File > Save) after the action I've just requested - would I get the warning-on-save?" ... and that's it. The first time after opening the document at which the answer to this question becomes "Yes" - that's when you'd warn. And if it doesn't become yes, then there's no reason to warn. I believe this addresses all three questions (and if it doesn't - please say so). Of course, LO might not be aware that a change is incompatible - but then it wouldn't warn-on-save anyway. That would be an orthogonal issue. > (an alternative pattern to warn-on-save is what some image editors do – > differentiate between "save" (native format) and "export" (andthing else)) I'm not actually suggesting we drop warn-on-save; although if this is accepted, the question might well come up.
(In reply to Heiko Tietze from comment #8) > Another example: You can direct format text as bold or via character style, > both are saved as <b> to HTML (and I would argue this is always DF). IOW, > you have a technical perspective on data and a user POV, depending on > expertise and workflow. > > > If you warn the first time about "styles are not stored with HTML" users > might not care but if it comes to another incompatibility they will for > sure. So you have to do it for every single attribute. Same argument in > comment 5. I believe this is a similar concern as the one jan d raised: What constitutes an "incompatible change"? Please see my reply to that in comment #10. > I doubt the use case of Benjamin loading an "extra format", something that > is not primarily suited for text processors or spreadsheet apps like html, > rtf, csv etc., expecting a different function set works the same way. I did not quite understand the end of this sentence. I will say that a 'Benjamin' user will likely not open plain text documents in LO Writer. But it's not inconceivable Benjamin would open a CSV for editing in Calc; or Markdown in Writer. And he may well do some formatting not supported by the file format. > Expert users probably not invest "hours of working" ending up in being > surprised on save. That is partially true. If we don't think of Expert as a binary - it is quite possible for a user to work on commented tracked change to a DOCX he got from a collaborator, and only save his work after, say, an hour or two. > More generally: Why do we always care about other applications? We should > proudly present our work and only secondarily consider other tools. User > running LibreOffice are supposed to work with ODF - period. First, this feature is not about _applications_, it is about file formats. It's true that some formats are associated with applications, like DOCX, PPTX etc. But: CSV, TSV, plain text, Markdown, HTML - those are not app-associated. Regardless - your point is a Red Herring. You see, this feature is only about the case of editing non-ODF formats. When a user is editing an ODF file, or creating a new file - this whole issue is irrelevant. This feature does not in any way encourage _more_ work with non-ODF formats (nor less) - it's just about what happens when users choose to edit them. (In reply to Telesto from comment #9) > I fully support this in principle. Would give more freedom, instead of > constant compromising functions and such on foreign formats. And well file > formats become probably less of an issue with cloud solutions. Same point as I was making to Heiko. ODFs are great - but this bug is about when you're editing other things. And some formats are just not that rich - nor should they be. Would you suggest people use ODS instead of CSV or TSV for unformatted tabular data? Or that Markdown is a useless format? Surely not.
(In reply to Heiko Tietze from comment #2) > We pondered over this in the ESC considering the warning on save. Would be > nice to learn what exactly is not compatible. But it requires every single > aspect to be listed somehow in a table, hard to imagine. => bug 115291
Note that this needs a never-ending track of what is supported, and what is not - both because the file format does not support it, and because we didn't yet implemented it; with every change in the code (fixing an interoperability bug; introducing a new feature); for a potentially unlimited number of file format (which are, basically, black box from the module's perspective: a file format is just a filter, which is pluggable, and provides means to import and export, and can come from extensions). The only potentially implementable approach is - checking when saving; and that would depend on the filter doing that job. We can introduce hooks allowing filters to report the issues, but not much more.
(In reply to Mike Kaganski from comment #13) > Note that this needs a never-ending track of what is supported, and what is > not - both because the file format does not support it, and because we > didn't yet implemented it; with every change in the code (fixing an > interoperability bug; introducing a new feature); for a potentially > unlimited number of file format (which are, basically, black box from the > module's perspective: a file format is just a filter, which is pluggable, > and provides means to import and export, and can come from extensions). This point is well-taken. The question is, can this "chasing after our own tail" be circumvented somehow. That is, when we actually export to a certain format, there is effectively some sort of filter deciding what gets massaged into output and what gets discarded. If that filtering is not implicit (e.g. in opaque code which gets XML and produces a stream of chars constituting a DOC or RTF or whatever), but rather explicit/formalized somehow (e.g. set of exported and discarded XML tags) - then that same filtering might be used to implement this feature. And if that's not possible - another option is a lightweight "dummy save" procedure which just invokes the export code without actually saving a file. And if that's not possible either - then maybe WONTFIX. But I feel you're a bit too quick to dismiss this. > The only potentially implementable approach is - checking when saving; and > that would depend on the filter doing that job. We can introduce hooks > allowing filters to report the issues, but not much more. So, I hope I may have suggested how we might be able to do more than just hooks in output filters.