Issue 64447

Summary: Bad context-sensitive rule to decide the font of some characters with Asian support
Product: Writer Reporter: adah <wuyongwei>
Component: formattingAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: hdu, issues, regodesebes
Version: OOo 2.0.1Keywords: CJK, needhelp
Target Milestone: ---   
Hardware: PC   
OS: All   
See Also: https://issues.apache.org/ooo/show_bug.cgi?id=90389
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
Test file for the problem none

Description adah 2006-04-18 06:43:47 UTC
I have Asian languages support enabled. My default languages are English (UK)
(Western) and Chinese (simplified) (Asian).

The problem is with Space and Ambiguous-Width Unicode characters. When a Chinese
font is used for Asian text and Western font used for Western text (default in
my case), the current rule seems to be:

- When a space or ambiguous character occurs at the beginning of a paragraph or
after a manual line break, or after another character that is applied the
Western font, the Western font is applied; otherwise (when it occurs after a
character that is applied the Chinese font, say, a normally input Chinese
characters or a ASCII character that is applied the Chinese font) the Asian font
is applied.

This causes headaches in the following scenarios:

1) For a phrase like "测试“testâ€" (whether imported from a Word file or directly
input), the left quote will appear in the Chinese font SimSun, but the right
quote will appear in the Western font Times New Roman.

2) For a phrase like "测试 test 测试", the first space will be in Chinese font,
and the second will be in Western font.

3) For a phrase like "测试“测试â€", if I insert a manual break before the left
quote, the left quote will be in Western font suddenly.

The rule of Word seems to be simpler. When importing text under a East Asian
enabled environment, all the ambiguous-width characters are applied the East
Asian font, and spaces are always applied the Western font; unless one manually
chooses another font for the text. It seems more reasonable and intuitive.
Comment 1 michael.ruess 2006-04-18 10:59:09 UTC
Reassigned to SBA.
Comment 2 adah 2006-04-27 06:43:57 UTC
This problem occurs on Linux (Ubuntu, etc.) too, although on one specific
distribution (Red Flag from China), the ambiguous-width characters (like left
and right quotes) always appear in the Chinese font. I think the vendor did
something about it, but the space problem is always there :-(.
Comment 3 stefan.baltzer 2008-12-10 21:42:48 UTC
Many issues been adressed since OOo 2.0.1 concerning CTL languages and character
treatment. Please re-verify your findings in OOo 3.0 and comment here.
Thank you.

Set isssue to "Worksforme".
Comment 4 stefan.baltzer 2008-12-10 21:44:33 UTC
Closing issue. 
Feel free to reopen if findings concerning this scenario in OOo 3.0 or later can
justify it.
Comment 5 adah 2008-12-28 05:52:39 UTC
I tested again on OOo 3.0, and all the problems I had described were still there.
Comment 6 Rainer Bielefeld 2013-07-18 04:39:18 UTC
OS = ALL due to comment 2

If this still is a problem a sample document wold help to understand the problem for users without Chinese language knowledge
Comment 7 adah 2013-07-21 03:08:20 UTC
Created attachment 81108 [details]
Test file for the problem

Add the test file as requested.

Please notice the text in the original bug report is now corrupt for some reason and I cannot decipher it now. It contains no Chinese now.
Comment 8 arego 2013-07-21 11:46:32 UTC
The bug continues in Ubuntu's LibreOffice 4.0.2.2 (Compilation ID: 400m0(Build:2).
Comment 9 adah 2013-07-21 14:49:23 UTC
Try restoring the corrupt part in the original bug report:

1) For a phrase like "测试“test”" (whether imported from a Word file or directly
input), the left quote will appear in the Chinese font SimSun, but the right
quote will appear in the Western font Times New Roman.

2) For a phrase like "测试 test 测试", the first space will be in Chinese font,
and the second will be in Western font.

3) For a phrase like "测试“测试”", if I insert a manual break before the left
quote, the left quote will be in Western font suddenly.
Comment 10 Rainer Bielefeld 2013-07-22 05:11:12 UTC
Reporter tells lots of observations, but for me it's difficult to find out what observations might show a bug and what observations might not.

My test  with  "AOO 4.0.0-Dev – German UI / German locale  [AOO400m3(Build:9702)  -  Rev. 1503709 (2013-07-17) ]" on German German WIN7 Home Premium (64bit)", Common 4.0-dev User Profile, Asian language support ant CTL enabled:

1. Open reporters sample document, Zoom -> 600% and observe word "test" in 
   second sentence
2. click behind opening quotation mark before word "test"
   > It will be shown as font "SimSun" (also see remark 'a' below!)
3. click behind closing quotation mark behind word "test"
   > It will be shown as font "Time New Roman"

This might be unexpected, but who can know what reporter typed? My ODF skills are not sufficient to decide what viewing should be expected.

But:
10. Redo steps 1 ... 3, but with SoftMaker FreeOffice
    Here in step 2 opening quotation mark will be shown as font "Time New Roman"
    what might be more plausible. 
    But again, currently I can't tell whether I observe a Bug in FreeOffice 
    or in AOO

Additional information
----------------------
a) it's easy to distinguish opening quotation marks in "Time New Roman" and "SimSun" (you can also compare with opening quotation mark in first sentence):
Click behind opening quotation mark before word "test" in second sentence and mark it,  then change font from "SimSun" to "Time New Roman". You will observe that the wide space between quotation mark and chinese character before will disappear (related to "Bug 90389 - CJK punctuation compression "?), and viewing is different, in "SimSun" the curve above the fat point at the bottom of each of the 2 elements does not exceed the fat point to the left

b) BTW, http://odf-validator.rhcloud.com/ rates reporter's sample as valid ODF

c) Results with other programs:
   Sympony: Like AOO
   LibreOffice 4.0.3:  Like AOO

d) I think it's an AOO bug, but help of an ODF expert required for final decision
Comment 11 adah 2013-07-22 05:55:39 UTC
Yes, it is possible to manually change the fonts to make them correct. In fact, that is what I have to do when preparing a well-typeset document with OpenOffice. The problem is: Why should I have to do this? I just want to apply a font setting (choose different fonts for Eastern and Western characters in Writer) to the whole document, and why should a symbol have different fonts applied just because what is before it (or its absence)?

As a side note, I have seen enough Chinese ODF (or ODF-generated PDF) documents that suffer from this problem. The result is unacceptable for me.

IMHO, this is a serious design flaw in OpenOffice.

(In reply to Rainer Bielefeld from comment #10)
> Reporter tells lots of observations, but for me it's difficult to find out
> what observations might show a bug and what observations might not.
> 
> My test  with  "AOO 4.0.0-Dev – German UI / German locale 
> [AOO400m3(Build:9702)  -  Rev. 1503709 (2013-07-17) ]" on German German WIN7
> Home Premium (64bit)", Common 4.0-dev User Profile, Asian language support
> ant CTL enabled:
> 
> 1. Open reporters sample document, Zoom -> 600% and observe word "test" in 
>    second sentence
> 2. click behind opening quotation mark before word "test"
>    > It will be shown as font "SimSun" (also see remark 'a' below!)
> 3. click behind closing quotation mark behind word "test"
>    > It will be shown as font "Time New Roman"
[snipped]
> a) it's easy to distinguish opening quotation marks in "Time New Roman" and
> "SimSun" (you can also compare with opening quotation mark in first
> sentence):
> Click behind opening quotation mark before word "test" in second sentence
> and mark it,  then change font from "SimSun" to "Time New Roman". You will
> observe that the wide space between quotation mark and chinese character
> before will disappear (related to "Bug 90389 - CJK punctuation compression
> "?), and viewing is different, in "SimSun" the curve above the fat point at
> the bottom of each of the 2 elements does not exceed the fat point to the
> left
Comment 12 Rainer Bielefeld 2014-05-03 06:58:15 UTC
I have no skills here