Re: Broken commandline

[Dr . Jürgen Sauermann]

Hi Kacper,

thanks a lot for your explanation.

I should add that the APL formatting model is heavily based on the 
assumption that
every character has the same size (like it was the case for old APL 
terminals). So
even if a font were able to tell that some (APL-) character takes 2 
screen columns,
then I am afraid that the printout of APL values with rank > 1 would 
still look a little
messy if such characters are being printed.

So fixing the the Noto Sans Mono font bug would not solve the problem 
entirely.
My proposal would be to use a different font where all characters have 
the same size
(my favourite is Courier with Unicode characters).

Best Regards,
Jürgen


On 6/4/21 10:24 AM, Kacper Gutowski wrote:
> On Fri, Jun 04, 2021 at 12:47:31AM +0200, Hans-Peter Sorge wrote:
> > However, there are "graphically oriented" UTF characters (including 
> > ⍝⊖⍟⍱), that take two character positions when being displayed and 
> > take one character position when being selected.
> >
> > So it's not an APL character / font handling problem. It Just 
> > happened to be the first popup.
>
> This sounds indicative of the kind of font problem where the terminal 
> emulator has a different idea about widths of glyphs than what the 
> font actually provides, i.e. when the font isn't really monospaced.
>
> You mentioned Noto Sans Mono earlier. If APL characters are displayed 
> for you using that font, either because you chose it or because your 
> chosen font doesn't have them and Noto Sans Mono happens to be used as 
> a fallback, then you surely will have this problem because the 
> mentioned characters are twice as wide as other characters in this font.
>
> And it's for no good reason. Unlike Chinese characters, these were 
> never a part of any East Asian character set (unless you count a 
> certain communist symbol from North Korean character set being 
> informally mapped to ⍟ by some sources) and their East Asian Width 
> property in Unicode is "neutral" and wcwidth returns 1 for them. So 
> they are expected to take only one character cell and in many terminal 
> emulators this leads to the behaviour you described when they don't.
>
> This should be considered a bug in Noto Sans Mono.
>
> -k