At Fri, 2 Apr 2021 11:51:26 +0200, Pavel Stehule <pavel.stehule@gmail.com> wrote in > with this patch, the formatting is correct
I think the hardest point of this issue is that we don't have a reasonable authoritative source that determines character width. And that the presentation is heavily dependent on environment.
Unicode 9 and/or 10 defines the character properties "Emoji" and "Emoji_Presentation", and tr51[1] says that
> Emoji are generally presented with a square aspect ratio, which > presents a problem for flags. ... > Current practice is for emoji to have a square aspect ratio, deriving > from their origin in Japanese. For interoperability, it is recommended > that this practice be continued with current and future emoji. They > will typically have about the same vertical placement and advance > width as CJK ideographs. For example:
Ok, even putting aside flags, the first table in [2] asserts that "#", "*", "0-9" are emoji characters. But we and I think no-one never present them in two-columns. And the table has many mysterious holes I haven't looked into.
We could Emoji_Presentation=yes for the purpose, but for example, U+23E9(BLACK RIGHT-POINTING DOUBLE TRIANGLE) has the property Emoji_Presentation=yes but U+23E9(BLACK RIGHT-POINTING DOUBLE TRIANGLE WITH VERTICAL BAR) does not for a reason uncertaion to me. It doesn't look like other than some kind of mistake.
About environment, for example, U+23E9 is an emoji, and Emoji_Presentation=yes, but it is shown in one column on my xterm. (I'm not sure what font am I using..)
A possible compromise is that we treat all Emoji=yes characters excluding ASCII characters as double-width and manually merge the fragmented regions into reasonably larger chunks.
From:
"Euler Taveira" Date: Subject:
Re: Logical Replication - improve error message while adding tables to the publication in check_publication_add_relation
