APL Character Set and Browsers
Discussion

Contents | Previous | Next

Requirements

One contributor to the discussion (on comp.lang.apl - see acknowlegements) organized an assessment of the various methods around the following list of "customer" requirements:

• (a) Ability to display APL code in a web browser that looks reasonably close to what is seen in one's APL interpreter.
• (b) Ability to allow my readers to see the same APL code on their screens.
• (c) Ability to "grab" small pieces of code off my screen and paste it into my interpreter. (I do not want to re-key what I see on the screen)
• (d) Ability for my readers to do the same as (c).
• (e) Optional ability to copy larger pieces of code by the same method. (Note that other methods for workspace interchange already exist.)

Discussion

1. Use html tags <FONT FACE="apl font name"> xxx </FONT>

When it works, it's great. But it is not applicable to all browsers and systems, and there are reports of minor difficulties even with Windows and common browsers. And since most major APL interpreters use a different APL font - some symbols are in different positions, depending on the interpreter and the font - requirement (c) presents a major problem.

2. Use technique 1 but specify the font using a style sheet. (Note that FACE is not part of the strict HTML 4 specification, and is to be phased out eventually in favour of style sheets.)

Style sheets are a "good thing", but the APL font is still the problem.

3. Use a captured screen shot of the APL function code.

This satisfies (a) and (b) but not (c) and (d). Give up on considerations of [reducing] size if you use this method.

4. Avoid using the APL font in a Web page. Present the code in an ASCII transliteration. (Weigang's method is often cited.) This method can be combined with providing the software being presented in a separate file for download and use in a particular interpreter.

ASCII transliteration schemes work great for APL interchange, but they fail to meet the wishes of (a), (b), (c) and (d).

5. Avoid APL. Switch to J, K, A, etc. which avoid using non-ASCII symbols.

There are similarities, but these languages are not APL. Even these languages require special handling to present the code in HTML, because HTML uses tags with pointy brackets (less than and greater than) as the markup language. This means that a "<" and ">" have to be translated to "&lt;" and "&gt;" in HTML.

6. Use Unicode

Unicode seems to be the standard industry direction, not just for APL. To display APL characters on browsers and meet the requirements noted above seems to require that all major browsers and all major APL interpreters support Unicode and a Unicode font. Certainly as time goes by the present seems to be catching up to future promise - some APL interpreters are farther along the path than others. Paraphrasing one comment - "Unicode is nice in theory, but I don't yet see practice giving us [ APL users] what we need [now]".

7. Embed APL code in PDF ("Adobe") format file to be displayed in the browser. This requires the browser (software and human) to have the Adobe Reader (commonly and freely available).

Like screen shots, this does not meet requirements (c) and (d).

8. Use images (GIF, XBM)

This method looks useful but fails (c) and (d). It would be helpful for any such method to use an existing or agreed-upon naming convention (based perhaps on an existing APL-ASCII transliteration scheme) for the names of the image files.