Open johnwcowan opened 3 years ago
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).
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.
Can we use smalltalk/squeak or other software to generate .strike fonts
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.
Attached is the info necessary to write AC format raster font files.
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.
We need a plan to generate fonts we can use. Not sure about the plan, but here are some desirable
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)
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)
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.
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.
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.
@pamoroso wrote:
Moritz Fürst is carrying out a remarkable project, restoring the typefaces of the Smalltalk-80 system. Medley may benefit from a similar effort but I'm not sure I understand what Moritz is doing in practice, and whether Medley's font data can be processed in a similar way.
to which I replied:
to which I replied:
Very interesting, thank you. The Medley "fonts" folder still need untangling. There are AltoFonts? Which we don't use? and fonts in .ac and .strike format. There are fonts from Star ... Medley was released with a set of fonts categorized so you didn't have to load too many floppies to get the fonts you wanted. PARC had a different organization of fonts because there all of the machines were networked and got fonts from the file servers.
Ideally we will be able to revive color (4 bit or 8 bit) enough to use anti-aliasing, although to get decent performance, many many hackers would advise, modify, or call down into lower levels of code, so system-wide changes are never as easy as they should be.
In the short term we could use modern fonts converted into a form that Interlisp can use. I started trying to load a BDF font parser (following John Cowan's advice), but I didn't get far without CLtL2 extensions, which were easy but time-consuming to make.
Using a smalltalk font converter to convert, say, X11 high res raster fonts ? Or just port the Interlisp font reader to XCL?
I've pulled out (almost) all the displayfont, .strike fonts from the CHM PARC Archive. Pointer is https://github.com/Interlisp/medley/issues/1408#issuecomment-1807005270
Is it possible that the pixels could be doubled or even tripled for high-resolution displays like Retina? I.e. so that one pixel in Medley is represented by 2x2 or 3x3 pixels on the actual screen. That could address some of those Retina woes.
The "VNC" option for Medley for windows-WSL does pixel scaling. I haven't found a solution to the do pixel scaling on a mac, so I'm running my MacBook built-in-screen at a low resolution.
The other reason for wanting better fonts is to extend our Unicode coverage.
some questions in response to #1875:
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 toolotf2bdf
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: