Interlisp
Create "complete" MEDLEYDISPLAYFONT files from Noto
Create a set of complete MEDLEYDISPLAYFONT files from Noto to parallel those in the upcoming HTMLSTREAM module.
I'm looking at @hjellinek 's Web Font project to see if I can use that process to (help) get "complete" fonts from ttf to BDF, and then to MEDLEYDISPLAYFONT.
These comments are copied from PR #2360 :
From Matt:
I tried this (PR 2630), converting various Noto Sans, Noto Sans Mono, and Noto Serif ttf fonts to bdf and then to original-style DISPLAYFONT files.
I didn't write .MEDLEYDISPLAYFONT files. (@rmkaplan what should I change in the FONTDESCRIPTOR objects I create to write better MEDLEYFONT format files vs. pre-MEDLEYFONT FONTDESCRIPTOR.)
I'm still analyzing just how much coverage of the MCCS glyphs are covered in the Regular, Bold, Bold Italic, and Italic styles, and would they be close to full fonts.
E.g., Noto Sans Mono has only Regular and Bold, not Italic nor Bold Italic.
@hjellinek Did you determine a good set of google fonts to get good coverage of the MCCS glyphs? Anyone else
From @hjellinek
Yes, take a look at the "font stacks" (that's Google/CSS terminology) that I defined in my WebFontMetrics project. The Java source file Main.java lines 56-70 might help. I'm happy to explain any of it. The companion FontCoverage tool examines font stacks for characters present in the code but missing from a font stack.
From Matt:
@hjellinek (I have no experience with java...) I've downloaded the WebFontMetrics project from github (as the .zip, and unpacked it).
I'm trying to follow the README.md, so:
- I installed java (
sudo apt install openjdk-21-jre-headless), - connected to the WebFontMetrics directory,
- created the destination directory (beside the WebFontMetrics directory) and
- gave the java command as in the README.md (
java -cp WebFontMetrics.main org.interlisp.Main -d ../wfm)
I get the error:
Error: Could not find or load main class org.interlisp.Main
Caused by: java.lang.ClassNotFoundException: org.interlisp.Main
What's wrong?
From @hjellinek
Java is a compiled language like C, so you need to compile (build) the application before running it. I omitted build instructions because I assumed that was understood. But I will document it since, even if you're cognizant of the fact that you have to build the app before running it, there are multiple ways someone might try to do that.
If you pull the project now you'll find build instructions in README.md that uses a new fatJar build task that packages up all the dependencies to make life easier.
You will probably still run into trouble because you downloaded the JRE (Java Runtime Environment), which doesn't include the Java compiler, javac, as opposed to the JDK (Java Development Kit). "openjdk" is an unfortunate name for the overall project, implying that it's the full JDK. And the headless variant may not include the font machinery the program relies on. (It probably does, but why take chances?)
Instead, I suggest you remove openjdk-21-jre-headless and install openjdk-21-jdk.
From Matt:
Replaced java:
sudu apt remove openjdk-21-jre-headless
sudo apt install openjdk-21-jdk
Following README.md.
./gradlew fatJar appears to have worked.
However:
$ java -jar build/libs/WebFontMetrics-1.0-SNAPSHOT.jar org.interlisp.Main -d ../wfm
SLF4J(I): Connected with provider of type [ch.qos.logback.classic.spi.LogbackServiceProvider]
Exception in thread "main" com.beust.jcommander.ParameterException: Was passed main parameter 'org.interlisp.Main' but no main parameter was defined in your arg class
at com.beust.jcommander.JCommander.initMainParameterValue(JCommander.java:1028)
at com.beust.jcommander.JCommander.parseValues(JCommander.java:819)
at com.beust.jcommander.JCommander.parse(JCommander.java:373)
at com.beust.jcommander.JCommander.parse(JCommander.java:352)
at org.interlisp.Main.main(Main.java:54)
From @hjellinek
Oh, there was a pair of typos (fixed) in README.md. The -jar should be -cp in both command lines.
-jar means that the JAR file defines a main procedure, and to pass the command line to that. -cp means that the code is to be found in the JAR file, but I'll tell you what main procedure to run.
Because org.interlisp.Main is defined as the main procedure, you could do this:
$ java -jar build/libs/WebFontMetrics-1.0-SNAPSHOT.jar -d ../wfm
From Matt:
Thanks.
$ java -jar build/libs/WebFontMetrics-1.0-SNAPSHOT.jar -d ../wfm
Seems to be working. It ran with no errors.
I noticed that in .wcm files, the widths field is :XCCS-WIDTHS. Are these XCCS or MCCS encoded?
From @hjellinek
They are MCCS-encoded. I'll change that keyword.
From Matt:
Next, (probably in a separate PR) will be constructing complete (mostly) fonts from complementary sets of BDF files.
(Which may mean figuring out how to identify which glyphs need to be taken from which .ttf file into BDF, etc., and providing the additional Medley Font Format properties in the created FONTDESCRIPTOR instances.)
(The above discussion should have been in an issue, not in this PR.)
This is the new issue!
@masinter, @rmkaplan, @hjellinek
Which sizes of fonts for DISPLAY should be constructed for this?
The current DISPLAYFONT files include the sizes 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 14, 16, 18, 20, 26, 24, 30, 32, 36, 48, 72.
The HTMLSTREAM web fonts are 6, 8, 10, 12, 14, 16, 18, 20, 24, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 92.
These seems pretty excessive for basic DISPLAY fonts from BDF.
What's a minimal useful set of sizes?
Well, sizes 3 4 5 only exist in Helvetica, and the characters are not readable at all. So I would excluded those at the start. In fact, maybe we should delete the existing files and specify that all sizes below 6 for Helvetica (and maybe all fonts) coerce to 6.
On Nov 14, 2025, at 5:14 PM, Matt Heffron @.***> wrote:
MattHeffron left a comment (Interlisp/medley#2364) https://github.com/Interlisp/medley/issues/2364#issuecomment-3535262337 @masinter https://github.com/masinter, @rmkaplan https://github.com/rmkaplan, @hjellinek https://github.com/hjellinek Which sizes of fonts for DISPLAY should be constructed for this? The current DISPLAYFONT files include the sizes 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 14, 16, 18, 20, 26, 24, 30, 32, 36, 48, 72. The HTMLSTREAM web fonts are 6, 8, 10, 12, 14, 16, 18, 20, 24, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 92. These seems pretty excessive for basic DISPLAY fonts from BDF. What's a minimal useful set of sizes?
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/2364#issuecomment-3535262337, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJKQBE726K3TRLCNQ4334Z47BAVCNFSM6AAAAACL2RRJIWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMZVGI3DEMZTG4. You are receiving this because you were mentioned.
Well, sizes 3 4 5 only exist in Helvetica, and the characters are not readable at all. So I would excluded those at the start. In fact, maybe we should delete the existing files and specify that all sizes below 6 for Helvetica (and maybe all fonts) coerce to 6. …
I started HTMLSTREAM at 6 pts for just that reason.
A further thought about the utility of those particular small sizes: they may be useful in the simulation of a down-scalefor a sketch or some other image, to give a hint of the layout even if nothing is legible. In which case we only would need one font, and it might as well be Helvetica. All other display fonts of sizes 3 4 5 would coerce to the Helvetica glyphs (unless there are better looking variants in the BDF translations, in which case small Helvetica can coerce to those.
What's the strategy for filling in Italic (and Bold Italic) glyphs when the source ttf (and, therefore, bdf) don't have Italic form glyphs?
E.g., "Noto Sans Mono" doesn't have any Italic forms, just Regular and Bold.
Or what if some of the glyphs in a font don't have Italic forms?
E.g., Only the base "Noto Sans" has Italic and BoldItalic ttf files; not for any of the other glyph groups like Arabic, Hebrew, Simplified or Traditional Chinese, etc.
Maybe Italic doesn't make sense in those contexts (languages).
What's the strategy for filling in Italic (and Bold Italic) glyphs when the source
ttf(and, therefore,bdf) don't have Italic form glyphs? E.g., "Noto Sans Mono" doesn't have any Italic forms, just Regular and Bold.Or what if some of the glyphs in a font don't have Italic forms? E.g., Only the base "Noto Sans" has Italic and BoldItalic
ttffiles; not for any of the other glyph groups like Arabic, Hebrew, Simplified or Traditional Chinese, etc. Maybe Italic doesn't make sense in those contexts (languages).
That's the core issue, and I suppose behavior is somewhere between "undefined" and "best effort." You could create an HTML document with text in a style that includes one of those fonts and the italic face and use the browser's inspector tool to see the result. I'd be interested in what you find. I'd try it myself but I'm away from my code and tools.
At least for Chinese, bold is a thing but italic is not, so I wouldn't worry about the italic and bold italic cases.
There are functions in FONT that move the bits around to fake bold and italic. Sometimes they give reasonable resultsSent from my iPhoneOn Nov 15, 2025, at 2:22 PM, Nick Briggs @.***> wrote:nbriggs left a comment (Interlisp/medley#2364) At least for Chinese, bold is a thing but italic is not, so I wouldn't worry about the italic and bold italic cases.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
maybe we need to rethink the notion of "complete": what is the value of having complete Medley Displayfonts, and is there some way to preserve the benfits without trying to fill in things that might depend on more of the context?
If you can't satisfy all of the constratints (3 point font size or no italic or only some planes and not others), what the right "coersion" is might depend on how the font is going to be used.
