Bug 172163 - Including new chinese fonts into anaconda
Summary: Including new chinese fonts into anaconda
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Mike McLean
URL:
Whiteboard:
Keywords: i18n
Depends On:
Blocks: FC5Blocker
TreeView+ depends on / blocked
 
Reported: 2005-11-01 01:24 UTC by Leon Ho
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version: anaconda-10.90.21-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-18 23:26:09 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Leon Ho 2005-11-01 01:24:56 UTC
Description of problem:
There are new chinese fonts available, hence the ttf files are not included into
anaconda stage 2.

Version-Release number of selected component (if applicable):


How reproducible:
everytime

Steps to Reproduce:
1. boot into anaconda using chinese
2. and go to shell and ls -la /usr/share/fonts

Actual results:
1. The fonts are using japanese glyphs
2. /usr/share/fonts/chinese/* is not available

Expected results:
1. Using chinese glyphs
2. /usr/share/fonts/chinese/* is available

Additional info:
the fonts are in fonts-chinese package
files are /usr/share/fonts/chinese/TrueType/u{kai,ming}*.ttf

Comment 1 Chris Lumens 2005-11-01 16:33:41 UTC
Do these two fonts replace
/usr/share/fonts/chinese/TrueType/{bsmi001p,gbsn001p.ttf} or are they in
addition to those?

Comment 2 Jeremy Katz 2005-11-08 02:33:53 UTC
These fonts are significantly larger which is going to have a negative impact on
the size of the installer second stage :/

But added

Comment 3 Leon Ho 2005-11-08 03:35:07 UTC
Apologies, we should only need to include uming.ttf because both Simplified and
Traditional Chinese glyphs are in that font for Sans face. This should help on
the second stage size. Thanks Tagoh-san for the reminder. In short, uming
replaces {bsmi001p,gbsn001p}.ttf

Comment 4 Jeremy Katz 2005-11-08 04:03:31 UTC
Changed the list we include to just be uming*

Comment 5 Jeremy Katz 2005-11-14 23:28:56 UTC
Hmm, having uming* makes it so that when we load the chinese fonts, we segfault.
 Bind mounting an empty dir makes it go away -- any clue what might cause this?
 Otherwise, we might need to pull the font for test1

Comment 6 Jeremy Katz 2005-11-15 01:37:34 UTC
Backtrace looks something like
#0 FcFreeTypeCharIndex
#1 pango_fc_font_create_metrics_for_context
#2 pango_fc_font_get_glyph
....

Comment 7 Jeremy Katz 2005-11-15 02:31:40 UTC
More details..
#0 FcFreeTypeCharindex(face=0x0, ucs4=31616) at fcfreetype.c:2311
#1 pango_fc_font_real_get_glyph at pangofc-font.c:514
#2 pango_fc_font_get_glyph at pangofc-font.c:623

Not sure why pango_fc_font_lock_face is returning NULL.

Comment 9 Akira TAGOH 2005-11-15 05:20:22 UTC
I just ran anaconda with --test --method_nfs://... but it looks good to me. how
can I reproduce this?

Comment 10 Akira TAGOH 2005-11-15 11:06:23 UTC
ok, I can now reproduce this on stage2.img chroot'ed. and it also appears on
Japanese as well.

Comment 11 Akira TAGOH 2005-11-15 11:24:12 UTC
ok, I got a workaround for this now. it works fine after run fc-cache on chroot.

Comment 12 Jeremy Katz 2005-11-15 17:05:09 UTC
We're already running fc-cache on the root so I'm not sure how this is changing
anything.  How are the font caches different?

Comment 13 Akira TAGOH 2005-11-15 17:23:56 UTC
running it when stage2.img was built? hmm, it's hard to check how are their
different since the cache file became the binary file.

Comment 14 Jeremy Katz 2005-11-15 18:02:05 UTC
Yeah, we run 'chroot $DESTGR /usr/bin/fc-cache' when we create the second stage
and there's no errors in the tree log to make me think there's anything wrong. 
Also, if there were, the fonts.cache files wouldn't be there as they're not
shipped in the package.

Comment 15 Akira TAGOH 2005-11-15 18:20:53 UTC
how about the timestamp? I just noticed that all files timestamp was 1970-01-01
00:00:00. is it the same as when the second stage image was being built? I'm not
sure if it's really related to this though. and I don't see anything else
difference between the second stage and the installed environment. actually this
problem won't happens on the installed environment since all gtk2 apps works
fine without any exceptions.

Comment 16 Jeremy Katz 2005-11-15 18:44:08 UTC
cramfs actually doesn't store timestamps and sets all the times just to 0 when
requested.  That does sound like a plausible though, though

Comment 17 Matthias Clasen 2005-11-15 18:53:46 UTC
Sounds like it would have the potential to screw up cache uptodate checks, etc

Comment 18 Jeremy Katz 2005-11-16 02:31:52 UTC
Aha, I see what it is.  The font is 20 megs.  cramfs has a max file size of 16 megs.

Any way we can get this font smaller? ;)

Comment 19 Jeremy Katz 2005-11-16 05:02:06 UTC
Okay, for test1 I'm just not going to include the new font.  For test2, I'm
going to see if we can move to squashfs (which involves bribing davej with tacos...)

Comment 21 Chris Lumens 2005-12-08 19:07:35 UTC
We've moved to squashfs, so the new font has gone back in.  Please test and let
us know if it's working.

Comment 22 Lawrence Lim 2005-12-18 23:26:09 UTC
Checked with anaconda-10.90.21-1, verfied that /usr/share/fonts/chinese/* is now
available.


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