When LibreOffice saves a document in ODF or Flat ODF format, it saves a large number of application configuration parameters, either in settings.xml in the case of a full-fledged ODF file, or within: <office:document ... etc. etc... > <office:settings> <config:config-item-set config:name="ooo:configuration-settings"> in the FODT hierarchy. Regardless of whether that's a good thing to do by default - users may not be interested in sharing their app configuration with others; or they might want to limit the content saved in the document to _just_ what they intended to put in the document, e.g. content and styles. Typically, a user would not know - unless they inspected the ODF/Flat ODF's XML, that these configuration settings are saved at all. I therefore propose: 1. An easily-discoverable toggle for saving configuration data in files, by default (either just ODT/Flat ODT or for all formats, where the semantics might vary by format). 2. Placing a toggle on the Save... / Save As... dialogs controlling whether such data would be included in the current Save operation. This would be similar to the "Save with Password" and other toggles already present in the Save... / Save As... dialog. Note that this also has some benefits w.r.t. QA and development, in that files would be smaller, diff's between files would be smaller, and it would not be necessary to verify that differences in behavior are not the result of app configuration changes. (Although to be fair, that effect can also be achieved by editing the files saved.)
No. The data saved in (F)ODT is the set that makes the fixe self-contained, and independent of possible future changes of the app defaults. Without this information, we will be limited in what changes we are allowed to do, without breaking others' documents. Any manual cleanup is always a thing that a person does, taking all blame on themselves. The program must not do that.
(In reply to Mike Kaganski from comment #1) First, none of what you've said is an argument against the _option_ of saving files without app configuration settings. Even supposing I bought the claim that the configuration settings are necessary to "make the file self-contained" - the user may not be interested in that. Remember that many file formats don't even support adding LO configuration settings; and we can very well use them for saving. But - that claim is not valid, in two ways: 1. many/most properties have no effect on the rendering of the document: PrinterSetup, RedlineProtectionKey, Rsid, UpdateFromTemplate, etc. 2. Even the app config properties which may affect the rendering of some documents, may not affect the current one. Example: 'DropCapPunctuation' ; if my document doesn't use drop caps, that won't come into play. 3. The configuration options which do affect document rendering do so beyond what the ODF spec itself specifies. That is certainly a legitimate thing to do, but the ODF has neglected to specify some of that for a reason. The document would still be legitimately rendered (albeit not identically rendered) by any properly-ODF-supporting app. > Any manual cleanup is always a thing that a person does, taking all blame on > themselves. The program must not do that. That's not generally true. For example, we can control whether or LO saves RSID tags.
(In reply to Eyal Rozenberg from comment #2) > (In reply to Mike Kaganski from comment #1) > > First, none of what you've said is an argument against the _option_ of > saving files without app configuration settings. It is. Providing such an option, we provide an option to create unstable documents. > Even supposing I bought the > claim that the configuration settings are necessary to "make the file > self-contained" - the user may not be interested in that. Remember that many > file formats don't even support adding LO configuration settings; and we can > very well use them for saving. These file formats are self-contained in their own right. E.g., a TXT contains only a text stream, and has no idea about pages and footnotes. But all ODF formats do have all the concepts that you suggest to eliminate; and that means, that the documents that inherently rely on some data, miss that data. > But - that claim is not valid, in two ways: > > 1. many/most properties have no effect on the rendering of the document: > PrinterSetup, RedlineProtectionKey, Rsid, UpdateFromTemplate, etc. Your argument is not valid. What I wrote is true; but there *may* be a specific case that may need specific treatment. We already provide options for some things - like not storing personal info; printer info; rsid (which you mention below). If you think that *some specific thing* needs a toggle, it's a subject for a case-by-case ticket. Your request is WONTFIX of INVALID; but you again started an edit war. I don't resolve it myself now, but I suggest you to consider that yourself, and create separate tickets; and if needed, a META ticket, which could potentially be a base for "create a dedicated page with an option to disable *those specific items* all at once".
(In reply to Mike Kaganski from comment #3) > It is. Providing such an option, we provide an option to create unstable > documents. You mean, like plain markdown (bug 160734), HTML, RTF, and other formats we support saving to? > These file formats are self-contained in their own right. E.g., a TXT > contains only a text stream, and has no idea about pages and footnotes. And if I save to a text file, that means I don't want to retain information about pages and footnotes. > But > all ODF formats do have all the concepts that you suggest to eliminate; and > that means, that the documents that inherently rely on some data, miss that > data. On the contrary. Much of the time, it is arbitrary data that LibreOffice forces into files, which the users did not want nor intend to place in it. Additionally, if this is information that documents "inherently rely on", it would not be stored as application settings, but as aspects of the content or the styles. Not to mention the fact, that application configuration is, by definition, application-specific. Open your ODTs in another application, and they would often/typically be ignored. > Your request is WONTFIX of INVALID; but you again started an edit war. It doesn't work that way. My request is UNCONFIRMED; you mistakenly marked it as WONTFIX, without justifying such an action. And - an edit is not an edit war. > I > don't resolve it myself now, but I suggest you to consider that yourself, > and create separate tickets; and if needed, a META ticket, which could > potentially be a base for "create a dedicated page with an option to disable > *those specific items* all at once". I am not focusing on individual settings, this bug requests the option of not saving application settings at all. I have, however, pre-split the matter of application settings and view settings.
(In reply to Eyal Rozenberg from comment #4) > (In reply to Mike Kaganski from comment #3) > > It is. Providing such an option, we provide an option to create unstable > > documents. > > You mean, like plain markdown (bug 160734), HTML, RTF, and other formats we > support saving to? No, I mean, like ODF, which is not plain markdown, HTML, RTF, and other formats that may have *their own* specifications and limitations. ODF has specific feature set. If you want, you may create a new file format, and make it "have no promise of being stable". Saving to that, you could strip out whatever you like. Again: your personal deep knowledge and reasonable expectation from this stripped out variant is NOT a reason to provoke users who have no idea what the inner differences are, to say "wow it's three times slimmer, and work the same - let me use this, and suggest this new shiny setting in all forums I can reach, and make myself and countless of others suffer tomorrow, when the program changes its defaults". There is ~0 upside in your proposal. But it is a HUGE danger. It simply must not be done.
(In reply to Eyal Rozenberg from comment #4) > > But > > all ODF formats do have all the concepts that you suggest to eliminate; and > > that means, that the documents that inherently rely on some data, miss that > > data. > > On the contrary. Much of the time, it is arbitrary data that LibreOffice > forces into files, which the users did not want nor intend to place in it. > > Additionally, if this is information that documents "inherently rely on", it > would not be stored as application settings, but as aspects of the content > or the styles. Not to mention the fact, that application configuration is, > by definition, application-specific. Open your ODTs in another application, > and they would often/typically be ignored. If you look at the settings you are talking about, you may notice things like compatibility settings. These are, indeed, application-specific; like e.g. Word would not use them. And LibreOffice itself, when opening files created in newer LO versions, would not know how to use them. But these options, nevertheless, control the appearance of the documents. It allows to keep documents converted from MS Word formats in a shape that was (close to) in Word. Clear them - and your document is broken. You may argue as much as needed, that these must be in styles. Shrug; that is not a topic of this report.
(In reply to Eyal Rozenberg from comment #4) > Additionally, if this is information that documents "inherently rely on", it > would not be stored as application settings, but as aspects of the content > or the styles. Not to mention the fact, that application configuration is, > by definition, application-specific. Open your ODTs in another application, > and they would often/typically be ignored. https://docs.oasis-open.org/office/OpenDocument/v1.4/OpenDocument-v1.4-part4-formula.html#HostDefinedBehaviors The ODF standard itself makes provisions for app-defined behavior. This is part of the standard.
(In reply to Mike Kaganski from comment #7) > The ODF standard itself makes provisions for app-defined behavior. This is > part of the standard. Exactly. App-defined - which is auxiliary and unessential. Perhaps it would make sense to introduce additional constraints or properties into non-app-defined aspects of ODFs, so that app-defined fields would not be necessary to fully specify the rendering of a document; and I would happily support such issue reports with OASIS. But the user many not want to save any app-defined, app-specific information - just the universally recognized information. And it is reasonable for that option to be available to them.
(In reply to Eyal Rozenberg from comment #8) Oh wow. Please read and think before replying. "Use or not use regular expressions in formulas" is such an app-defined behavior. And it simply changes what tour ODS calculates. The user who does not want to store what our ODF needs, is welcome to save as TXT. They may create tools like https://git.libreoffice.org/core/+/refs/heads/master/bin/flat-odf-cleanup.py. They are welcome to do it manually. But there must be nothing in the program itself like what you suggest here.
(In reply to Mike Kaganski from comment #9) > The user who does not want to store what our ODF needs, is welcome to save > as TXT. The words "our ODF" is key in that sentence. It is not reasonable for force users to save only "our" kind of ODFs. They may well want to say a generic, or universal, ODF. > They may create tools like > https://git.libreoffice.org/core/+/refs/heads/master/bin/flat-odf-cleanup.py. > They are welcome to do it manually. Many things can be done manually. People can insert custom shapes into ODFs manually, or perform complex search-and-replace operations manually etc. But - they should not have to. The option to save an app-inspecific ODF is a reasonable expectation from a GUI ODF editor.
(In reply to Mike Kaganski from comment #9) > (In reply to Eyal Rozenberg from comment #8) > > Oh wow. Please read and think before replying. "Use or not use regular > expressions in formulas" is such an app-defined behavior. And it simply > changes what tour ODS calculates. That example is not suitable. That information is stored in <table:calculation-settings> in the content.xml.
(In reply to Regina Henschel from comment #11) You are correct. Thanks. One thing I wanted to add. (In reply to Eyal Rozenberg from comment #4) > On the contrary. Much of the time, it is arbitrary data that LibreOffice > forces into files, which the users did not want nor intend to place in it. > ... > I am not focusing on individual settings, this bug requests the option of > not saving application settings at all. > > I have, however, pre-split the matter of application settings and view > settings. Note that the wording "application settings" might indicate misunderstanding (or not), caused by our *document-local* settings UI in Options. Note that files do not store *application* settings, but only *document* settings.
(In reply to Mike Kaganski from comment #12) > Note that the wording "application settings" might indicate misunderstanding > (or not), caused by our *document-local* settings UI in Options. Note that > files do not store *application* settings, but only *document* settings. Formally, they're application configuration settings. Quoting ODF 1.4: > 3.10.1 General > > The <office:settings> element contains one or more <config:config-item-set> > elements, each of which represents a set of application settings. so, it's true that they could be document-specific settings, but that is not necessarily the case. In practice, some settings may well affect document rendering, and some settings are document-specific, but can't be considered part of the document itself; rather, they are persisted application settings specific to the documents, e.g. whether to print various elements or not (graphics, hidden text, empty pages); or an RSID hash.
Reducing severity to minor, considering the manual workaround Mike points out, and the fact that this does not hamper usability of the (Flat/)ODT.
(In reply to Eyal Rozenberg from comment #13) > so, it's true that they could be document-specific settings, but that is not > necessarily the case. This is necessarily the case, in the sense that they all define settings that may be different between two different documents, and these two documents will *therefore* cause application behave differently *in a document-specific* way; and in the sense that this is the case *in practice* (here: it would be possible to store something non-specific to documents there, e.g., copy the whole registrymodifications; but we only put there things that definitely are per-document settings). I see other ways to treat "document-specific", the same as ODF's "application settings" is different from our "application vs. document settings".
(In reply to Eyal Rozenberg from comment #4) > Much of the time, it is arbitrary data that LibreOffice forces into files... Stopped here as this is clearly not UX-related. There are plenty of privacy options, if that is the concern. Easy-to-discover contradicts with rarely used features.
(In reply to Heiko Tietze from comment #16) > Stopped here as this is clearly not UX-related. The question of how to make this option accessible to the user is a UI/UX question.