https://bugs.documentfoundation.org/show_bug.cgi?id=153043
--- Comment #12 from Mike Kaganski <mikekagan...@hotmail.com> --- (In reply to Eyal Rozenberg from comment #11) > (In reply to Mike Kaganski from comment #10) > > Don't you find that the same can be said about work *without* a template > > (when people start creating their own document without any prior > > preparational work); > > I didn't mention templates anywhere... what does it matter if this scenario > happens with or without a template? You mentioned it from start - just the problem of loose terminology here. We never talked about the *proper* "template" in LibreOffice sense (e.g., ott); only about a *document* that one sends to another, and they start working on copies of that document - it's all about this original document used as "template" here. If you prefer, you may change the word (not *term*) "template" that I used here all along, with word "initial blank document shared among contributors to start their work". > In fact, I believe your approach sometime results in the need for more need > for style conflict resolution, because if two people write a document from > scratch, and then want to merge it - with your approach, they will need to > harmonize the differences in all undefined styles they had not even given > any though to (and may not even know about). No. "From scratch" case would not make it easier in even a slightest bit. Even if you imagine the case where collaborator A has their from-scratch document (using *pre-defined, default* Style 1 and Style 2) without any other styles in the ODF, and collaborator B has their from-scratch document (using *pre-defined, default* Style 2 and Style 3) without any other styles: * what you imagine is that copying data from collaborator B's document into collaborator A's document (on collaborator A's system) would only introduce possibly unexpected look of parts with Style 2, but not with Style 3; * what would happen instead, would be that opening collaborator A's document on collaborator A's system would still fill all the missing *pre-defined, default* styles, including Style 3; and that would match the collaborator A's system i.e. what would be saved in the ODT anyway; pasting data from collaborator B's document would still result in the conflict between the in-memory definition of Style 3 in target document with what is in the pasted data. Same in the opposite case (opening on collaborator B's system), or even worse on collaborator C's system, having their from-scratch new document, pasting data from both other collaborators' documents. So there is no real scenario where your proposal would create a *usability* improvement (or there was not provided one yet); the only actual upside is smaller XML size (not really resulting in noticeable change in ZIPped size; of course, FODT file size could change significantly for not too large documents). On the other hand, there is a real scenario, that benefits from the *status quo* usability-wise. I have shown it. So, we compare 0% usability improvement (and some % of XML size improvement) - i.e., your proposal - to some (non-0) % of usability improvement - i.e., to status quo. I'd say, that until we implement our discussed improvement into language handling in ODF, the Western/CTL/CJK problems (most of them) would not have any satisfactory solution. Having this triade is unfortunate. It works with the in-built magic of assigning a character one of these categories not based on what a user wants, but based on the character Unicode group; and that's awful. Anyone could suddenly arrive at using a character from the other Unicode group, say, by copy-pasting some emoticons (there are plenty of them using Japanese, Arabic, etc. characters). Not having control on what part of a style is applied to what run means the program has to be prepared. -- You are receiving this mail because: You are the assignee for the bug.
