Red Hat Bugzilla – Bug 180588
[oocalc] inconsistent font result with c'n'p
Last modified: 2014-03-25 20:53:09 EDT
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):
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)
zh_TW is bitmapp font while zh_CN is not
should be consistently bitmap
Created attachment 124423 [details]
sample text with from zh_TW locale and zh_CN locale
Created attachment 124432 [details]
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
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
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.
must have been http://qa.openoffice.org/issues/show_bug.cgi?id=61841 I bet