Bug 180588 - [oocalc] inconsistent font result with c'n'p
[oocalc] inconsistent font result with c'n'p
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Caolan McNamara
: i18n
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-09 00:58 EST by Lawrence Lim
Modified: 2014-03-25 20:53 EDT (History)
3 users (show)

See Also:
Fixed In Version: openoffice.org-calc-2.0.1.1-11.2.2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 21:41:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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


External Trackers
Tracker ID Priority Status Summary Last Updated
OpenOffice.org 61841 None None None Never

  None (edit)
Description Lawrence Lim 2006-02-09 00:58:35 EST
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 00:58:35 EST
Created attachment 124423 [details]
sample text with from zh_TW locale and zh_CN locale
Comment 2 Caolan McNamara 2006-02-09 07:26:03 EST
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 06:07:21 EST

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-21 21:41:23 EST
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 04:06:52 EST
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.