rmk122--Next round on fonts and MCCS

[rmkaplan]

Many files have changed as I have rearchitected the font interfaces, introduced the Medley font-format files, and worked to normalize to the MCCS encoding of internal data.

This PR is a draft that doesn't yet include the flood of files. For starters, it just has the documentation files that describe the strategy and new and changed features. It will be helpful to get some initial reactions so I can make adjustments before pushing everything. The code and font files will come later.

[pamoroso]

On Linux Mint 22.1 Cinnamon this PR builds with no issues and I didn't notice anything unusual. I tested DInfo and NoteCards and the fonts look fine so far.

[rmkaplan]

I have uploaded all of the medleyformat fonts, and removed the draft status.

I expect/hope the only issue is that filenames with underscores and carets might not look the same in Medley vs Unix. I would like to get this tested and merged, to avoid confusion with the changes to the imagefile/hardcopy interfaces.

[pamoroso]

On Linux Mint 22.1 Cinnamon I tested up to commit d01503c and I haven't noticed anything unusual. Names containing ← or ↑ in TEdit look as expected on Linux, i.e. with _ and ^.

[rmkaplan]

I found that PRETTYFILEINDEX had its own compensation for underscore/arrow, at least for Interpress. Removed it.

[rmkaplan]

@MattHeffron , LOADUPFULLFONTS on internal/loadups/LOADUP-FULL has some special code for building the postscript fontcache. I wonder whether this should be done when POSTSCRIPTSTREAM is loaded, as part of POSTSCRIPT.INIT.

[pamoroso]

When setting CHAT.FONT to Terminal 10 VTCHAT works as expected with respect to the function keys for underscore and circumfles, as well as deleting with Backspace and Del.

[rmkaplan]

If you set CHAT.FONT to, say, Classic 18 before you start (e.g. a fresh release sysout), it's still bad. You type the first character, it looks good. You type the next character on the same line, the first character reappears after a big run of white space, then the second character. And backspace is still garbage.

…

On Oct 12, 2025, at 11:17 AM, Nick Briggs ***@***.***> wrote: nbriggs left a comment (Interlisp/medley#2280) <#2280 (comment)> You shouldn't be using DSPFONT to change the chat font -- I think setting CHAT.FONT and restarting the CHAT is the only approved way to do it. DSPFONT is likely almost never the right thing to do unless you're working directly on an image stream (not some application's window) — Reply to this email directly, view it on GitHub <#2280 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJK3BESOAF4I4KGDQKT3XKLLBAVCNFSM6AAAAACF4OLO3CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGOJVGE4DANJQHE>. You are receiving this because you were mentioned.

[pamoroso]

However, pressing the _ and ^ keys makes the CHAT window flash with any font under DM2500 and VT100, not display the left and up arrow.

[rmkaplan]

However, pressing the _ and ^ keys makes the CHAT window flash with any font under DM2500 and VT100, not display the left and up arrow.

Yes, that's to be expected, given the new LLKEY assignments. Those keys transmit the MCCS uparrow and leftarrow codes (0,255, 0,254), which the shell doesn't recognize.

As per a previous note, it may be more intuitive, especially for new users, to have those transmit according their labels, as they used to. Users would then have to know that the function keys are available if they want to type those particular arrows (and that they do need to type F-10 when they want the left-arrow in a create expression (unless someone fixes DWIM).

[rmkaplan]

BTW, none of these Chat/font/backspace problems are new: same behavior in the Venue sysout. Also in the Venue sysout, Tedit mode doesn't work by clicking the TeditMode button in the Chat menu. Something probably needed to be done earlier to set up the textstream.

[nbriggs]

The CHAT.FONT must be a monospace font. It's never going to work with Classic. The underlying shell may be using what it knows about the terminal emulator to move the cursor before erasing the character, and it can directly address each character cell on the (typically 24 x 80 character) display. If the emulator didn't put the characters in that grid you're going to get garbage.

[rmkaplan]

OK, then it's only Gacha and Terminal up to size 12 that should work, and they (mostly) do. In playing around, sometimes I still do see the case where the already echoed first-typed character is repeated after some extra white space, before the second typed character appears. Interestingly, the unwanted black pixel when backspacing over an underscore only appears for Terminal 12. Terminal 8 and 10 are OK, as are all the Gacha sizes. Maybe something is wrong with its underscore bitmap?

…

On Oct 12, 2025, at 2:34 PM, Nick Briggs ***@***.***> wrote: nbriggs left a comment (Interlisp/medley#2280) <#2280 (comment)> The CHAT.FONT must be a monospace font. It's never going to work with Classic. The underlying shell may be using what it knows about the terminal emulator to move the cursor before erasing the character, and it can directly address each character cell on the (typically 24 x 80 character) display. If the emulator didn't put the characters in that grid you're going to get garbage. — Reply to this email directly, view it on GitHub <#2280 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJMWUDFTORZFFMO7EVT3XLCP5AVCNFSM6AAAAACF4OLO3CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGOJVGM4DGMJZGA>. You are receiving this because you were mentioned.

[nbriggs]

I'd expect TITAN, LETTERGOTHIC, and BOLDPS to work - they're printwheel fonts and I think they're monospace. TITANLEGAL perhaps too. But the character mappings in those may not really be XCCS.

[nbriggs]

Actually, they do look like XCCS encoding at least in FontSample for character set C0. They really don't work well in a CHAT window though, with what looks like mis-mapped characters.

[rmkaplan]

I wrote a predicate to test for monopitchness. The legacy (displayfonts/c0) Terminal 10 has a glitch in the 8-bit region, otherwise Gacha and Terminal are OK. Titan seems to be OK, Boldps seems to have a lot of variation. Of course, when slugs (missing characters) get filled in from other fonts to suppress black boxes (e.g. Terminal gets characters from Modern or Classic) there are no guarantees. But presumably that doesn't happen in the 7-bit Ascii range.

…

On Oct 12, 2025, at 6:39 PM, Nick Briggs ***@***.***> wrote: nbriggs left a comment (Interlisp/medley#2280) <#2280 (comment)> I'd expect TITAN, LETTERGOTHIC, and BOLDPS to work - they're printwheel fonts and I think they're monospace. TITANLEGAL perhaps too. But the character mappings in those may not really be XCCS. — Reply to this email directly, view it on GitHub <#2280 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJMDDG7KHJ6D5NQCXOD3XL7DLAVCNFSM6AAAAACF4OLO3CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGOJVGYYDSMRSGI>. You are receiving this because you were mentioned.

[pamoroso]

Part of issue #1157 is that the Calendar application displays some black boxes in the message editor window, so I tried to reproduce the issue on this branch where MCCS is supposed to take care of the boxes.

Now I no longer get black boxes in the message editor but the window content still looks off. And the error is different:

END-OF-FILE

In \EOSERROR:
End of file #<IO Tedit Stream/167, 64700>

[fghalasz]

Running on this PR branch, the following files in docs/medley-irm fail when trying to hardcopy to PDf file:
14-ERRORS.TEDIT
16-SEDIT.TEDIT
25-USERIO-PACKAGES.TEDIT.

All fail with Invalid argument: (NIL NIL REGULAR) inside \FONTFACE underneath POSTSCRIPT.FONTCREATE where the FONTSPEC argument is (SYMBOL 1 (BOLD REGULAR REGULAR) 0 POSTSCRIPT)

[rmkaplan]

@pamoroso The Calendar bug is independent of the fonts. Calendar fills in its template from a string, using OPENSTRINGSTREAM to first convert the string to a stream before giving it to Tedit (because we changed Tedit a long time ago to treat strings as file names). OPENSTRINGSTREAM produces a fat (2-byte) stream even if the characters are only in charset 0. Unlike thin files and thin streams, fat-stream pieces are not binnable at the stream level, so the subr falls out to the textbin code. And there appears to be an extra SUB1 in that code. The effect is that you were seeing every other character.

Removing that SUB1 makes it work, but I want to do some more testing to see whether any other piece types somehow depended on that. And I won't install this fix in the font PR, the code in the TEDIT-STREAM file may already have things that depend on the next hardcopy/imagefile changes that are waiting on the sidelines.

[rmkaplan]

@fghalasz , I updated POSTSCRIPTSTREAM (variables were set in the wrong order). Those 3 files now work for me, but I did see a message flash by in the USERIO hardcopy saying that page 19 was complete full of headings. The page didn't look odd to me, but I didn't investigate.

[pamoroso]

I tested up to commit 016a716 and I have nothing unusual to report. I'm still using this branch as my daily driver.

[nbriggs]

Could you make it MONOSPACEFONTP rather than mixing "fixed pitch" (from typewriter terminology) and "monospace" (more modern font terminology) in the name?

[rmkaplan]

OK

…

On Oct 17, 2025, at 4:53 PM, Nick Briggs ***@***.***> wrote: @nbriggs requested changes on this pull request. Could you make it MONOSPACEFONTP rather than mixing "fixed pitch" (from typewriter terminology) and "monospace" (more modern font terminology) in the name? — Reply to this email directly, view it on GitHub <#2280 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJJMJA5RHV4LYEK7JJL3YF6Q5AVCNFSM6AAAAACF4OLO3CVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTGNJSGM4TOMRVGQ>. You are receiving this because you were mentioned.

[pamoroso]

I updated to commit c727386, still looking good.

[nbriggs]

The requested change looks fine. Go ahead and merge.

[rmkaplan]

Forgot to mention: this PR addresses issues raised in #2178 #2135 #2124 #2120 #2040 #2025 #1971 #1854 #1403

[pamoroso]

Can all the issues addressed by this PR be closed? Any to leave open?

[rmkaplan]

@pamoroso , I suspect that all of those issues can be closed, but I think they probably need to be scanned to make sure that there aren't some additional comments that still need to be addressed.