Re: [StrongED] Display of Tabs and Ctrls

[Fred Graute <fjgraute@xxxxxxxxx>]

In message <b277dcd052.martin@xxxxxxxxxxxxxxxx>
          Martin Bazley <martin.bazley@xxxxxxxxxxxxxxxx> wrote:

> The following bytes were arranged on 18 Sep 2012 by Fred Graute :
>
> > In message <56e159d052.martin@xxxxxxxxxxxxxxxx>
> >           Martin Bazley <martin.bazley@xxxxxxxxxxxxxxxx> wrote:
> >
> > > The following bytes were arranged on 16 Sep 2012 by Fred Graute :
> > >
> > > > The glyphs for non-alphabetic control codes are placed at the first 32
> > > > character positions in a font style. Currently we don't use these and
> > > > this is how things were before the CtrlTab style was introduced.
> > >
> > > That sounds even better than my plan!  If altering the existing bitmap
> > > fonts is on the table, then the CtrlTab style can be dispensed with
> > > entirely, just as I wanted all those posts ago.
> >
> > Well it's just a plan and I've already found a snag; I forgot to factor
> > in ASCII 127. Not a showstopper, I think, but it's going to be slightly
> > more complicated then I had hoped for.
>
> Well, you don't display ASCII 127 any more than you display 0-31, do
> you?  I thought that glyph was equally redundant.

True, ASCII 127 is not displayed itself but it does have representations
just like the other control codes. When displaying Ctrls a small hex
numbers 0-31 are simply mapped to themselves but we can't do that for
127. It has to be mapped elsewhere, probably to 256+ which complicates
things a bit.

> > > Of course, if it doesn't, then that paves the way for... Unicode
> > > StrongED!! :-)
> >
> > Sorry, not for a while as I know little about the intricacies of Unicode
> > so unless someone wants to provide me with 'Unicode for Dummies' it's
> > not likely to happen any time soon.
>
> Well, basically, step one is to design a really, really, really, really
> large number of bitmap characters, and then you can start thinking about
> the implications of not every character in the text occupying an equal
> amount of memory.  (A bit like the transition from fixed-width to
> outline fonts, I imagine, only much worse.)

Exactly, much worse. There are many, many locations where characters
are read from the text, all using LDRB. It would be impossible to change
all those locations to take the width of a character (in bytes) into
account.

The late Keith Hopper and I discussed this a couple of years ago and we
concluded that if StrongED were to support Unicode then the only two
viable ways are:

a) create a function to read characters and replace the LDRBs with calls
   to that function (similar for character writes).

b) use an encoding in which each character takes up the same number of
   bytes such as UCS-4 (UTF-32). In principle, each LDRB could then be
   replaced by an LDR.

Apart for the number of bytes per character there are a lot of other
problems to be solved, eg how does advanced search work with Unicode?

Cheers,
Fred.

-- 
StrongED developer
http://www.stronged.iconbar.com/

-- 
To unsubscribe send a mail to StrongED+unsubscribe@xxxxxxxxxxxxxx