On 26.09.2024 18:03, Frediano Ziglio wrote:
> On Thu, Sep 26, 2024 at 3:46 PM Jan Beulich <jbeul...@suse.com> wrote:
>>
>> 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.
>
> That was what I was trying to do.
> I wrongly thought it was latin1, in reality looking at the font (why
> not?) it's code page 437, so this commit is doing the right thing
> https://gitlab.com/xen-project/people/fziglio/xen/-/commit/7ca512e8ae21bb02339ed7a1a78409827a08aea4.
Yes, this looks good (after looking at just a few entries).
> Now... I'm trying to send the patch to the mailing list, which seems
> easy, but I have to find the right combination of options, tools get
> very easily confused about (that's why I send the link of the commit,
> at least people can take a look and see that is correct)
Maybe this is a case where, besides inlining, it would help to also
attach the patch, to remove any possible ambiguity due to back and
forth en-/decoding?
Jan
