From: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Unicode grapheme clusters |
Date: | 2023-01-24 16:47:32 |
Message-ID: | CAMsGm5dfwyA3qba2MAC_t384X8uTfhwc2q8jtat1pxHTA-z3UA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 24 Jan 2023 at 11:40, Greg Stark <stark(at)mit(dot)edu> wrote:
>
> At the end of the day Unicode kind of assumes a variable-width display
> where the rendering is handled by something that has access to the
> actual font metrics. So anything trying to line things up in columns
> in a way that works with any rendering system down the line using any
> font is going to be making a best guess.
>
Really what is needed is another Unicode attribute: how many columns of a
monospaced display each character (or grapheme cluster) should take up. The
standard should include a precisely defined function that can take any
sequence of characters and give back its width in monospaced display
character spaces. Typefaces should only qualify as monospaced if they
respect this standard-defined computation.
Note that this is not actually a new thing: this was included in ASCII
implicitly, with a value of 1 for every character, and a value of n for
every n-character string. It has always been possible to line up values
displayed on monospaced displays by adding spaces, and it is only the
omission of this feature from Unicode which currently makes it impossible.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2023-01-24 16:57:26 | Re: cutting down the TODO list thread |
Previous Message | Tom Lane | 2023-01-24 16:43:25 | Re: run pgindent on a regular basis / scripted manner |