https://bugs.documentfoundation.org/show_bug.cgi?id=163789
Eyal Rozenberg <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|NOTABUG |--- --- Comment #5 from Eyal Rozenberg <[email protected]> --- (In reply to Mike Kaganski from comment #4) > And what is the problem in these 40? In fact, these are one of the few (two > more down the road) that really could be minimized - because their set is > basically fixed, to simplify the code; but how do they harm *in reality*? They're redundant and gratuitous, at least to some extent. For example: xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" when my document doesn't used 3-dimensional shapes. And many more. > Note that I ask this, and - possibly - one of a *couple* people who really > *does* clean up FODF files when preparing minimized bug docs and unit tests; > so - I really could benefit from that - but it would never outweigh the > complexity of the code. Let's ignore for the moment the prospect of skipping namespaces which can be inferred using the office namespace, ODF version, MIME type and some ODF defaults, and just focus on unused namespaces. Where's the great complexity in using the information which I'm sure we already collect, regarding whether or not a document has 3D drawings, or math formulae, or form controls etc? If we have any, we include the namespace in the office:document element attributes, and if we don't - then we don't. > And they must be: these settings are what defines the ... settings; > including compatibility, view, etc. Some of them are controllable using > settings (and may be not exported). "Must"? No, it's just a choice, as long as they don't affect the content. For example, the view information. That might even be a privacy concern. Suppose I save a contract; I don't want people to determine which part of it I was last looking at; and at least I want to be asked about this. Or - take printing-related preferences; who said I want other people reading or editing my document to have my printing preferences? ... generally, and particularly my printer name?! > Again: this is a boilerplate for simplicity. Could be stripped, at the > expense of code complexity. Doesn't hurt. Let users have at least a toggle somewhere to not add boilerplate to their files. > No - please stop this useless argument. As long as the font is in a style, > it is used. Period. 1. There's duplication fonts, resulting in dummies. 2. But the file is full of styles which _aren't_ used. > > 6. ~105-line <styles> element, containing 17 distinct styles, including a > > graphics style, outline numbering, footnote and endnote configuration, a > > color scheme that's unused, > > ... And styles **are** the document content. No matter what you think. 1. I didn't create nor use any of these styles. 2. Some of them are latent styles which aren't even accessible in the UI, e.g.: <text:p text:style-name="P1">hello world</text:p> and style P1, which really doesn't exist as far as the user is concerned, is: <style:style style:name="P1" style:family="paragraph" style:parent-style-name="Standard"> and style "Standard", which also doesn't exist, is: <style:style style:name="Standard" style:family="paragraph" style:class="text"/> ... and it's only then that we get to the Default Paragraph Style. Now that - we definitely should have in the document. BUt why the other stuff? > No. A useful argument :-) > > 3. The user may not intend for all of this information to be embedded into > > the document. > > Then they shouldn't use WYSIWYG tools. LibreOffice is really not WYSIWYG. In fact, you're making my argument for me, since if WYSIWYG, I should at least not get stuff I don't and can't see. Moreover - there's no reason WYSIWYG tools should not be able to produce terse and more easily-readable output. Especially for textual formats like flat ODT. > which has much more interesting > things to do, than playing "let's make it eye-pleasing internal code to > please one geek's eye" games. Terse files with only relevant content also makes parsing and automated processing easier. Also, "more interesting things to do" just means low priority/severity. > It's not even "if someone volunteers to do, > then please" - for the most part, it is simply no-go. Remove a style, and > you break someone's workflow. Remove a setting, and you break the document > behavior / look. 1. Fortunately, that's not the case for much of what can be removed. 2. We can offer an option for more parsimonious saving/export, so that nobody's theoretical workflows are broken. > I simply close this useless issue. I know that you like to reopen, and try > to force your PoV no matter what. To close a bug against the reporter's opinion, you need to make a convincing argument for why it merits closure. If you've not convinced the reporter, and they are not some troll/spammer, then you should establish there is wider agreement with your position. For design bugs, this is "adjudicated", to some extent, by discussions in design meetings. For import/export issues I don't know what the custom is, but "A developer has a different perspective on the matter" cannot be sufficient when the bug report is about outward-facing behavior. -- You are receiving this mail because: You are the assignee for the bug.
