W3C home > Mailing lists > Public > www-font@w3.org > January to March 1996

Re: APL on the WEB

From: Martin J Duerst <mduerst@ifi.unizh.ch>
Date: Sun, 10 Mar 1996 17:59:30 +0100 (MET)
Message-Id: <9603101659.AA04494@www10.w3.org>
To: www-font@w3.org
Ray Cannon wrote:

>The computer language APL includes many non "LATIN-1" symbols in its
>"alphabet", making it very difficult to put into Web pages (and e-mail).
>(The standard APL joke is "It's all Greek to me." only makes any sense
>when you see a program written in APL.)

Hello Ray - I understand your problem; I have programmed APL around
18 years ago, and it was quite fun.

>We (in the APL community) are looking for solutions which will allow APL
>"scripts" to be sent in a web page across the internet in a simple
>What we need to be able to do is specify that a font (containing a
>"standard" APL symbol set) should be used for parts of the message. We
>are working on what the standard symbol set should contain (and in what
>position), but as yet, we do not known how we will convay where the APL
>font should be used within a web page.

The problem is not exactly a font problem, and should not be handled
as such. Some glyph resources (usually from a font) are of course necessary
to display the APL symbols, but just to change the font of a text is
not the correct way to specify that APL symbols should be used in a
Web page.

>(The proposed rules reguarding
>how to specify "languages" within HTML expicitly exclude computer

You seem to have read the internationalization (i18n) draft for
HTML (of which I am a coauthor), and indeed the LANG attribute
is also not the right solution. Both fonts (if they are specified via
style sheets or some non-standard tag such as <font>) and the
LANG attribute are not supposed to change the inherent identity
of a character in the HTML text. Something that comes along
as an &uuml;, for example (either in this representation or in
another) should not suddenly be turned into e.g. an APL nabla
just because of a special font or language specification.

The correct solution is to have the APL symbols as symbols of
their own, which are rendered as such independent of LANG or
font specifications, only depending on the availability of the
glyph resources at the client side (which might be helped by
the work this group is targeting on) and of course depending
on the availability of a browser that implements the specifications.

Now when reading the i18n draft, you will not have read
anything about APL, and thus not have got the impression
that there is a solution. But you will have noticed that
Unicode and ISO 10646 are mentionned over and over.
Now Unicode (in its verision 1.1) and ISO 10646, which
are code-by-code identical, contain a large number of
special APL symbols, besides Greek letters and such that
are also needed for APL.

There are basically two ways to encode these symbols:

One is to encode them as binary values, in a suitable
encoding. I think the only possibilities are Unicode/ISO
10646 or an encoding that is APL-specific. This encoding
has to be registered as a MIME "charset" parameter value.
The drawback with an APL-specific encoding would be
that it might be impossible to use lower-case Latin
letters, or German/French accents, and so on, on the
same page as APL, because this MIME parameter is
specific to HTTP and applies to a document as a whole.

The second solution is to include your symbols as numeric
character references, of the form &#9017; (APL FUNCTIONAL
SYMBOL QUAD DIVIDE, U+2339, if I remember correctly this
is the operator to solve linear equations or invert matrices).

Hope this helps.	Regards,	Martin.
Received on Sunday, 10 March 1996 11:59:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:37 UTC