Breezy installer resolution

[Alvin Thompson]

yup, i agree that under the best of circumstances it would be a pain and
it's definitely an ugly kludge. the one positive is that you wouldn't
really have to maintain it assuming that the problem is being addressed
in the kernel. just thought i'd bounce the idea out there.

do you know if the kernel framebuffer issues will be resolved by the
time Drake rolls out?

-alvin


On Wed, 2005-09-14 at 21:18 +0100, Colin Watson wrote:
> On Wed, Sep 14, 2005 at 03:41:08PM -0400, Alvin Thompson wrote:
> > On Wed, 2005-09-14 at 01:21 -0700, Matt Zimmerman wrote:
> > > This issue has nothing to do with the font.
> > 
> > i'm thinking of an alternative solution. if you can change fonts after
> > the kernel has loaded, why not create a custom font with just the
> > characters necessary to display the names of all the languages? for
> > 'english', you would just need 7 characters: e-n-g-l-i-s-h. you would
> > only need 4 additional characters for 'français', since the 'i', 'n' and
> > 's' is already added for english and the 'a' is repeated. you get the
> > idea.
> 
> Some languages have double-width characters in their fonts, which would
> cause further pain here. I'm afraid I'm not really interested in
> attempting or maintaining this kind of complicated kludge; making it
> work in cdebconf, bterm, localechooser (especially at the same time as
> localechooser's parallel function in oem-config!), main-menu, and so on
> would be likely to make the whole installer less reliable for the
> benefit of a few pieces of hardware that can probably be dealt with by
> (fundamentally) simpler and more correct fixes in the kernel.
> 
> Maybe with an installer written in C talking to the framebuffer
> directly, this kind of thing would be practical - but we've moved on
> quite some distance from there. Using higher-level abstractions for the
> installer has a huge number of benefits, but it does mean that the
> maintenance costs of special-purpose hacks for individual installer
> components become too high, and we have to concentrate on more general
> solutions. Fortunately, in the end that's usually the right approach.
> 
> Cheers,
> 
> -- 
> Colin Watson                                       [cjwatson at ubuntu.com]

-- 
Alvin Thompson

Navy: 42
Army: 13