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

Re: i18n of main-menu and Packages



amck@utvinternet.com writes:

> >Hi,
> >
> >
> >Hmm.
> >I tried to convert /usr/src/unifont.bdf to unifont.bgf by bdftobogl,
> >then bgf file size is 22228410 bytes. This looks too big for installer.
> 
> 
> Yes. The udeb bterm-unifont does this. The udeb compresses to
> 781kB, but consumes a lot of memory in the ramdisk.
> 
> Note: the file is mmap()'ed, so it is not all loaded into memory
> unless you are using all of it. I don't know the exact usage,
> as I have not measured it within debian-installer.

Its installed into tmpfs so its already completly in ram. Not sure if
the mmap will share the pages with tmpfs but I sure hope so. Otherwise
it would be 40 MB ram gone worst case.

> >And, dynamic font loading needs restart bterm (and it may cause a
> >problem), doesn't it?
> 
> I'm testing this out now. More details tomorrow.
> 
> >My poor idea is:
> >- We provide build/foo-<language code>.utf (such as foo-ja.utf,
> >foo-kr.utf, etc...) and apply additional (dynamic loaded) messages
> >into these files.
> >- Then merge them into all-*.utf by build/Makefile.
> 
> The problem is, we do not know all of the strings that may be
> used, and hence the characters needed.
> For example, we allow the user to choose Japanese, do base-config, install software
> into /target, then run a shell. 

Once we have /target a full font is probably no problem but till then.

Would it be possible to merge in more characters into the font file
and then send bterm a signal to reread it? That way we could make a
base font and require additional udebs to add their own characters.

> This software probably comes from the net, and could be 
> written (years) after then installer was built.  It could
> use arbitrary characters, so after the installer loads
> udebs or debs from the media, it must be capable of showing
> arbitrary characters, not just the ones used in  the boot media.
> 
> At the moment I think we do not use UTF-8 or i18n in the
> floppy installs. On the CDROM and net installs, we could
> perhaps use the low-memory loopback tricks described earlier
> to minimise memory issues; in fact I'd recommend them.

For cdrom a 22MB font file should be used directly from cdrom or
inside the low-memory trick.

But if its realy 22MB for a properly reduced font I would strongly
suggest making a more moderate european font version. English, german,
french and the like don't need that much. I guess a minority of
languages needs the majority of space. Sorry for all the chinese and
japanese users out there but all those new characters are a bit much
for a floppy.

MfG
        Goswin



Reply to: