[Libreoffice-bugs] [Bug 153043] Writer should not declare CJK (RTL-CTL) fonts when CJK (resp. RTL-CTL) support disabled
https://bugs.documentfoundation.org/show_bug.cgi?id=153043 Eyal Rozenberg changed: What|Removed |Added Blocks||119352 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=119352 [Bug 119352] [META] Language issues -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153043] Writer should not declare CJK (RTL-CTL) fonts when CJK (resp. RTL-CTL) support disabled
https://bugs.documentfoundation.org/show_bug.cgi?id=153043 --- Comment #14 from Mike Kaganski --- (In reply to Eyal Rozenberg from comment #13) > Wait, is only Style 1 a predefined default or both of them? Grammar ambiguity > ... In my scenario, the three styles: Style 1, Style 2, and Style 3, were all pre-defined; e.g., they could be "Heading 1", "Body Text", and "Block Quotation". > Also, it seems you're assuming the default pre-defined styles are the same > on A and B's system. Why are you making this assumption? Grammar ambiguity ;) What specifically do you mean by "the same"? I assume that the styles are "the same" in the sense that they have the same name. But otherwise, I do not assume their same *formatting* - if they were "the same" formatting-wise, it would make it safe and would not create problems. (In reply to Eyal Rozenberg from comment #11) > 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). These words imply, that two people - starting *from scratch*, and wanting to *merge* - have conflicts in all *undefined* styles - i.e., they have the problem in styles they didn't use (but that implies, that these styles still existed in their "from scratch" document, which leads to the standard styles). -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153043] Writer should not declare CJK (RTL-CTL) fonts when CJK (resp. RTL-CTL) support disabled
https://bugs.documentfoundation.org/show_bug.cgi?id=153043 --- Comment #13 from Eyal Rozenberg --- (In reply to Mike Kaganski from comment #12) So, about templates: I think that people who collaborate should probably use a proper OTT template, which defines everything they expect to use or maybe simply everything, period, in a way that's stylistically consistent. And that means I am not that worried about collaborators who start writing from scratch having to then harmonize different style choices they each introduce during their work. > > 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) Wait, is only Style 1 a predefined default or both of them? Grammar ambiguity > without any other styles > in the ODF, and collaborator B has their from-scratch document (using > *pre-defined, default* Style 2 and Style 3) same question. Please clarify so that I can understand the rest of the scenario. Also, it seems you're assuming the default pre-defined styles are the same on A and B's system. Why are you making this assumption? -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153043] Writer should not declare CJK (RTL-CTL) fonts when CJK (resp. RTL-CTL) support disabled
https://bugs.documentfoundation.org/show_bug.cgi?id=153043 --- Comment #12 from Mike Kaganski --- (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.
[Libreoffice-bugs] [Bug 153043] Writer should not declare CJK (RTL-CTL) fonts when CJK (resp. RTL-CTL) support disabled
https://bugs.documentfoundation.org/show_bug.cgi?id=153043 Eyal Rozenberg changed: What|Removed |Added Summary|Writer should not declare |Writer should not declare |CJK (or RTL-CTL) fonts when |CJK (RTL-CTL) fonts when |if CJK (resp. RTL-CTL) |CJK (resp. RTL-CTL) support |support disabled|disabled --- Comment #11 from Eyal Rozenberg --- (In reply to Mike Kaganski from comment #10) Let me start with a meta-reply: Our deeper disagreement seems to be about whether or not an ODF document must fully define the styling of _all_ possible content, not just the content in the actual document; or whether unused styling can remain undefined. The argument for full-definition seems to be: FD1. If such a document is modified by different people, they are likely to define inconsistent styling (of those aspects not defined in the original document) My arguments for partial definition are: PD1. There is benefit in documents only containing anything the user was not aware they are inserting into the document. Whoever opens the document can't tell whether the author actually wanted any RTL-CTL content, for example, to be set in the font specified in styles.xml, or whether the app just inserted some default. PD2. This Allows for the creation of smaller documents, and particularly, shorter styles.xml file. This is most relevant for testcases and sample document. PD3. The aspects of styling which the user does not set explicitly and does not use (e.g. RTL-CTL font), and which would be set to some default, are likely to not match the specified styles well; thus, if/when they come into effect, the document would be poorly-styled, or otherwise - the effect would be the same as with no-styling, i.e. each user (among several potential collaborators) would set it to something different. In these cases there will have been no benefit in for PD4. The default choice of RTL-CTL font is likely to not cover many Unicode characters of various RTL-CTL languages. For those characters, even the specification of the font in styles.xml does not _really_ specify which font is used. And, in fact, LO today doesn't even have the capability of specifying fallbacks properly (*) - so if users were to add content in those languages, they would again each be using their own different fallback font. Now back to the bickering: > (In reply to Mike Kaganski from comment #8) > (In reply to Eyal Rozenberg from comment #9) > > It's not a mess, because none of them uses CJK. > > Don't you find that my words above explicitly say otherwise? You did say that, but I was talking about the scenario of CJK not being used. I assume you concede that while CJK is not used no mess is created, and proceed to the case you want to focus on, which is multiple collaborators who independently introduce CJK content without one disseminating an update to all the others. In that case, the "mess" is a conflict of styles: Say, one user who added CJK chose font family FooCJK, and another chose BarCJK. And this conflict will need to be resolved. But like I said in my last comment - that's no different from settling differences in edits to the text. 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). > 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? > and the template idea is exactly to *prevent* such a situation ;) We could have the same argument about templates. If a group of people don't use CJK, and want to work on some documents based on a template - why should that template define any CJK fonts? -- You are receiving this mail because: You are the assignee for the bug.
