4 ms·

a lovely example is uFDFD, ﷽ (single char)

by adzicg 9y ago

chrismorgan 9y ago
I am referring to Annex #11 (East Asian Width) of the Unicode Standard, which is all about CJK. Under those rules, U+FDFD is one column wide. If you happen to see it rendering really wide in the middle of text set in a monospaced typeface, it’s probably because a fallback font is being employed. In one arrangement locally I see it as eleven-and-a-bit columns, because it’s using it from another font; in another which sticks stringently to actual columns and doesn’t use fallbacks at all, it’s one-column-wide blank. I do not know of any monospaced fonts that include U+FDFD. I’m not at all sure what they would do with it. What I find particularly amusing about U+FDFD is the broad range of widths and styles it can take. I see three wildly differing styles depending on the font employed (two long ones and one roughly square one).
- JdeBP 9y ago
  My terminal displays it just fine, so it must be in at least one of the bitmap monospace fonts that I have configured it with.
  - chrismorgan 9y ago
    That doesn’t mean it’s being rendered monospace. (When herein I say “terminals” I mean “terminals/renderers/text editors/things like that”.) Some terminals are truly monospace, simply not drawing glyphs that aren’t available at the right size (e.g. xterm). Some terminals don’t actually care about being monospaced all that much, and are quite happy to handle glyphs of differing sizes, though up/down movements may still be character-based (e.g. Notepad++). Some terminals try hard to both be monospaced and show you useful stuff, and will either horizontally truncate the glyph, or draw subsequent glyphs on top of any overflow (e.g. gVim). Some terminals simply make a total hash of it, with the cursor positioning being monospaced, but drawing subsequent characters after the incorrectly-wide glyph (e.g. Ace). Your example of U+FDFD is bonus fun because it’s RTL. Most terminals don’t handle RTL at all well. (Terminals capable of proportional rendering such as Notepad++ and plain old Notepad are much more likely to treat it properly in my experience.)
    - JdeBP 9y ago
      Yes it does. I wrote the terminal program. I know what it does with fonts.
      - chrismorgan 9y ago
        I’m curious: how many columns is it occupying? From all that I can see, it should be a single column, with the font incapable of overriding that.
        JdeBP 9y ago
        I can tell you that terminal emulator is finding the character in the fonts that I have configured it with. But it won't tell you the stuff about character widths that you want to know, I suspect. As I mentioned, my terminal emulator uses bitmap fonts. Whilst bitmap fonts do have a mechanism of specifying either single-width or double-width characters, it ignores that and displays everything in the same width, rescaling everything with some slight special-casing of block graphic and horizontally repeatable characters. So whilst by the looks of the amount of detail in the glyph on screen, U+FDFD is a double-width character in the font file; it occupies a single column. See the "Fonts" section of http://jdebp.eu./Softwares/nosh/guide/console-fb-realizer.html http://jdebp.eu./Softwares/nosh/guide/console-fb-realizer.ht... I am currently using a mixture of monospace bitmap fonts that I have obtained from various places: --vtfont-normal-i fonts/t0-16i-unicode.fnt --vtfont fonts/9x15.fnt --vtfont fonts/k16-1990.fnt --vtfont fonts/unifont-7.0.06.fnt So U+FDFD is somewhere in those. (-:

a lovely example is uFDFD, ﷽ (single char)

by adzicg 9y ago

a lovely example is uFDFD, ﷽ (single char)

I am referring to Annex #11 (East Asian Width) of the Unicode Standard, which is all about CJK. Under those rules, U+FDFD is one column wide. If you happen to see it rendering really wide in the middle of text set in a monospaced typeface, it’s probably because a fallback font is being employed. In one arrangement locally I see it as eleven-and-a-bit columns, because it’s using it from another font; in another which sticks stringently to actual columns and doesn’t use fallbacks at all, it’s one-column-wide blank. I do not know of any monospaced fonts that include U+FDFD. I’m not at all sure what they would do with it. What I find particularly amusing about U+FDFD is the broad range of widths and styles it can take. I see three wildly differing styles depending on the font employed (two long ones and one roughly square one).

JdeBP 9y ago
My terminal displays it just fine, so it must be in at least one of the bitmap monospace fonts that I have configured it with.
- chrismorgan 9y ago
  That doesn’t mean it’s being rendered monospace. (When herein I say “terminals” I mean “terminals/renderers/text editors/things like that”.) Some terminals are truly monospace, simply not drawing glyphs that aren’t available at the right size (e.g. xterm). Some terminals don’t actually care about being monospaced all that much, and are quite happy to handle glyphs of differing sizes, though up/down movements may still be character-based (e.g. Notepad++). Some terminals try hard to both be monospaced and show you useful stuff, and will either horizontally truncate the glyph, or draw subsequent glyphs on top of any overflow (e.g. gVim). Some terminals simply make a total hash of it, with the cursor positioning being monospaced, but drawing subsequent characters after the incorrectly-wide glyph (e.g. Ace). Your example of U+FDFD is bonus fun because it’s RTL. Most terminals don’t handle RTL at all well. (Terminals capable of proportional rendering such as Notepad++ and plain old Notepad are much more likely to treat it properly in my experience.)
  - JdeBP 9y ago
    Yes it does. I wrote the terminal program. I know what it does with fonts.
    - chrismorgan 9y ago
      I’m curious: how many columns is it occupying? From all that I can see, it should be a single column, with the font incapable of overriding that.
      - JdeBP 9y ago
        I can tell you that terminal emulator is finding the character in the fonts that I have configured it with. But it won't tell you the stuff about character widths that you want to know, I suspect. As I mentioned, my terminal emulator uses bitmap fonts. Whilst bitmap fonts do have a mechanism of specifying either single-width or double-width characters, it ignores that and displays everything in the same width, rescaling everything with some slight special-casing of block graphic and horizontally repeatable characters. So whilst by the looks of the amount of detail in the glyph on screen, U+FDFD is a double-width character in the font file; it occupies a single column. See the "Fonts" section of http://jdebp.eu./Softwares/nosh/guide/console-fb-realizer.html http://jdebp.eu./Softwares/nosh/guide/console-fb-realizer.ht... I am currently using a mixture of monospace bitmap fonts that I have obtained from various places: --vtfont-normal-i fonts/t0-16i-unicode.fnt --vtfont fonts/9x15.fnt --vtfont fonts/k16-1990.fnt --vtfont fonts/unifont-7.0.06.fnt So U+FDFD is somewhere in those. (-: