Bug 443735 - [ja] corruption in font rendering in font selector
Summary: [ja] corruption in font rendering in font selector
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: F9Target
TreeView+ depends on / blocked
 
Reported: 2008-04-23 03:05 UTC by Jens Petersen
Modified: 2009-10-22 12:44 UTC (History)
4 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2008-04-30 16:14:45 UTC


Attachments (Terms of Use)
ja-font-selection.png (59.63 KB, image/png)
2008-04-23 03:06 UTC, Jens Petersen
no flags Details

Description Jens Petersen 2008-04-23 03:05:18 UTC
Description of problem:
With current rawhide, in Japanese ewhen I try to select the
Sazanami fonts in the font selector their entries are not
rendered correctly but appear as garbage.

How reproducible:
every time

Steps to Reproduce:
1. install rawhide with Japanese support (to get sazanami-fonts installed)
2. run: LANG=ja_JP.UTF-8 oowriter
3. try to select one of the Sazanami fonts (near bottom of list)
  
Actual results:
3. entries appear as noise

Expected results:
3. normal rendering in Japanese

Comment 1 Jens Petersen 2008-04-23 03:06:23 UTC
Created attachment 303418 [details]
ja-font-selection.png

Comment 2 Akira TAGOH 2008-04-23 05:41:21 UTC
That works for me with:

fonts-japanese-0.20061016-13.fc9.noarch
dejavu-lgc-fonts-2.24-3.fc9.noarch
wqy-zenhei-fonts-0.5.23-0.fc9.noarch
sazanami-fonts-gothic-0.20040629-4.20061016.fc8.noarch
bitstream-vera-fonts-1.10-8.noarch
xorg-x11-fonts-100dpi-7.2-6.fc9.noarch
xorg-x11-fonts-ISO8859-1-100dpi-7.2-6.fc9.noarch
texlive-texmf-fonts-2007-20.fc9.noarch
bitmap-fonts-0.3-5.2.fc9.noarch
cjkunifonts-uming-0.1.20060928-4.fc8.noarch
ghostscript-fonts-5.50-18.fc8.noarch
xorg-x11-fonts-truetype-7.2-4.fc9.noarch
taipeifonts-1.2-5.fc9.noarch
xorg-x11-fonts-misc-7.2-6.fc9.noarch
liberation-fonts-1.0-4.fc9.noarch
cjkunifonts-ukai-0.1.20060928-4.fc8.noarch
texlive-texmf-errata-fonts-2007-4.fc9.noarch
xorg-x11-fonts-ISO8859-1-75dpi-7.2-6.fc9.noarch
sazanami-fonts-mincho-0.20040629-4.20061016.fc8.noarch
xorg-x11-fonts-75dpi-7.2-6.fc9.noarch
urw-fonts-2.4-5.fc9.noarch
fonts-chinese-3.03-12.fc8.noarch
xorg-x11-fonts-Type1-7.2-6.fc9.noarch
VLGothic-fonts-20071215-2.fc9.noarch

and

openoffice.org-core-2.4.0-12.6.fc9.i386
openoffice.org-writer-2.4.0-12.6.fc9.i386
openoffice.org-writer2latex-0.5-2.fc9.i386
fontconfig-2.5.0-2.fc9.i386

just wondering if any fontconfig conf files came from the font packages may
affects this.

Comment 3 Caolan McNamara 2008-04-23 08:49:00 UTC
origfamily is Sazanami Gothic
familylang and family is ar Sazanami Gothic
familylang and family is ja さざなみゴシック

I wonder why this font has an ar as "arabic" name and not e.g. an en for
"english" name. I suspect that our problem here is similar to rhbz#443356 where
we want to prefer a localized name for UI purposes but fontconfig only gives the
expected font hints for the "canonical" name which we need to map the localized
names back to.

lets give that a go...

Comment 4 Caolan McNamara 2008-04-24 07:59:52 UTC
Can you check 
http://koji.fedoraproject.org/packages/openoffice.org/2.4.0/12.7.fc9
for me ?

Comment 5 Jens Petersen 2008-04-28 07:15:00 UTC
Seems this is an xorg-x11 issue since changing from nv to vesa drivers
makes it go away - Dave Airlie is aware of it, and I think there is another bug open
for it somewhere.

Comment 6 Jens Petersen 2008-04-28 07:17:58 UTC
A temporary workaround is to give

Option "XaaNoCPUToScreenColorExpandFill"

to the nv driver.

Comment 7 Dave Airlie 2008-04-28 07:43:03 UTC
this is quite similiar to 384631

Comment 8 Jens Petersen 2008-04-28 07:57:21 UTC
(In reply to comment #4)
> http://koji.fedoraproject.org/packages/openoffice.org/2.4.0/12.7.fc9

Thanks!  I tested it now and it fixes the problem in Oo.o. :)

Comment 9 Caolan McNamara 2008-04-30 16:13:52 UTC
Whatever about the reason for rendering corrupt, it should never have happened
anyway as we should have been using different flags anyway which avoid the
situation as a side-effect


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