Issue 72349

Summary: editengine: detection of script type uses incorrect range
Product: Draw Reporter: caolanm
Component: codeAssignee: stefan.baltzer
Status: CLOSED FIXED QA Contact: issues@graphics <issues>
Severity: Trivial    
Priority: P3 CC: issues
Version: OOo 2.1   
Target Milestone: OOo 2.3   
Hardware: All   
OS: Linux, all   
Issue Type: PATCH Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 78017    
Attachments:
Description Flags
demo document
none
patch to fix
none
document for testing
none
patch none

Description caolanm 2006-12-07 09:58:42 UTC
The following attached .odp has three characters in a drawing box.

i.e. <western><cjk><western> 

When you select just the first char the western font is displayed in the font
drop down, when you select the 2nd char (on it's own) then no font is displayed,
and the same for the 3rd character.

With the following patch in place the correct font is shown on selecting each
character individually. Looks to me that the test for seeing if a range falls
inside a script range is wrong
Comment 1 caolanm 2006-12-07 09:59:14 UTC
Created attachment 41192 [details]
demo document
Comment 2 caolanm 2006-12-07 09:59:37 UTC
Created attachment 41193 [details]
patch to fix
Comment 3 wolframgarten 2006-12-07 10:16:24 UTC
Reassigned. Please handle.
Comment 4 clippka 2007-01-02 10:15:52 UTC
cl->tl: please evaluate and integrate if this patch is ok
Comment 5 thomas.lange 2007-01-08 15:19:32 UTC
.
Comment 6 thomas.lange 2007-02-01 10:08:20 UTC
The patch works for selected characters but not if one simply travels with the
cursor from char to char.

The following code works well with both cases:

:    for ( USHORT n = 0; n < rTypes.Count(); n++ )
:    {
-/+     if (rTypes[n].nStartPos <= nS  &&  nE <= rTypes[n].nEndPos)
:        {
:            if ( rTypes[n].nScriptType != i18n::ScriptType::WEAK )
:            {
:                nScriptType |= GetItemScriptType ( rTypes[n].nScriptType );
:            }
:            else
:            {
:                if ( !nScriptType && n )
:                {
:                    // #93548# When starting with WEAK, use prev ScriptType...
:                    nScriptType = rTypes[n-1].nScriptType;
:                }
:            }
+            break;
:        }
:    }
Comment 7 thomas.lange 2007-02-01 10:10:56 UTC
Fixed in CWS tl37.

Files changed:
- svx/source/editeng/impedit2.cxx
Comment 8 thomas.lange 2007-04-24 08:14:24 UTC
.
Comment 9 thomas.lange 2007-05-22 14:42:58 UTC
The detection of the scripttype is fixed. 
For example copy the characters from the presentation sample document into a
Writer text box. 

It still does not work as expected in Draw/Impress and Calc though!
This is because sd and sc choose to overwrite that scriptype with the one from
the keyboard input language. Which should not happen. Since I do not want to
mess with the implementation of the use-keyboard-language feature I'm going to
write separate issues to sd and sc. 
Comment 10 thomas.lange 2007-05-22 15:51:41 UTC
I submitted a follow-up for the remaining problem in Draw/Impress and Calc (see
issue 77682).
Comment 11 caolanm 2007-05-31 17:01:05 UTC
Created attachment 45557 [details]
document for testing
Comment 12 caolanm 2007-05-31 17:10:31 UTC
I'm not sure that the final fix was right either, what I think we want to get
out of this function is the combination of scripts which are active for the
selection.

i.e. the sum of scripts which intersect with the selection. So if we have two
scripts used inside the selection we want to get both of them back. While the
final patch gets the script of the range which completely encloses the selection. 

As a side problem, when we have no selection, just a cursor to get the script of
the previous character. Basically the selection of the previous character. 

cmc->tl/mru: I think the above document and ctrl+a and change fontsize should
show what I mean. In a mixed script selection in the workspace install sets I
think only the western script will change size, not both of them. 

Does the below attached patch seem plausible instead ? or maybe I'm wrong and
the above testcase shows no regression ?
Comment 13 caolanm 2007-05-31 17:11:04 UTC
Created attachment 45558 [details]
patch
Comment 14 thomas.lange 2007-06-01 09:06:38 UTC
TL->CMC: I see the problem. Still that problem is a new one entirely different
from the original one described in this issue.
Thus the original problem is fixed and the new found issue should not prevent
this CWS from being integrated.
Please submit the patch to the new problem in an issue of it's own. 
Thanks in advance!
Comment 15 caolanm 2007-06-01 09:22:57 UTC
done, issue 78017
Comment 16 michael.ruess 2007-06-21 10:01:04 UTC
Reassigned to SBA.
Comment 17 stefan.baltzer 2007-06-26 15:42:27 UTC
SBA: Verified in CWS tl37.
Comment 18 caolanm 2007-08-27 10:50:24 UTC
closed