Bug 172163 - Including new chinese fonts into anaconda
Including new chinese fonts into anaconda
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Mike McLean
: i18n
Depends On:
Blocks: FC5Blocker
  Show dependency treegraph
 
Reported: 2005-10-31 20:24 EST by Leon Ho
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Leon Ho 2005-10-31 20:24:56 EST
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 11:33:41 EST
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-07 21:33:53 EST
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-07 22:35:07 EST
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-07 23:03:31 EST
Changed the list we include to just be uming*
Comment 5 Jeremy Katz 2005-11-14 18:28:56 EST
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-14 20:37:34 EST
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-14 21:31:40 EST
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 00:20:22 EST
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 06:06:23 EST
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 06:24:12 EST
ok, I got a workaround for this now. it works fine after run fc-cache on chroot.
Comment 12 Jeremy Katz 2005-11-15 12:05:09 EST
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 12:23:56 EST
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 13:02:05 EST
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 13:20:53 EST
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 13:44:08 EST
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 13:53:46 EST
Sounds like it would have the potential to screw up cache uptodate checks, etc
Comment 18 Jeremy Katz 2005-11-15 21:31:52 EST
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 00:02:06 EST
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 14:07:35 EST
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 18:26:09 EST
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.