Issue 77682 - Impress/Draw: display of incorrect font
Summary: Impress/Draw: display of incorrect font
Alias: None
Product: Calc
Classification: Application
Component: code (show other issues)
Version: 680m212
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2007-05-22 15:36 UTC by thomas.lange
Modified: 2013-08-07 15:13 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Adding bugdoc from original issue 72349 (9.71 KB, application/octet-stream)
2007-05-22 15:37 UTC, thomas.lange
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description thomas.lange 2007-05-22 15:36:12 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 =
:            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)
Comment 1 thomas.lange 2007-05-22 15:37:03 UTC
Adding CMC and NN...
Comment 2 thomas.lange 2007-05-22 15:37:59 UTC
Created attachment 45319 [details]
Adding bugdoc from original issue 72349
Comment 3 thomas.lange 2007-05-22 15:42:58 UTC
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.
Comment 4 thomas.lange 2007-05-22 15:46:55 UTC
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.)
Comment 5 clippka 2007-07-12 08:32:04 UTC
Comment 6 clippka 2007-11-12 13:46:35 UTC
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.
Comment 7 frank.loehmann 2008-02-07 08:32:23 UTC
Comment 8 frank.loehmann 2008-06-02 13:35:55 UTC
FL->TL: Please take over. I think I got this one in error (tl/fl).
Comment 9 frank.loehmann 2008-06-02 13:36:34 UTC
Reassign to TL.
Comment 10 thomas.lange 2008-06-02 14:23:51 UTC
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.
Comment 11 frank.loehmann 2008-06-02 14:29:55 UTC
FL->TL: But were is the UX part in this issue?
Comment 12 frank.loehmann 2008-06-02 15:55:17 UTC
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.
Comment 13 frank.loehmann 2009-04-16 11:55:40 UTC
Adjust target.