Skip to content

Rmk225 Importing postcript fonts and other font improvements - #2745

Merged
rmkaplan merged 32 commits into
masterfrom
rmk225--Postcript-fonts-and-other-font-improvements
Sep 21, 2026
Merged

rmkaplan merged 32 commits into
masterfrom
rmk225--Postcript-fonts-and-other-font-improvements

Conversation

@rmkaplan

@rmkaplan rmkaplan commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

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.

@rmkaplan
rmkaplan marked this pull request as draft September 4, 2026 08:23
@rmkaplan

rmkaplan commented Sep 4, 2026

Copy link
Copy Markdown
Contributor Author

I forgot to include the new unscaled fonts, will do that tomorrow

@pamoroso

pamoroso commented Sep 4, 2026

Copy link
Copy Markdown
Member

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)
font-error

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

@rmkaplan

rmkaplan commented Sep 4, 2026 via email

Copy link
Copy Markdown
Contributor Author

@nbriggs

nbriggs commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

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 *POSTSCRIPT-EXTRA-CHARACTERS* to pull some specials in, but that variable is NOT defined in the file, or anywhere else I can find.

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.

@pamoroso

pamoroso commented Sep 5, 2026

Copy link
Copy Markdown
Member

At commit 7426263 I still get the font not found error when opening TEdit files.

@pamoroso

pamoroso commented Sep 5, 2026

Copy link
Copy Markdown
Member

Still font not found errors at commit 7c3179e.

@rmkaplan

rmkaplan commented Sep 5, 2026 via email

Copy link
Copy Markdown
Contributor Author

@pamoroso

pamoroso commented Sep 5, 2026

Copy link
Copy Markdown
Member

I get the error for all display fonts, for example when just opening DInfo or a TEdit file.

@pamoroso

pamoroso commented Sep 5, 2026

Copy link
Copy Markdown
Member

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))

@rmkaplan

rmkaplan commented Sep 5, 2026 via email

Copy link
Copy Markdown
Contributor Author

@rmkaplan

rmkaplan commented Sep 5, 2026 via email

Copy link
Copy Markdown
Contributor Author

@pamoroso

pamoroso commented Sep 5, 2026

Copy link
Copy Markdown
Member

The calls to FONTCREATE:

4_ (FONTCREATE '(CLASSIC 24 MRR 0 DISPLAY))
In ERROR:
FONT NOT FOUND
(CLASSIC 24 (MEDIUM REGULAR REGULAR) 0 DISPLAY)

5_: 
6_ (FONTCREATE '(CLASSIC 24 MRR 0 POSTSCRIPT))
{CLASSIC24-MRR/136,121314}

What do you mean by taking off the NIL?

@nbriggs

nbriggs commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

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.

@nbriggs

nbriggs commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

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.

@rmkaplan

rmkaplan commented Sep 5, 2026 via email

Copy link
Copy Markdown
Contributor Author

@pamoroso

pamoroso commented Sep 5, 2026

Copy link
Copy Markdown
Member

Got it, here are the calls to FONTCREATE with NIL taken off:

5_ (FONTCREATE '(CLASSIC 24 MRR 0 DISPLAY))
In ERROR:
FONT NOT FOUND
(CLASSIC 24 (MEDIUM REGULAR REGULAR) 0 DISPLAY)

6_: 
7_ (FONTCREATE '(CLASSIC 24 MRR 0 POSTSCRIPT))
{CLASSIC24-MRR/136,121314}

@rmkaplan

rmkaplan commented Sep 5, 2026 via email

Copy link
Copy Markdown
Contributor Author

@rmkaplan
rmkaplan marked this pull request as ready for review September 8, 2026 06:45
@rmkaplan

rmkaplan commented Sep 8, 2026

Copy link
Copy Markdown
Contributor Author

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?

@nbriggs

nbriggs commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

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.

@rmkaplan

rmkaplan commented Sep 9, 2026 via email

Copy link
Copy Markdown
Contributor Author

@rmkaplan

Copy link
Copy Markdown
Contributor Author

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.

@pamoroso

Copy link
Copy Markdown
Member

Still looking good at commit f1198be.

@pamoroso

Copy link
Copy Markdown
Member

Still looking good at commit 17c82bb.

@rmkaplan

Copy link
Copy Markdown
Contributor Author

@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.

@pamoroso

Copy link
Copy Markdown
Member

Still looking good at commit 0a93310.

@pamoroso

Copy link
Copy Markdown
Member

Nothing unusual to report at commit c009f10.

@rmkaplan

Copy link
Copy Markdown
Contributor Author

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.)

@nbriggs

nbriggs commented Sep 16, 2026

Copy link
Copy Markdown
Contributor

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.

@rmkaplan

rmkaplan commented Sep 16, 2026 via email

Copy link
Copy Markdown
Contributor Author

@pamoroso pamoroso left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

@rmkaplan
rmkaplan merged commit 3c8ee92 into master Sep 21, 2026
@rmkaplan
rmkaplan deleted the rmk225--Postcript-fonts-and-other-font-improvements branch September 21, 2026 19:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants