APL character set (and Mail/News/Web) 
Author Message
 APL character set (and Mail/News/Web)

Leigh Clayton writes, "Re: Special Symbols in pages? Do it 'right', if at all.

> Let me say up-front that I am not really a fan of this idea (because I believe
>that a year down the road more people will be using WWW, the UCS-2 mapping will
>be out, and the directions will be much clearer). It seems, however, that a
>bunch of you are rolling ahead regardless, so may I please suggest that you at
>least make some attempt to do this in a reasonably legitimate way?

I think, &#160 etc. is a reasonably legitimate way to send 8-bit character data.
Maybe in a couple of years straight 8-bit (the extended sendmail protocol,
RFC 1425 as opposed to 7-bit RFC 821) will become widely adopted.  But even
as of now, pretty much all modern computers support 8-bit characters.  So does
the Web, if not yet perfectly transparently.  I believe it should be possible,
with a few hours' work here and there, to implement an APL encoding/font to
work with (all) WWW browsers and with News (which seems fairly 8-bit transparent
to me).  None of us have the time, inclination, or ability to interface
APL<->ASCII translators (in C or otherwise) with the _dozens_ of popular
Mail/News/Web readers and senders on so many different platforms.

The bottom line, is that one has to be able to install a font, in order to
view APL glyphs (without resorting to large bitmaps).  If we take that as given,
what else is required?  Very little, I think.  Much of News is already 8-bit
transparent.  The Web is specified as 8-bit.  (I still don't know for sure
whether one can simply embed 8-bit characters in HTML pages.)  Perhaps in time
we will have legitimate, fully general solutions based on MIME or Unicode or
whatever.  But anything that is not "common denominator" will take a long time
to get adopted.  Here is another passage from the ISO 8859-1 FAQ:

  13.2.2 High-level protocols
    In the Good Old Days, messages were 7-bit US-ASCII only. When users
  wanted to transfer 8 bit data (binaries or compressed files, for
  example), it was their responsibility to translate them to a 7 bit
  form which could be sent.  At the other end, the recipient had to
  unpack the data using the same protocol.  The commonly used encoding
  mechanism used for this purpose is uuencode/uudecode.
    Today, a standard, MIME (MIME stands for Multi-purpose Internet Mail
  Extensions), exists which automatically packs and unpacks data as is
  required.  This standard can take advantage of different underlying
  protocol capabilities and automatically transform messages to
  guarantee delivery.  This standard can also be used to include
  multimedia data types in your mail messages.
    The MIME standard defines a mail transfer protocol which can handle
  different character sets and multimedia mail, independent of the
  network infrastructure.  This protocol should eventually solve
  problems with 7-bit mailers etc.  UNFORTUNATELY, NO MAIL TRANSFER
  STANDARD... [emphasis added]

MIME, or something like it, is part of the Web.  We should think about an
APL MIME protocol, but the big problem is how to get it incorporated into all
the Mail readers and Web browsers out there.  On the other hand, _all_ should
(eventually) support ISO Latin-1.  Passing APL off as ISO should do the
trick for now, legitimate or not.  Again to quote the FAQ:

  13.4 WWW (and other information servers)
    The WWW protocol can transfer 8 bit data without any problems and you
  can advertise ISO-8859-1 encoded data from your client.  THE DISPLAY
  OF DATA IS DEPENDENT UPON THE USER CLIENT.  xmosaic (freely available
  from the NCSA) which is available for most UNIX platforms uses an
  ISO-8859-1 compliant font by default and will display data correctly.
  [emphasis added]

I'm hoping that we will have a "solution" by APL95(NET), the first week of
June.  It would be nice to have a SIGAPL Web homepage, with a GIF of APL
glyphs (at least, if we ever solve _that_ problem), an on-line tutorial in
hypertext, and links to the Waterloo archive.  Of course ASCII versions can
be provided as well.  The Web is one way we can expose APL to a lot of people.
The sooner we get started the better.

> RFC 822 does provide a way to accomplish what you want (in fact, it will allow
>you to solve it fully, for mail and news, even on 7-bit systems, as long as you
>use news/mail software that supports it). What you must do is design a 7-bit
>transmission scheme around an accepted APL encoding (I might suggest the UCS-2
>APL encoding, but as long as everyone uses the same it doesn't matter all that
>much), and then write a customisable pair of C routines that can translate into
>and out of the 7-bit form. Lets call them 'apl2asc' and 'asc2apl'...

> To receive such a posting, you need:
> 1/ Mail/News/Web software that recognises the 'Encrypted:' keyword.
> 2/ A version of asc2apl that has been customised to produce APL text the way
>    you want to see it (this could include a keyword scheme if you want it).

Again, I'm somewhat dubious we can interface #1 with #2, for diverse platforms
and software.

> If the encoding is chosen to represent 32-127 codes as themselves, and also
>preserve line integrity, then even people without APL or decryption capability
>will be able to read the (ASCII part of the) text; this would then be quite
>close in appearance to the suggested new, 8-bit, encoding except that it would
>be possible for people with the proper software to detect and handle the APL

> RFC822 requires that the encryption be registered with the NIC; I don't know
>whether this is still required, but even if no-one does that this scheme is
>likely to work better, for more people, than re-using 8859-1 codepoints.

An encoding/encryption is needed, independent of the requirement to notify
Mail/News/Web readers of the fact that APL is being sent.  The simplest
encryption is the "null" one, 8-bit data or (if necessary) &#160 etc.
I don't really see a contradiction!  We can certainly put "Encrypted: APL" in
the header; presumably it will just be ignored...  I don't see this as
"re-using 8859-1 codepoints" (what do you mean?).  As for &#160 etc. being
human-unreadable, one can always include an ASCII rendition alongside the APL.

p.s. Re: APL GIFs
A thousand messages went on comp.infosystems.www.providers today (the second
day I read this group).  The GIF compression/decompression _patent_ is being
enforced by Unisys...

Wed, 25 Jun 1997 14:50:03 GMT  
 [ 1 post ] 

 Relevant Pages 

1. The APL Character Set and APL Usage

2. APL character set (PROPOSAL)

3. APL character set (ISO Latin-1 FAQ)

4. APL character set (Sun xterm solution) REPOST

5. APL character set

6. APL character set (Adrian Smith's proposed encoding)

7. APL character set

8. APL character set (Sun xterm solution)

9. The APL Character Set

10. APL Character set

11. apl character set under win nt 3.51 (stsc)

12. discussion on APL character set


Powered by phpBB® Forum Software