Want better Medley fonts -- Calling all strike fonts!

[johnwcowan]

The Squeak version of Smalltalk (which uses a modified Smalltalk-80 image) is open source and still uses Xerox strike fonts, though it now supports OpenType as well. Here's the current list from the image itself:

Accuat, Accujen, Accula, Accumon, Accuny, Accusf, Accushi, Accuve, Atlanta, Bitmap DejaVu Sans, BitstreamVeraSans, BitstreamVeraSansMono, BitstreamVeraSerif, ComicSansMS, Darkmap DejaVu Sans.

In addition, X ships with a large number of bitmap fonts represented in BDF format. This format uses ASCII files to specify the metrics and the actual bits for each glyph (in hex). PCF format is a compiled version of BDF; it can be decompiled by the standard command-line tool pcf2bdf. The similar tool otf2bdf will convert OpenType fonts. Note that it will be necessary to chop these into 256-glyph chunks for our purposes.

Here are some BDF font sources, all freely available:

• Standard X Windows fonts
• IBM console fonts
• Search Google

[masinter]

this is good information, but what is missing for a good issue is a good statement of objectives (better rendering on high-res displays? Eliminate black blobs when TEditing Unicode text files?) and a plan of attack (or possible things to investigate or test before proceeding).

[johnwcowan]

Better rendering on high-res displays?

For that we'll need vector font support, which is out of scope for the moment.

Eliminate black blobs when TEditing Unicode text files?

For that we'll need (at least on my present view) a conversion from XCCS to Medley UCS-2. I'm filing another issue on that point, which will be more detailed.

The main benefit is just having more fonts: we can write TEdit files that don't have that MADE BY XEROX visual stamp on them.

[masinter]

Can we use smalltalk/squeak or other software to generate .strike fonts

• in higher resolution
• compatible with XCCS and fully fleshed out?
  I think three fonts (fixed-width, serif, sans-serif) and appropriate use of FONTCREATE coercion from Gacha, TimesRoman and Helvetica) would give is better rendering on high-resolution displays without Interlisp support of "vector" (bezier) fonts.
  Along the way, support for "bigger bitmaps" for the screen. To get fully "modern" looking fonts it is necessary to use sub-pixel rendering on a color display.

[nbriggs]

We have the documentation for the strike format, and there are plenty of font rasterizer applications that can read a modern font definition and generate the bitmaps -- some are even take plugins to let you add your own output format. Or we could translate from one of the generic interchange raster formats to strike.

[nbriggs]

Attached is the info necessary to write AC format raster font files.

PARC-AC-font-file-format.txt

[masinter]

It would be even better if we could have "on the fly" generation of high-resolution bitmap display fonts at first use for complete coverage. Then support FONTSET in more Interlisp applications. Doing font conversion in (Inter or Common) Lisp supported by a subr ... not as portable though.

[masinter]

We need a plan to generate fonts we can use. Not sure about the plan, but here are some desirable

• Prefer fonts that can render all of XCCS 2.0. If we extend XCCS to 3.0, that will be desirable too
• The display fonts need to be usable by medley: either converted to strike or add medley software to read
• "hardcopy" fonts (postscript) are important but less urgent than display fonts and can be delayed
• What we NEED and what would be nice are difficult to prioritize
  • what is a "first step" and what is "climbing a tree to the moon"?
• could we use: Squeek, X-fonts, emacs fonts? Lots of sources of technlogy
• Not important and might have difficulty bidi, ligatures

[nbriggs]

We could probably start from AFONT's \READACFONTFILE to produce a \READBDFFONTFILE for reading Adobe BDF (bitmap distribution format) fonts. That gives us access to a wide range of fonts, to me the tricky part is getting the mapping right for the XCCS character sets -- but that's a problem we're already working on. I think reading BDF is easier than coercing FontForge (or similar) into writing AC Strike files (even though it is supposedly extensible in that area using Python)

[masinter]

GNU Unifont looks ideal.
Could we make Lisp FONTCREATE just read the unicode-indexed font and (as necessary) do index mapping?

I want to move fonts into a separate repo and leave in medley only the fonts used (thus the attempt to TEdit all files in all repos we know of)

[nbriggs]

GNU Unifont has excellent coverage, but it's a pretty ugly font, and I wouldn't choose to use it for an everyday font in Medley. As I suggested above, if we can write \READBDFFONTFILE then we can read fonts such as GNU Unifont which are available in (or trivially convertible to) BDF format. Reading the BDF files does require doing the mapping from the named glyphs to the right position in the Medley font descriptor.

[johnwcowan]

Here's a classic Lisp font: Lisp Machine monowidth bitmap font

And here's a tool to convert it to BDF: PCF to BDF decompiler

With these tools plus otf2bdf above we can convert any standard font format to BDF, and then it's just a matter of either converting BDF to AC font format or providing a BDF font reader inside Medley.

Of course this doesn't change the fact that we still don't have complete conversion tables from Unicode to XCCS.

[masinter]

A frequent complaint from Medley users is that the text is too small on modern high-resolution / 4k / 'retinal' displays.
Interlisp-D has FONTSET which lets you choose larger fonts, but there aren't really resolution-specific fonts like in X.
My hope is that we can choose to replace the fonts we use now with some built for larger DPI. In Medley, I'dimagine we could "set/change resolution" by switching DISPLAYFONTDIRECTORIES to a set using the same font size numbers (so that GACHA 8 would look bigger on screen.

Xerox had hand-tuned (some of) its display fonts for legibility at small sizes on low-res displays.

I think we're better off picking fonts that were designed/tuned for bitmap use-- the ones that ship with Linux today would be best.