Christian Perrier wrote:
To cover all the languages of India, you would need all these packages.That may be the problem. As Attilio pointed, we're very likely to have size constraints...and having too many font packages needed will also complicate the build and the maintenance.
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?
Should I make one udeb with a font from each script or 8 different udebs with one font each.Debian-installer currently uses unifont doesn't it? Is this opentype? If so would it make sense to add Indic glyphs to it?Well, having a single font that could be used for as many languages as possible would certainly at least help in maintenance, yes. For that, we might need some font wizard(s)...
and we must consider we'll have to prepare and mantain udebs for arabic, japanese, chinese, korean, etc. too: who's gonna take care of packaging those fonts? Anyway i hope Alastair McKinstry will solve soon the problem of the missing libgtk+2.0-directfb0-udeb archive: this seems to be the main reason that prevents us from starting to build GTK netinst cds, or is there any other problem i've not taken count of?
ciao attilio