On 27/09/2024 7:25 am, Jan Beulich wrote:
> 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?
I'm just going to take it straight from git. That has the least chance
of errors.
~Andrew
