Bug 443735

Summary: [ja] corruption in font rendering in font selector
Product: [Fedora] Fedora Reporter: Jens Petersen <petersen>
Component: openoffice.orgAssignee: Caolan McNamara <caolanm>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: airlied, caolanm, eng-i18n-bugs, jnavrati
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 2.4.0-12.8 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-30 16:14:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 235705    
Attachments:
Description Flags
ja-font-selection.png none

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