https://bugs.documentfoundation.org/show_bug.cgi?id=151215
--- Comment #16 from Eyal Rozenberg <[email protected]> --- (In reply to Mike Kaganski from comment #14) > (In reply to Eyal Rozenberg from comment #12) > > * Choosing what happens to neutral characters (i.e. which language's font > > they adhere to) > > Disagree with some specific part of this wording. Specifically: I totally > agree that it would be useful to define a font used for "neutral" characters > ... but I believe that it should not be "bind them to font of language X", > but rather an own entry. I don't have a strong opinion on this, I (think I) am ok with your approach. > Additionally, in this case it looks like we have an > xor case: *either* we map all neutral characters to some font, *or* honor > the language of the text run to decide the font.Without the latter, we > would not be able to resolve bug 148257; but if we allow the latter, a > normal workflow on Windows (naturally marking every piece of text with > current system input language) would already apply a language, so neutral > characters would have to obey ... That's a good point; but - let's suppose that we keep track of the language the user is typing text in, and save that information in the document. That now creates 3 basic options for treating neutrals: 1. Honor what the document says explicitly about the language of the neutrals (using spans, or whatever's in the ODF spec). 2. Apply whatever standard heuristic we have for recognizing language runs in text without language indicated specifically, and assign neutrals according to the language they are determined to be in. 3. Render neutrals as some global override language. and perhaps a combination of these three, e.g. use (1.) when possible and (3.) as a fallback. Also (2.) may not actually be that useful in some cases, e.g. "שלום,hello" - is the comma English, or Hebrew? Or even: "Hello,bonjour" - comma in English or French? And finally, "grand,brand" - is this English all the way, or maybe French and English, or even French and Dutch, in which "brand" means fire? ... and then there's no way to make a decent call on which language to choose for the comma. > > * Understanding which additional languages would be covered "for free" by a > > font (e.g. if I want to occasionally use a French word with accents in my > > English text - can I?) > > I don't see how would that be reasonable part of e.g. Writer - we are not a > dedicated tool for font management. If at all, I believe that Special > Character dialog (which needs much of love anyway) could be used for > something like that. However, if you have an appealing UI mockup that makes > it natural in a place like the discussed configuration - why not. I was trying to describe a maximal set of potential functionality. We could decide this is too much. > > * Controlling overlaps between fonts beyond the perfectly neutral characters > > - what gets preferred? > > This needs some elaboration. Suppose you want font F1 for language L1 and font F2 for language L2 - but that L1 and L2 have some non-neutral glyphs _in common_ and other glyphs which aren't common. Like Arabic and Farsi I guess. Now, which font should we use for a single glyph in the intersection of L1 and L2? ... if it's something we're typing, I guess you could say "use the locale's language" - but what if you've entered it as a special character? Or if you've pasted plain text? Or if you've used a Unicode hex value to enter a character that's not in the language's set of glyphs? I realize I'm getting into corner cases here, but again, I've tried to capture the maximal set of potential functionality, and we could decide to ignore this, or force a default, or have another mechanism for handling it (like UI and an UNO command for setting the language explicitly, a-la-bug 148257). If we had that, the font selection dialog could do a little less and corrections could use the language forcing mechanism. Or not. -- You are receiving this mail because: You are the assignee for the bug.
