[Bug 462295] not displaying Korean glyphs
bugzilla at redhat.com
bugzilla at redhat.com
Mon Sep 15 18:03:58 UTC 2008
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
--- Comment #7 from Nicolas Mailhot <nicolas.mailhot at laposte.net> 2008-09-15 14:03:57 EDT ---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #2)
> > > Font SIG guys, when anaconda (the installer) is running it runs in its own
> > > environment. This environment gets build by the upd-instroot script. This
> > > script starts by installing a list of packages into a chroot and then removing
> > > any files not in a list of files to keep, so as to reduce the footprint of the
> > > install image, currently the lists of packages being installed to get the
> > > necessary fonts to get the installer to be able to render text in non western
> > > charactersets is listed above. This list clearly is no longer correct for
> > > rawhide, we could use some help in getting it fixed.
> > The default install list in the @fonts group is supposed to provide support for
> > all our locales. Is it for some reason not good enough for you?
> Well for one our current script only handles packages, not groups, but we could
> fix that, besides that we are trying to keep things as small as possible (this
> goes on boot.iso) so it would be good to know if there is anything we could
> leave out for the installer case. For example it serves little purpose to ship
> fonts for language for which there is no anaconda translation.
> So some questions:
> 1) The fonts-lang aliases are going away, right?
fonts-lang packages have not been representative of our language support for
quite a long time. What we had was a mix of font-lang packages and font
packages named another way. During the past releases we've tried to consolidate
font support by first renaming font-lang packages so they follow the same
conventions as other font packages (keeping legacy aliases to their old names)
and then in the future we'll kill those aliases too.
> 2) Is there a table somewhere with lang -> needed font mappings
I've tried to get the L10N teams fill
but it's not been a huge success. I'm afraid only local guys know which font is
best for them.
> 3) Are there any fonts in the font group which are there to for example have
> a decent selection of fonts for language foo in openoffice, but which could
> be left out without affecting the ability to display language foo?
I think the intention is to have a default font selection in @fonts which is
sufficient to display all our locales, and then have additional fonts for foo
locale defined both in @foo-support comps group and as optional @fonts members.
Of course the package lists are not as complete and accurate as we'd like them
to be and an audit is always welcome.
Thus while the default fonts list in the @fonts group is probably closest to
what you need, it will have two defaults:
— it covers all the scripts we know of, not just the scripts needed by anaconda
— it will have some duplication (for example latin is important enough we
install both liberation and dejavu by default)
However maintaining this list is already a lot of work and I don't see us
maintaining another one just for anaconda. (Of course if comps had some notion
of inheritance we could do stuff like "@fonts group is composed of
@anaconda-fonts + those fonts anaconda does not care about")
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the fonts-bugs