>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. >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. 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. >Kenshi Muto >[EMAIL PROTECTED] > Alastair McKinstry [EMAIL PROTECTED] >-- >To UNSUBSCRIBE, email to [EMAIL PROTECTED] >with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
