Apache OpenOffice (AOO) Bugzilla – Issue 77682
Impress/Draw: display of incorrect font
Last modified: 2013-08-07 15:13:10 UTC
This one is a follow-up of issue 72349. In CWS tl37 issue 72349 (the EditEngine's detection of the script-type) was fixed. This resulted in Writer draw objects showing the correct font. However the same did not happen in Draw/Impress and Calc. The reason for this is that sd in drtxtob.cxx in function TextObjectBar::GetAttrState has code that overrides the detected script type with the one used for the keyboard input language when there is no selection. It looks like this : if(pOLV && !pOLV->GetSelection().HasRange()) : { : if( mpViewShell && mpViewShell->GetViewShell() && mpViewShell->GetViewShell()->GetWindow() ) : { : LanguageType nInputLang = mpViewShell->GetViewShell()->GetWindow()->GetInputLanguage(); : if(nInputLang != LANGUAGE_DONTKNOW && nInputLang != LANGUAGE_SYSTEM) : nScriptType = SvtLanguageOptions::GetScriptTypeOfLanguage( nInputLang ); : } : } This code was probably introduced with the feature to make use of the keyboard language for Asian languages (see issue 42732). Since the current implementation of this feature prevents issue 72349 from completely being fixed we need either to drop this issue or change the implementation of the feature. For example in Writer text boxes the keyboard langauge is not applied immediately but only if new text is entered. This is done via a post-key event. Thus it needs to be discussed what should be done here. Closing the mentioned issues or changing the implementation. NOTE: If the choice is to change the implementation please be aware that Calc has similar code which then needs to be changed accordingly as well. In Calc the code is located in editsh.cxx in the function ScEditShell::GetAttrState (about line 956)
Adding CMC and NN...
Created attachment 45319 [details] Adding bugdoc from original issue 72349
To view the problem you need to have the fix to the original issue 72349 from CWS tl37 available. Then you can just open the bugdoc and select the Japanese character (the second one) and view the font displayed. If you now place the cursor in between the second and third character (while your keyboard language is e.g. DE or EN) that very same font from before should be displayed but is not.
One other minor question that comes to mind is: AFAIK the keyboard language should currently only be applied for non-western script types. (Should not be a real problem though since according to issue 1035 it should be applied for western text as well. At least for the Writer this is planned to happen soon.)
retargeting
I'm not very happy fixing issues I don't understand. And I'm also not happy fixing issues that just removes features we thought were ok when we added them. So I need a user experience decision what to do with this task.
Retargeting.
FL->TL: Please take over. I think I got this one in error (tl/fl).
Reassign to TL.
TL->FL: Nope. This one is for you! I submitted the issue and CL wants you to clarify things (what to do) especially since there is a conflict.
FL->TL: But were is the UX part in this issue?
Not that easy to define. If I place the cursor in a text, I would expect to see all attributes valid on that cusor position. If I would change the input language then, I would expect the language change to this keyboard language too. If I do not enter any text at that position, I would expect to lose the language if I start traveling around. Then I would be able to see all attributes set at the cursor position. If I start entering text I would expect that the current input language is set and used. But this has the disatvantage that I need to set the language correctly to add any text to a already present text part, because then the text attributes would not be extended anymore. This issue needs more discussion -> retargeted to 3.1.
Adjust target.