Bug 180588 - [oocalc] inconsistent font result with c'n'p
Summary: [oocalc] inconsistent font result with c'n'p
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org
Version: 5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-02-09 05:58 UTC by Lawrence Lim
Modified: 2014-03-26 00:53 UTC (History)
3 users (show)

Fixed In Version: openoffice.org-calc-2.0.1.1-11.2.2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-02-22 02:41:23 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
sample text with from zh_TW locale and zh_CN locale (745 bytes, text/plain)
2006-02-09 05:58 UTC, Lawrence Lim
no flags Details
screenshot (256.29 KB, image/png)
2006-02-09 12:26 UTC, Caolan McNamara
no flags Details


Links
System ID Private Priority Status Summary Last Updated
OpenOffice.org 61841 0 None None None Never

Description Lawrence Lim 2006-02-09 05:58:35 UTC
Description of problem:
Copy and pasting chinese characters in oocalc under en_US locale produce in very
inconsistent result. The same problem also exist in non-en_US locale, however,
it is much less obvious.

Version-Release number of selected component (if applicable):
openoffice.org-calc-2.0.1.1-5.2

How reproducible:
Always

Steps to Reproduce:
1.open the sample text with gedit
2.copy the entire text to clipboard
3.paste into the cell with Paste Special (unfomatted text)
  
Actual results:
zh_TW is bitmapp font while zh_CN is not

Expected results:
should be consistently bitmap

Additional info:

Comment 1 Lawrence Lim 2006-02-09 05:58:35 UTC
Created attachment 124423 [details]
sample text with from zh_TW locale and zh_CN locale

Comment 2 Caolan McNamara 2006-02-09 12:26:03 UTC
Created attachment 124432 [details]
screenshot

Both gedit and OOo will attempt font substitution if the given font doesn't
have the glyphs, and we've patched OOo to use fontconfig like gtk does for this
process. So we need to make sure that gedit and OOo are both starting their
search and substitutions from the same starting position when seeing if this
has gone wrong in one of them.

So as in this attachment I've set gedit to use Luxi Sans 10 the same as oocalc.
Is the problem visible in this screenshot ?. 

(and the debugging variable "SAL_EMBEDDED_BITMAP_PRIORITY" is not set in the
environment), i.e. unset SAL_EMBEDDED_BITMAP_PRIORITY

Comment 3 Rahul Sundaram 2006-02-20 11:07:21 UTC

These bugs are being closed since a large number of updates have been released
after the FC5 test1 and test2 releases. Kindly update your system by running yum
update as root user or try out the third and final test version of FC5 being
released in a short while and verify if the bugs are still present on the system
.Reopen or file new bug reports as appropriate after confirming the presence of
this issue. Thanks

Comment 4 Lawrence Lim 2006-02-22 02:41:23 UTC
RE: Comment #2
Apologies for the delay. Yes, the behaviour in the screenshot is very ideal.
Seems you have went ahead and make changes to oocalc. It is now working
perfectly in FC5Test3. Thanks.

Comment 5 Caolan McNamara 2006-02-22 09:06:52 UTC
must have been http://qa.openoffice.org/issues/show_bug.cgi?id=61841 I bet


Note You need to log in before you can comment on or make changes to this bug.