[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 --- Comment #18 from Eyal Rozenberg --- (In reply to Mike Kaganski from comment #16) I now understand your objection. However - it works both ways... Let's ignore for a moment the relevation in my previous comment and consider the current behavior on Linux. Suppose you've typed some English characters and have now changed the layout to RTL. Does the UI now tell you what's going to happen on keypress? It does not. Given everything you might now type in - it is more likely you will type an RTL character. And even if you typed a space, it is now _extremely_ likely that your next characters would be RTL. So that while I agree that the space would break the logic I suggest, I believe it will still be less broken than it is now. And after bug 151290 is resolved, the the logic will be consistent w.r.t. spaces too. (Of course, when that happens, we will have the interesting dilemma of what happens when you type in strongly-Western-group character from an RTL-CTL layout: Which font, and which language, to choose for those. But that is a concern for a later time.) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 --- Comment #17 from Eyal Rozenberg --- I have interesting news... it turns out, that on Windows - the behavior I've asked for is _already_ our behavior right now; while on Linux it isn't (which is why I filed the bug). Try it! 1. Enable full RTL/CTL language group support. 2. Set your keyboard layout to some RTLish layout (e.g. Arabic or Hebrew). 3. Start a new Writer document. 4. Make your paragraph to RTL. 5. Set your paragraph's style (it would be the Default Paragraph Style) to have different typefaces for Western and RTL/CTL, different sizes, and different variants within the typeface, e.g. one of them bold, the other not bold. 6. Type a few RTL characters (e.g. مرحبًا or שלום) 7. Switch your keyboard layout to an LTR layout (e.g. English or German) 8. Switch your keyboard layout back to the RTLish layout Behavior on Windows: With steps 7 and 8, the formatting toolbar controls for typeface, size and bold state change, then change back. Behavior on Linux: With steps 7 and 8, the formatting toolbar controls don't change. Seen with LO 25.2.5 Now I wonder whether the Linux behavior is a bug, or just an inability to determine the keyboard layout... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 --- Comment #16 from Mike Kaganski --- (In reply to Eyal Rozenberg from comment #14) > But using the keyboard layout is still a good heuristic: If I change the > keyboard layout from ru_RU to ar_SA - Don't you agree it's better to show > the user what font they would get if they now type in an RTL-CTL character, > rather than a Western one? I would only agree, *if* what the control show would be exactly what would happen on key press. I.e., when even the space would be rendered using the font shown in the control. If the control shows a font with a space having width X, but pressing the space gives width Y from another font, it is already bad. I consider this issue *only* solvable after another your bug, about assigning language groups to punctuation and friends. Maybe I just didn't notice, and that's already solved? If so, then I likely must drop my concern. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 Heiko Tietze changed: What|Removed |Added Severity|normal |enhancement CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | --- Comment #15 from Heiko Tietze --- (In reply to Eyal Rozenberg from comment #13) > Was that a clear explanation? If not, I can make a video. Yes, we want to get rid of this unholy trinity. Isn't this covered in one of the gazillion other bugs? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 --- Comment #14 from Eyal Rozenberg --- (In reply to Mike Kaganski from comment #12) > I feel that we already > discussed, that no "layout" by itself defines "next character language > (group)". If the system provides a real "input language" (Win / Qt), *that* > could be used (but we have some problems with that, too: space won't get > that language still). You're right, in that a keyboard layout may contain characters associated with different language groups, and weak characters. But using the keyboard layout is still a good heuristic: If I change the keyboard layout from ru_RU to ar_SA - Don't you agree it's better to show the user what font they would get if they now type in an RTL-CTL character, rather than a Western one? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 --- Comment #13 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #11) > Many +1 so I stay away to -1'ing. In general we continue the previous > character attributes whether it's font weight or language. Not quite. Suppose one types a Western-language-group, say 'a', then an RTL-CTL character, say 'ש'. Even though both have the same style, the _aspect_ of the style which applies visibly will now be the RTL-CTL group's aspect, i.e. the RTL-CTL typeface, font size, font weight etc - which are not the same as for the Western character. > But I don't > understand "settings in the formatting toolbar controls", neither the > summary with "no text selected". When you look at the LibreOffice (module) window and its toolbar, you (typically) see controls for: typeface, font size, Bold Y/N, Italic Y/N and a few others. These show values for one of the three language groups of some style. If no text is selected, the style is that of the character before the cursor (or the paragraph style, or drawing object style etc.) . But that still does not determine which of the language groups has its properties displayed. This bug suggesting changing the logic regarding which language group is reflected in the controls I mentioned. Was that a clear explanation? If not, I can make a video. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 --- Comment #12 from Mike Kaganski --- Typing space will not change the "language group". I feel that we already discussed, that no "layout" by itself defines "next character language (group)". If the system provides a real "input language" (Win / Qt), *that* could be used (but we have some problems with that, too: space won't get that language still). I disagree with the idea. Too much guessing. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 Heiko Tietze changed: What|Removed |Added CC||[email protected] --- Comment #11 from Heiko Tietze --- Many +1 so I stay away to -1'ing. In general we continue the previous character attributes whether it's font weight or language. Sounds correct to have the language of the previous character at the current. But I don't understand "settings in the formatting toolbar controls", neither the summary with "no text selected". -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 --- Comment #10 from V Stuart Foote --- (In reply to Jonathan Clark from comment #8) > (In reply to Eyal Rozenberg from comment #9) > OK, with understanding that it would apply to the GUI only and not affect the document model until user actually enters *additional* text in the newly identified language/language group--sure. No continuing objection over the scope or potential impact on document. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 --- Comment #9 from Eyal Rozenberg --- (In reply to V Stuart Foote from comment #7) > Issue would be with how it would be laid down in the text run. With DF or > Text style applied to the text entered mid span, you'd end up with a text > run of mixed style assignments in the ODF, potentially misidentified > language, with RSID tags to boot. All of that is actually independent of this bug. I'm only talking about what the Formatting toolbar shows, I'm not suggesting any other change in behavior. > To keep the chaos down (and keep the ODF/OOXML meaningful) No change suggested in what ends up in the ODF/OOXML... The "deeper" issues is discussed in bug 151290, and other bugs blocking bug 162336; this is purely about the UI (and relative to the current state of affairs regarding representation of language in the document model). I hope this clears up what I'm suggesting here. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 --- Comment #8 from Jonathan Clark --- +1 for sure. Tracking the user's intended input language among script types would also let us fix some other long-standing usability snarls, like bug 74735. (In reply to V Stuart Foote from comment #1) > Assumes there is a consistent method to query system for > keyboard in use, and can be implemented cross platform. Sadly, there isn't one. However, I think we shouldn't let that stop us from providing the best experience we can on platforms where this is possible. It would be good to let users control this manually too, which might be a good enough solution for those other platforms. (In reply to V Stuart Foote from comment #7) > To keep the chaos down (and keep the ODF/OOXML meaningful), it would be > reasonable to limit the keyboard/IME has changed response to apply at ICU > lib word bounds for current edit cursor, or to word/sentence ends when a > bounding selection of words has been made. > > Hard to justify the mess that would result doing it mid-word. The way I imagine this feature working is, we would track the current input language for GUI purposes separately from the document model. Any document change would be entirely user-initiated. The user would need to switch language and then type text before there is any DF, for instance. Switching to a different input source should affect the GUI, but it should not affect the document until writing happens. If that's the way this feature works, I don't think it would be a problem if users can change their language and start typing wherever they want. Someone might want to click in the middle of a word and start typing Arabic. In my opinion, that's their business, not ours. ICU is a lovely library, but it's not an absolute authority on how language ought to be used - let alone how documents ought to be edited. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 --- Comment #7 from V Stuart Foote --- (In reply to Eyal Rozenberg from comment #6) > > And probably don't want a language change on active keyboard to assert > > against entire paragraphs, as that would make it impossible to work polyglot > > for a single paragraph. > > assert... ? > > Can you describe the scenarios which you find problematic with my suggestion? > > More specifically - suppose I have a sequence of characters which are > strongly RTL-CTL. Now, in the middle of that sequence, I change the keyboard > layout to French. My ask here is to have the formatting toolbar show me the > French typeface, font size, etc. Do you think this is problematic? *in the middle of that sequence* Issue would be with how it would be laid down in the text run. With DF or Text style applied to the text entered mid span, you'd end up with a text run of mixed style assignments in the ODF, potentially misidentified language, with RSID tags to boot. To keep the chaos down (and keep the ODF/OOXML meaningful), it would be reasonable to limit the keyboard/IME has changed response to apply at ICU lib word bounds for current edit cursor, or to word/sentence ends when a bounding selection of words has been made. Hard to justify the mess that would result doing it mid-word. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 --- Comment #6 from Eyal Rozenberg --- (In reply to V Stuart Foote from comment #3) > But my expectation would be that if something is implemented, rather than > the edit cursor as now, a change in keyboard needs to have a > scope --mid-word/span would not be helpful. Why not? Why would it matter? If we're choosing the language group by what's about to be typed rather than what's already typed? Also - would we not want the logic for choosing what to show to be relatively simple with a minimum number of cases? > And probably don't want a language change on active keyboard to assert > against entire paragraphs, as that would make it impossible to work polyglot > for a single paragraph. assert... ? Can you describe the scenarios which you find problematic with my suggestion? More specifically - suppose I have a sequence of characters which are strongly RTL-CTL. Now, in the middle of that sequence, I change the keyboard layout to French. My ask here is to have the formatting toolbar show me the French typeface, font size, etc. Do you think this is problematic? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 --- Comment #5 from V Stuart Foote --- (In reply to Volga from comment #4) > > Should work at ICU word bounds, or assigned language of text run/sentence. > > So what about assigning style:script-type property? That seemed to be the mechanism this keyboard/IME "awareness" seeks to influence. Current paragraph style/or by selection assignment of character DF is not sufficiently granular and can be cumbersome. Consuming os/DE report keyboard language or locale of an IME in use would give more granularity to control language, so at the word bound would be useful. But more so for full sentences identifying the authors intent/locale and tagging spans/configuring UI to follow the keyboard language/IME. That seems reasonable and supplements style based Paragraph assignment to locale. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 --- Comment #4 from Volga --- > Should work at ICU word bounds, or assigned language of text run/sentence. So what about assigning style:script-type property? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 --- Comment #3 from V Stuart Foote --- Asserting a language appropriate to the current active keyboard layout would be a good enhancement. But my expectation would be that if something is implemented, rather than the edit cursor as now, a change in keyboard needs to have a scope--mid-word/span would not be helpful. So we could make a change at ICU word bounds for current text run, or for the entire current text run/sentence if word bounds are too granular. And probably don't want a language change on active keyboard to assert against entire paragraphs, as that would make it impossible to work polyglot for a single paragraph. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 --- Comment #2 from Eyal Rozenberg --- > Should work at ICU word bounds, or assigned language of text run/sentence. Sorry for not quite catching it, but - _what_ should work at ICU word bounds etc? The "consistent method"? My requested behavior? Something else? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 V Stuart Foote changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=16 ||6012 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 V Stuart Foote changed: What|Removed |Added CC||[email protected], ||[email protected] See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=66 ||791 --- Comment #1 from V Stuart Foote --- +1 reasonable. Assumes there is a consistent method to query system for keyboard in use, and can be implemented cross platform. Should work at ICU word bounds, or assigned language of text run/sentence. See also work for bug 66791 and dupes. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 Eyal Rozenberg changed: What|Removed |Added Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 Eyal Rozenberg changed: What|Removed |Added Blocks|83066 | Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=83066 [Bug 83066] [META] CJK (Chinese, Japanese, Korean, and Vietnamese) language issues -- You are receiving this mail because: You are the assignee for the bug.
[Bug 167484] When no text is selected, font controls should reflect the chosen keyboard layout
https://bugs.documentfoundation.org/show_bug.cgi?id=167484 Eyal Rozenberg changed: What|Removed |Added Blocks||162336 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=162336 [Bug 162336] [META] Issues relating to the Western/Asian/RTL-CTL trichotomy of language groups -- You are receiving this mail because: You are the assignee for the bug.
