[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Debian-in-workers] Re: GTK frontend update and maybe time for an experimental netinst cd?

Christian Perrier wrote:
i've noticed that in Anaconda, every time i change the installation languge, cdrom is accessed and some more megs of memory occupied: this because the new font is loaded from cd while other ones are kept in memory. I think that we should retrive font packages from cdrom only for the used language while removing the unneded ones: do we already a technology that is capable of doing this task?

Well, actually, because localechooser displays languge names not only
in English but also in the various languages, we actually need all
fonts for it. Well, if that happens to be a problem, we can revert
this back but such feature is here since woody installer, so, it would
be a serious step back.

I understand this but we're now no longer able to GTK-boot a pc with only 64 megs of ram even if we use only latin fonts. Imagine what if we include ALL the fonts on the cd and those fonts have to be unpacked all togheter (example: ttf-arphic-uming for chinese, as suggested on this ml)

Package Size       Installed Size
10626.4            18604

18 megs unpacked, and there are still tens of other fonts to include in the initrd image: i doubt that even 128 megs will be enough. Could we disable this feature only if using the GTK frontend and keep it in case we use the NEWT frontend?

We have the technology for loading udebs. At the moment we want to do
this (after the language choice), these udebs have to be on the initrd
image, so that's a big constraint.

And what if we move any step successive to the language choosing after accessing the cdrom?

We don't have the technology for unloading udebs, IIRC (at least, I've
never seen it used).

No one ever made experiments? and what if we would develop an home-made solution to the problem?

I think that the right direction could be the use of a "general" font,
made by collecting together the various fonts we have. This would
probably be a big font, but probably easier to maintain. Afterall,
this is what we do actually with bterm-unifont.

in this case we'll have only one big udeb, right? can we already make previsions about its size (packed/unpacked) ?

anyway i think a complete lists of matches language-fonts-fontsize is needed.
Since a list of languages supported by the debian installer already exists


could you add a pair of additional columns reporting the ttf font needed and its size by every language? Maybe this will help in picking fonts and deciding if it's better a single enormous font or many smaller font packages.



Reply to: