Re: newt frontend: Asian chars and line-drawing chars working
[Alastair McKinstry]
> I've got the i18n and line-drawing chars working for the Newt
> front-end in d-i. For a test, download 'initrd' from
> http://people.debian.org/~mckinstry, and try it (vmlinuz 2.4.20-1),
> with vga=0x314 as a kernel parameter.
This sounds very good. Why do you need the vga=0x314 parameter? When
I try the same in my VMWare, the kernel tells me "You passed an
undefined mode number." and ask me to choose another.
> This depends on a patch to slang, (NMU in queue), and an upgraded newt,
> which will be uploaded when the slang NMU hits the archive. For the
> moment they are also available at p.d.o/~mckinstry
The new slang version is in the archive. I look forward to the new
newt version. :)
> It also requires the bterm from BOGL library; I'm creating a udeb
> patch for it.
The bogl-bterm maintainer was working on this before we discovered the
UTF-8 mode in the console and told him to wait. Coordinate your work
with him. Is it an option to use the bogl cdebconf frontend instead?
> For localisation, what remains is a solution for the font. At the moment
> the makefile builds a reduced font, based on the chars needed for the
> udebs in the initial image. I think what is required after that is a
> package that includes the _full_ unicode font; If we are to allow
> base-config, or more, to be run within a chroot, the list of needed
> chars is unbounded (in particular, it can change _after_ the initial
> media is created ). So I'm creating a di-console-font udeb to do this in
> debian-installer/tools. (There was a package I'd expected to use ,
> console-fonts-udeb, within the console-tools source deb, but as that is
> pure console fonts, rather than bdf / bterm fonts, it would be cleaner
> to start afresh and remove console-fonts-udeb).
I know little about fonts, I just copied the font generation code from
b-f into d-i/build/. :)
Reply to: