Rmk225 Importing postcript fonts and other font improvements - #2745
Conversation
|
I forgot to include the new unscaled fonts, will do that tomorrow |
|
I have to upload the new fonts
… On Sep 4, 2026, at 1:38 AM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2745)
<#2745 (comment)>
On Linux Mint 22.1 Cinnamon, when opening lispusers/EQUATIONEXAMPLES.TEDIT I get the error:
INTERLISP-ERROR
In ERROR:
FONT NOT FOUND
(MODERN 6 (MEDIUM REGULAR REGULAR) 0 DISPLAY)
Image: font-error (view on web) <https://github.com/user-attachments/assets/a7ce1a0d-b38f-47be-bbea-4e7faf78d118>
The backtrace:
6_: BTV
MESS1 "FONT NOT FOUND"
MESS2 (MODERN 6 (MEDIUM REGULAR REGULAR) 0 DISPLAY)
NOBREAK NIL
ERROR
FONTCREATE
FILE
#<Input Stream on {MEDLEY}<lispusers>EQUATIONEXAMPLES.TEDIT;1/130,31700>
TEXTOBJ {TEXTOBJ}#121,141600
LOOKS {CL101/4954:Gacha10}
FILEPOS 11122
LOOKSLEN 47
FONT NIL
NAME MODERN
SIZE 6
SUPER 0
STYLESTR NIL
BOLD NIL
ITALIC NIL
BITS 0
PROPS NIL
PROPS ((COLOR . BLACK))
\TEDIT.GET.SINGLE.CHARLOOKS
FILE
#<Input Stream on {MEDLEY}<lispusers>EQUATIONEXAMPLES.TEDIT;1/130,31700>
TEXTOBJ {TEXTOBJ}#121,141600
I 7
\TEDIT.GET.CHARLOOKS.LIST
TEXT
#<Input Stream on {MEDLEY}<lispusers>EQUATIONEXAMPLES.TEDIT;1/130,31700>
TSTREAM #<IO Tedit Stream/130,31000>
PCCOUNT 187
CURTEXTBYTE# 0
END 13285
PCNO 1
TEXTOBJ {TEXTOBJ}#121,141600
ORIGBYTE# 0
PC NIL
BYTELEN 0
PREVPC {PIECE}#121,135710
FIRSTPC {PIECE}#121,135710
PARALOOKSMAP {ARRAYP}#137,63006
CHARLOOKSMAP NIL
DEFAULTCHARLOOKS {CL101/5062:Gacha10}
OLDPARALOOKS {PL81/49096:LE-0-0}
\TEDIT.GET.PIECES3
TEXT
#<Input Stream on {MEDLEY}<lispusers>EQUATIONEXAMPLES.TEDIT;1/130,31700>
TSTREAM #<IO Tedit Stream/130,31000>
START 0
END 13285
PROPS NIL
TEXTOBJ {TEXTOBJ}#121,141600
TRAILER (8863 52 3 187 1813772093 (&))
PCCOUNT 187
IDATE NIL
PROPS NIL
PC NIL
\TEDIT.GET.FORMATTED.FILE
SI::*CLEANUP-FORMS* SI::RESETUNWIND
TEXTOBJ {TEXTOBJ}#121,141600
PWINDOW NIL
READONLY NIL
SI::*UNWIND-PROTECT*
TEXT
#<Input Stream on {MEDLEY}<lispusers>EQUATIONEXAMPLES.TEDIT;1/130,31700>
TSTREAM #<IO Tedit Stream/130,31000>
START 0
END 13285
PROPS NIL
LISPXHIST ((&) (4 "" . "_ ") "<not yet evaluated>"
NIL)
SI::*RESETFORMS* NIL
RESETSTATE NIL
\TEDIT.OPENTEXTSTREAM.PIECES
SI::*CLEANUP-FORMS* SI::RESETUNWIND
TSTREAM #<IO Tedit Stream/130,31000>
TEXTOBJ {TEXTOBJ}#121,141600
TEDIT.GET.FINISHEDFORMS NIL
PRIMPANE NIL
START NIL
SI::*UNWIND-PROTECT*
TEXT
#<Input Stream on {MEDLEY}<lispusers>EQUATIONEXAMPLES.TEDIT;1/130,31700>
WINDOW Tedit
START/PROPS NIL
END NIL
PROPS NIL
LISPXHIST ((&) (4 "" . "_ ") "<not yet evaluated>"
NIL)
SI::*RESETFORMS* NIL
RESETSTATE NIL
OPENTEXTSTREAM
TEXT {MEDLEY}lispusers>EQUATIONEXAMPLES.TEDIT
WINDOW NIL
DONTSPAWN NIL
PROPS NIL
TSTREAM NIL
PROC NIL
TEDIT
TEXT {MEDLEY}lispusers>EQUATIONEXAMPLES.TEDIT
WINDOW NIL
DONTSPAWN NIL
PROPS NIL
TEDIT
*FORM* (TEDIT (QUOTE
{MEDLEY}lispusers>EQUATIONEXAMPLES.TEDIT))
*ARGVAL* NIL
*TAIL* NIL
*FN* TEDIT
\EVALFORM
FAULTEVAL
*FORM* (UNDOABLY (TEDIT &))
\EVALFORM
\INTERNAL NIL
EVAL
EVAL-INPUT
RETRYFLAG NIL
HELPCLOCK 911
DO-EVENT
SI::*DUMMY-FOR-CATCH* T
SI::*CATCH-RETURN-FROM* (&)
LISPXHIST ((&) (4 "" . "_ ") "<not yet evaluated>"
NIL)
HELPCLOCK 0
XCL::EXECA0001A0002
*CURRENT-EVENT* ((&) (4 "" . "_ ")
"<not yet evaluated>" NIL)
SI::NLSETQ-VALUE NIL
*PROCEED-CASES* (&)
SI::*NLSETQFLAG* NIL
XCL::EXECA0001
\PROGV
XCL::TOP-LEVEL-P T
XCL::WINDOW {WINDOW}#161,156664
XCL::TITLE-SUPPLIED NIL
XCL::TITLE NIL
*THIS-EXEC-COMMANDS* (#<Hash-Table @ 165,74632>)
XCL::ENVIRONMENT NIL
XCL::PROMPT NIL
XCL::FN EVAL-INPUT
XCL::PROFILE "XCL"
*EXEC-ID* ""
XCL::PROFILE-CACHE (XCL::*PROFILE-NAME* "IL"
XCL:*EVAL-FUNCTION* EVAL *PACKAGE* #<Package INTERLISP>
*READTABLE* #<ReadTable INTERLISP/172,64714>
XCL:*EXEC-PROMPT* "_ " --)
EXEC
\PROC.REPEATEDLYEVALQT
*FORM* (\PROC.REPEATEDLYEVALQT)
*ARGVAL* NIL
*TAIL* NIL
*FN* \PROC.REPEATEDLYEVALQT
\EVALFORM
%#FORM# (\PROC.REPEATEDLYEVALQT)
*CURRENT-PROCESS* #<Process EXEC/172,22204>
HELPFLAG BREAK!
\CURRENTDISPLAYLINE 0
\#DISPLAYLINES 22
\LINEBUF.OFD #<IO Linebuffer Stream/171,141000>
*READTABLE* #<ReadTable INTERLISP/172,64714>
\PRIMTERMTABLE {TERMTABLEP}#172,57740
\PRIMTERMSA {CHARTABLE}#172,60000
TtyDisplayStream #<Output Display Stream/137,106100>
SI::*RESETFORMS* NIL
\INTERRUPTABLE T
\TTYWINDOW NIL
READBUF NIL
\TERM.OFD #<Output Display Stream/166,120200>
*STANDARD-OUTPUT* #<Output Display Stream/166,120200>
*STANDARD-INPUT* #<IO Linebuffer Stream/171,141000>
\MAKE.PROCESS0
T
—
Reply to this email directly, view it on GitHub <#2745?email_source=notifications&email_token=AQSTUJIKSSP2JJZYIIZQWJL5NJ5P7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJTG44TENZZGIYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5537927920>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJKHAKDTGVJBQFBM5NL5NJ5P7AVCNFSNUABFKJSXA33TNF2G64TZHMZDQMJVGE4TSNRUHNEXG43VMU5TKMZUGU4TGMBVHEZ2C5QC>.
You are receiving this because you authored the thread.
|
|
It might be a good idea, since you're converting to medleyfont format for Postscript fonts, and you're now converting to/from MCCS, to take a new look at "CONVERT-AFM-FILES" in POSTSCRIPTSTREAM. It ignores many characters that are present in the font that are not part of the standard encoding. There's You can find the Adobe Font Metric specs online pretty easily, and there are quite a few versions of the .AFM files out there (beware, while they may say version 2 of the AFM file format specification, there seem to be many versions of the metrics themselves -- e.g., Helvetica.afm has font versions 001.002 and 001.006 and they're quite different). I have no idea what versions of the fonts the existing .PSCFONT files were created from -- they don't seem to maintain references back to the AFM source they were created from -- and neither of the above 2 versions of Helvetica.afm recreate the existing PSCFONT file for Helvetica. |
|
At commit 7426263 I still get the font not found error when opening TEdit files. |
|
Still font not found errors at commit 7c3179e. |
|
For a particular font? From a top-level call to FONTCREATE, or embedded somewhere?
Is it just postscript/pdf? Are display fonts OK?
… On Sep 5, 2026, at 1:19 AM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2745)
<#2745 (comment)>
Still font not found errors at commit 7c3179e <7c3179e>.
—
Reply to this email directly, view it on GitHub <#2745?email_source=notifications&email_token=AQSTUJLOBYQXEA4TPK7YA2D5NPEBNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJVGA2TIMZSGM22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5550543235>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJJ6QBEDSARELJOUDYL5NPEBNAVCNFSNUABFKJSXA33TNF2G64TZHMZDQMJVGE4TSNRUHNEXG43VMU5TKMZUGU4TGMBVHEZ2C5QC>.
You are receiving this because you authored the thread.
|
|
I get the error for all display fonts, for example when just opening DInfo or a TEdit file. |
|
For context this is the font related code of my greetfile: |
|
Is there a difference between
(FONTCREATE '(CLASSIC 24 MRR 0 DISPLAY))
and
(FONTCREATE '(CLASSIC 24 MRR 0 POSTSCRIPT))
… On Sep 5, 2026, at 1:35 AM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2745)
<#2745 (comment)>
I get the error for all display fonts, for example when just opening DInfo or a TEdit file.
—
Reply to this email directly, view it on GitHub <#2745?email_source=notifications&email_token=AQSTUJM7KQRU53S6MASIOTD5NPF4LA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJVGA3DEMJQGA32M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5550621007>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJKHG2R5GQP7QG3F4XD5NPF4LAVCNFSNUABFKJSXA33TNF2G64TZHMZDQMJVGE4TSNRUHNEXG43VMU5TKMZUGU4TGMBVHEZ2C5QC>.
You are receiving this because you authored the thread.
|
|
What if you take off the NIL ?
… On Sep 5, 2026, at 1:37 AM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2745)
<#2745 (comment)>
For context this is the font related code of my greetfile:
(SETQ DISPLAYFONTDIRECTORIES (APPEND '(NIL "{DSK}<home>paolo>il>fonts>Commodore>"
"{DSK}<home>paolo>il>fonts>ComicSans>"
"{DSK}<home>paolo>il>fonts>")
DISPLAYFONTDIRECTORIES))
—
Reply to this email directly, view it on GitHub <#2745?email_source=notifications&email_token=AQSTUJJZ5SBXZTZYOJESXJD5NPGDXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJVGA3DGMBXGY32M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5550630767>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJKOEX6XEJLNUBFNJCT5NPGDXAVCNFSNUABFKJSXA33TNF2G64TZHMZDQMJVGE4TSNRUHNEXG43VMU5TKMZUGU4TGMBVHEZ2C5QC>.
You are receiving this because you authored the thread.
|
|
The calls to What do you mean by taking off the |
Ron is referring to your DISPLAYFONTDIRECTORIES -- He's suggesting that you remove the NIL that you're putting on the front of DISPLAYFONTDIRECTORIES and see if that's causing the font file search failure. |
|
I just noticed in the IRM, relevant to the way Postscript fonts are stored, this note:
|
|
Yes, the code may be stumbling over NIL in this context, which I will look at if that's the problem.
But, what directory(ies) do you expect it to search over, when it sees NIL?
… On Sep 5, 2026, at 8:19 AM, Nick Briggs ***@***.***> wrote:
nbriggs
left a comment
(Interlisp/medley#2745)
<#2745 (comment)>
What do you mean by taking off the NIL
Ron is referring to your DISPLAYFONTDIRECTORIES --
(SETQ DISPLAYFONTDIRECTORIES (APPEND '(NIL "{DSK}<home>paolo>il>fonts>Commodore>"
"{DSK}<home>paolo>il>fonts>ComicSans>"
"{DSK}<home>paolo>il>fonts>")
DISPLAYFONTDIRECTORIES))
He's suggesting that you remove the NIL that you're putting on the front of DISPLAYFONTDIRECTORIES and see if that's causing the font file search failure.
—
Reply to this email directly, view it on GitHub <#2745?email_source=notifications&email_token=AQSTUJO2IL4JSPABXDJY6I35NQVGNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJVGI3TMNRQHAZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5552766083>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJOX4REIEURYEBG7TW35NQVGNAVCNFSNUABFKJSXA33TNF2G64TZHMZDQMJVGE4TSNRUHNEXG43VMU5TKMZUGU4TGMBVHEZ2C5QC>.
You are receiving this because you authored the thread.
|
|
Got it, here are the calls to |
|
On this revision I have made the change that the unscaled sources for scaling appear in the directory (and fontdescriptor) as size 0, not 1 (or the smallest as described here). This now only applies to postscript/pdf, since we no longer support press, but the same logic would apply to scale fonts for other devices.
… On Sep 5, 2026, at 8:21 AM, Nick Briggs ***@***.***> wrote:
nbriggs
left a comment
(Interlisp/medley#2745)
<#2745 (comment)>
I just noticed in the IRM, relevant to the way Postscript fonts are stored, this note:
Warning: One must be careful when using the function FONTSAVAILABLE to determine what Press font files are available. For Press font families/faces, the font widths for different sizes are consistently scaled versions of the smallest font in the family/face. Therefore, instead of storing data about all of the sizes in the FONTS.WIDTHS file, only the widths for the font of SIZE=1 are stored, and the other widths are calculated by scaling these widths up. This is signified in the FONTS.WIDTHS file by a font with SIZE=0. Therefore, if FONTSAVAILABLE is called with CHECKFILESTOO?=T, and it finds such a "relative" font, it returns a font spec list with size of 0. For example,
_(FONTSAVAILABLE 'GACHA '* '* 0 'PRESS T)
((GACHA 0 (BOLD ITALIC REGULAR) 0 PRESS)
(GACHA 0 (BOLD REGULAR REGULAR) 0 PRESS)
(GACHA 0 (MEDIUM ITALIC REGULAR) 0 PRESS)
(GACHA 0 (MEDIUM REGULAR REGULAR) 0 PRESS))
This indicates that Press files can be created with GACHA files of any size with faces BIR, BRR, MIR, and MRR. Of course, this doesn't guarantee that these fonts are available in all sizes on your printer.
—
Reply to this email directly, view it on GitHub <#2745?email_source=notifications&email_token=AQSTUJKV5WCQLHC7U3OGU635NQVRFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJVGI3TQMZQGY4KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5552783068>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJIBUPBZNZXHDSCXRV35NQVRFAVCNFSNUABFKJSXA33TNF2G64TZHMZDQMJVGE4TSNRUHNEXG43VMU5TKMZUGU4TGMBVHEZ2C5QC>.
You are receiving this because you authored the thread.
|
|
With respect to NS/Interpress printing on Dodo, apart from the slug issue, we could get better text spacing if we made the Interpress Medley fonts not from the .WD files but from the widths of the postscript fonts that Dodo maps the XCCS characters into. But is there any reason to spend more time on this? It's been good way of validating that we can still get Interpress to work, and a good test of the new font interfaces, but do we really care about the output when we can go straight to pdf/postscript? |
|
The Postscript fonts that Dodo maps the Interpress fonts into are fonts provided by Xerox which should match the widths of Classic and Modern, assuming you have those fonts installed in the resources directory so that they get used. I'd also point out that WE don't have correct widths for the Postscript fonts that we map onto (the AFM files we converted to PSCFONT files long ago are older versions of the fonts) and not only that, but if you use Ghostscript to convert from PS to PDF you don't even have the real Adobe fonts that we think we have the widths for-- Ghostscript doesn't ship with even the base 14 fonts, let alone the standard 35 (37?) Type 1 fonts that printers used to ship with. Regular Adobe Postscript generating apps no longer (2023) support type 1 fonts - they've switched to TTF (TrueType) and/or OTF (OpenType) fonts. |
|
If we don't have the correct widths for the PS fonts, and if pd2df uses a different set of fonts, isn't it surprising that our pdf files look as good as they do?
… On Sep 8, 2026, at 4:00 PM, Nick Briggs ***@***.***> wrote:
nbriggs
left a comment
(Interlisp/medley#2745)
<#2745 (comment)>
The Postscript fonts that Dodo maps the Interpress fonts into are fonts provided by Xerox which should match the widths of Classic and Modern, assuming you have those fonts installed in the resources directory so that they get used.
I'd also point out that WE don't have correct widths for the Postscript fonts that we map onto (the AFM files we converted to PSCFONT files long ago are older versions of the fonts) and not only that, but if you use Ghostscript to convert from PS to PDF you don't even have the real Adobe fonts that we think we have the widths for-- Ghostscript doesn't ship with even the base 14 fonts, let alone the standard 35 (37?) Type 1 fonts that printers used to ship with. Regular Adobe Postscript generating apps no longer (2023) support type 1 fonts - they've switched to TTF (TrueType) and/or OTF (OpenType) fonts.
—
Reply to this email directly, view it on GitHub <#2745?email_source=notifications&email_token=AQSTUJMGGWJZU44ADQGZPJD5OCFPZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJZGMYDGOBVGMY2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5593038531>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJKRJHICEINDRKXM2ID5OCFPZAVCNFSNUABFKJSXA33TNF2G64TZHMZDQMJVGE4TSNRUHNEXG43VMU5TKMZUGU4TGMBVHEZ2C5QC>.
You are receiving this because you were mentioned.
|
|
This is now a very big update, since it includes new versions of all the medley display, postscript, and interpress fonts, in addition to the code changes. These fonts now systematically record the slug-status of every character, with some generic functions to set things up and interpret that status. The postscript outcharfn now puts up a black box for the slug, the Interpress outcharfn still needs some work. Maybe it should also do what postscript does. |
|
Still looking good at commit f1198be. |
|
Still looking good at commit 17c82bb. |
|
@MattHeffron raised the question whether the justification would be off in postscript/pdf streams for lines that contain slug characters. I did the test, the justification still works, no problem. |
|
Still looking good at commit 0a93310. |
|
Nothing unusual to report at commit c009f10. |
|
Interpress wasn't showing slugs. Without getting into BLTSHADE or choosing a specific character for the slug, I put in a hack that I think should just space over the intended width of the slug, showing white space. @pamoroso , can you see what Dodo shows if you recreate the Tedit file that has a slug (e.g. charcode 1000) between an A and a B? I think the B was right next to the A before, I hope now it will be spaced over a bit. (To get the 1000, do (PRINTCCODE 1000 (TEXTSTREAM(WHICHW))) with the mouse over the Tedit window.) |
|
The printer puts in the slugs if the character is not present in its loaded fonts - you probably shouldn't second-guess what it's capable of doing. That's how the fake font sampler works -- it's creating Interpress for a font whose name was changed from an existing font, but all the characters imaged get passed through even though we don't have the widths for the characters. |
|
Do we know the width of the slug that the printer puts in? That's what any formatter in Lisp needs to know?
… On Sep 15, 2026, at 5:33 PM, Nick Briggs ***@***.***> wrote:
nbriggs
left a comment
(Interlisp/medley#2745)
<#2745 (comment)>
The printer puts in the slugs if the character is not present in its loaded fonts - you probably shouldn't second-guess what it's capable of doing. That's how the fake font sampler works -- it's creating Interpress for a font whose name was changed from an existing font, but all the characters imaged get passed through even though we don't have the widths for the characters.
—
Reply to this email directly, view it on GitHub <#2745?email_source=notifications&email_token=AQSTUJNYKWAPZP2NJY3IE2D5PHNW5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRZGAZDEMZUGQZKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5690223442>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJPQIWTLACRPUGGBJZD5PHNW5AVCNFSNUABFKJSXA33TNF2G64TZHMZDQMJVGE4TSNRUHNEXG43VMU5TKMZUGU4TGMBVHEZ2C5QC>.
You are receiving this because you were mentioned.
|

This was instigated by the mismatch in FONTCREATE and FONTSAVAILABLE behavior for postscript and pdf fonts #2741 . That led to a refactoring of the way that postscript pscfonts are imported into Medley, and further work on when and where coercions (including the double coercion of pdf fonts) and scaling take place.
The fontspec-to-filename mismatches are now driven by templates that are associated with the various font-formats. Medleyfonts don't have separate files for separate character sets, so their template is uniformly just (FAMILY SIZE - FACE). Legacy fonts include character sets in different ways, for example (c CHARSET > FAMILY SIZE - FACE -C CHARSET). The appropriate templates have been added to the display CHARSETFNS for AC and STRIKE files. A number of spec-to-file functions have been removed.
With respect to postscript, the unscaled postscript PSCFONTs were created from Adobe metrics some time int he distant past (@MattHeffron ). Previously, they were converted to fontdescriptors and scaled as needed. On this pass the conversion to fontdescriptors is done separately and offline, in the IMPORTFONTS framework, and the resulting unscaled fonts are saved as medleyfont files. They are read, scaled, and cached as needed by FONTCREATE.
This PR also includes some changes to get rid of some funky or confusing names, e.g. the fields \SFAscent, \SFDescent, \SFHeight of the fontdescriptor have been renamed FONTASCENT FONTDESCENT FONTHEIGHT, followiing the pattern of most of the other field names. The other names are still there as synonyms--there are a few files that I haven't yet updated.
There were quite a few tangles that had to be worked out, particularly in the logic of font coercions. So I'm marking this as draft until it gets exercised in a broader way.