[vlc-devel] [RFC PATCH] freetype: using Pango for text layout

[Salah-Eddin Shaban]

On Fri, Jan 23, 2015 at 10:49 AM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le 2015-01-22 13:00, Salah-Eddin Shaban a écrit :
>>
>> Thanks :)
>> I think you're right. It does seem like an endianness issue.
>>
>> Is this the official way to handle such an issue?
>
>
> No. VLC has dedicated functions for byte endianess conversion and others for
> character sets conversion. But UTF-8 is endian-independent by design, so
> this is rather suspicious.
>
> Regardless the only reason why UTF-32 is involved is FreeType. I have not
> checked pango's documentation. But it is more modern, so I would expect it
> to support UTF-8 to some extent, especially the high-level API.
>

It's the other way round. Pango accepts only UTF-8 strings so I had to
convert psz_text (which is uni_char_t*) to UTF-8. I tried g_convert
and VLC's FromCharset, with a source charset of "UCS-4" and they both
produced weird results. I remember the resulting UTF-8 string was
longer (in bytes) than the source, which didn't make any sense, and of
course, Pango rejected that as "invalid UTF-8 string". The only way it
worked was by reversing the byte order of the source (UCS-4) string,
so the endiannes issue was not with UTF-8.

>> I mean is endian.h a standard header on all platforms?
>
>
> No. You can look up ISO C and POSIX specifications online by the way...

Thanks for the tip.