On 26.09.2024 15:48, Frediano Ziglio wrote:
> --- a/xen/drivers/video/font_8x14.c
> +++ b/xen/drivers/video/font_8x14.c
> @@ -2059,7 +2059,7 @@ static const unsigned char fontdata_8x14[FONTDATAMAX] =
> {
> 0x00, /* 00000000 */
> 0x00, /* 00000000 */
>
> - /* 128 0x80 'Ÿˆ */
> + /* 128 0x80 'Ÿˆ */
I'm unconvinced this representation is any better. The data that follows
right here clearly means 'Ç', not 'Ÿ'. Which is U+00c7, not U+0080. I
don't have my Unicode manual to hand, but I seem to vaguely recall that
U+0080 doesn't really have a glyph associated with it.
Of course I'm also uncertain whether my mail UI actually correctly decoded
the transfer encoding (base64) that you now used. In any event I'm unsure
of associating the upper 128 code points with any particular characters
(glyphs). We don't render UTF-8 to the console, and what those code points
mean is unknown until code page information is provided. I see the
following options:
1) The glyphs represent what the bit patterns encode, encoded as UTF-8.
2) The glyphs are simply omitted for the upper half of the range.
3) We purge any encoding of particular glyphs for the upper half of the
range and instead expand the upper 128 entries to some placeholders
when rendering (like e.g. the Windows font I'm looking at, using a
boxed question mark).
Jan
