Re: Unicode in strings

On 5/31/2024 4:01 PM, Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

BGB wrote:
>

On 5/31/2024 12:21 PM, MitchAlsup1 wrote:

>
>

For the rest, say, one can have, say, a big buffer, with an array of
lines giving the location and size of the line's text in the buffer.

>
In a modern text editor, one can paste in {*.xls tables, *.jpg, *.gif,
..}
along with text from different fonts and different backgrounds on a per
character basis.
>

>

Errm, I think we call this a word processor, not a text editor.

>
So, you are calling AOL e-mail editor a word processor ???

 Yep.
 

And every modern forum editor (this one not included) word processors

 Yep.  They're certainly not text editors along the lines of vim or emacs.
 

My definition is, say:
   Text editor:
     Notepad, Notepad2, Notepad++, GEdit, SciTe, etc...
     VI, Emacs, Nano, etc, also count.
   Line Editor:
     Ed, Edlin, etc.
   Word Processor:
     Word, {Open/Libre}Office Writer, ...
     WordPad (sorta)
     ...
The editors in a lot of email programs or forums are HTML or Markdown WYSIWYG editors being used as an editor, but I would not consider them as text-editors when used in this context.
About as soon as one allows things like dynamic formatting, images, and other metadata that can't be expressed in bare ASCII or UTF-8 or similar, it is no longer a text editor as I see it.
The fuzzy line here is mostly emojis, and other effects that can be shoehorned though UTF-8 or similar. Because, seemingly, the era of Plain ASCII has mostly passed (though, it seems uncommon to use characters outside of ASCII or 8859-1 / 1252 range all that often; apart from random people sticking emojis in stuff).
Though, IIRC, if you try sticking emojis in a lot of text editors, they will often render in monochrome or in non-combined forms, rather than the full-color fully-graphical forms often expected in things like messaging or chat.
So, for example, the "family" emoji might just render as the man/woman/child emojis, with implicit zero-width-joiners.
Ironically, a set already exists in certain contexts in TestKern, mostly for the character ranges inherited from Unifont (which apparently mostly contains the original set of ~ 200 emojis developed by NTT DoCoMo and similar, which exist within the BMP).
Well, and with "quality" based on the automated algorithmic conversion from 16x16 1bpp bitmap graphics to SDF (sorta hit/miss).
A different (more customized) font is used for 1252-range, mostly because the Unifont graphics don't work well if scaled below 16x16, and my strategy for the "base" characters was to design things mostly around an 8x8 pixel cell.
Though, for the GUI text console and similar, I ended up going for 5x6 padded to 6x8, which doesn't really work much outside of ASCII (and generally a bitmap font is used for the 6x8 and 8x8 cases; falling back to trying to generate cells from the SDF if accessing characters outside the ASCII or 1252 set, with results that are generally unreadable).
The smallest is 3x5 padded to 4x6, but this is barely passable for ASCII and one needs to use their imagination for some of the character glyphs (so I ended up going with 5x6/6x8 instead). I suspect that 3x5 is the smallest size possible for semi-recognizable ASCII text.
But, one arguable merit to 3x5 is that it does allow fitting 80x25 text characters into 320x150 pixels, or 40x25 in 160x140 (roughly the same as the screen on the original GameBoy).