Rmk206 offline enlargement of small ns display fonts#2687
Conversation
… as part of importing NS fonts
… fonts and fontspecs
|
In my initial tests on Linux Mint 22.1 Cinnamon at 1080p I notice text is slightly larger in Execs, menus, and elsewhere. For example, text in DInfo is more readable. I assume the old font behavior is no longer available not even as an option, right? |
|
There are now text overflow issues with VIRTUALKEYBOARDS, see for example the function key row of the DEFAULT keyboard: 
This is what it looked like in April of 2023: 
Also, the right and down arrow symbols in the numeric keypad are replaced by black boxes and the left and up arrows are rendered as |
|
In CALENDAR the top of the year is slightly cropped in the year view. 
|
|
In MISSILE the text 
Now: 
|
|
There are text overflow issues in the FM-CREATOR LispUsers module. Now: 
In March of 2023: 
|
|
The display problem with virtual keyboards was noted in the original NSDISPLAYSIZES, I have to upload the fix.
But I also have to make sure that the keyboard codes are now MCCS compliant, a separate issue.
… On Jul 10, 2026, at 5:20 AM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2687)
<#2687 (comment)>
There are now text overflow issues with VIRTUALKEYBOARDS, see for example the function key row of the DEFAULT keyboard:
virtualkeyboard.png (view on web) <https://github.com/user-attachments/assets/98b9a835-b753-4435-b00f-920297bba942>
This is what it looked like in April of 2023:
virtualkeyboard-apr2023.png (view on web) <https://github.com/user-attachments/assets/bc23b544-b910-4ce4-920c-3a08b0ec890a>
Also, the right and down arrow symbols in the numeric keypad are replaced by black boxes and the left and up arrows are rendered as _ and ^. Medley Online shows the right and down arrows correctly but not the left and up ones, so this may be a font encoding rather than enlargment issue.
—
Reply to this email directly, view it on GitHub <#2687?email_source=notifications&email_token=AQSTUJIEIJ3WGMN66VFS7W35EDNSHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTGUYTQOBRGAYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4935188100>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJOWG2P5BB25SEBKGLT5EDNSHAVCNFSNUABFKJSXA33TNF2G64TZHMZDQMJVGE4TSNRUHNEXG43VMU5TIOBVGIYTAMJRGEZ2C5QC>.
You are receiving this because you authored the thread.
|
|
The old behavior can be made available by also keeping a version of the old fonts with their old nominal sizes, perhaps in an overlay fonts directory. Just like the current NSDISPLAYSIZES package, the incore cache of fonts would be cleared out so that switching back would catch the creation of any new font descriptors. But descriptors already created and stashed in other data structures or variables would not be updated.
Or the loadup could be built with the old fonts, and NSDISPLAYSIZES could be fixed just to smash the cache and then point to the directory with the new descriptors (again, as now, missing fonts that are stored in other places).
The main improvement here is that enlarged fonts that nherit from other enlarged fonts and so have more consistent glyph sizes.
… On Jul 10, 2026, at 12:38 AM, Paolo Amoroso ***@***.***> wrote:
I assume the old font behavior is no longer available not even as an option, right?
|
|
I was thinking not so much of dynamically switching font behavior but rather a way of starting a Medley session with the old behavior, or doing a loadup with the old behavior if it's not practical to do it per session. Such a "classic mode" would provide maximum compatibility and an experience closer to the original Medley. |
|
Switching at loadup is easy: just have the loadup's DISPLAYFONTDIRECTORIES point to either of two of offline-constructed fonts.
On further thought, though, it would be pretty easy to switch all the fonts in memory, no matter where they may be stashed--so long as they were all created by FONTCREATE and thus stored in the \FONTSINCORE cache. We could whip through the cache, smashing the existing font descriptors with field values taken from the alternative set of fonts. Probably just a few lines of code. The fonts in memory would all be in a consistent state.
… On Jul 10, 2026, at 9:30 AM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2687)
<#2687 (comment)>
I was thinking not so much of dynamically switching font behavior but rather a way of starting a Medley session with the old behavior, or doing a loadup with the old behavior if it's not practical to do it per session. Such a "classic mode" would provide maximum compatibility and an experience closer to the original Medley.
—
Reply to this email directly, view it on GitHub <#2687?email_source=notifications&email_token=AQSTUJMO2RBDA2TODF2MXNL5EEK2NA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTG42DANJQGEYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4937405010>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJLNVDSCPCNXYYNAP4T5EEK2NAVCNFSNUABFKJSXA33TNF2G64TZHMZDQMJVGE4TSNRUHNEXG43VMU5TIOBVGIYTAMJRGEZ2C5QC>.
You are receiving this because you authored the thread.
|
|
Do you mean something like |
|
I have never used NSDISPLAYSIZES, and it appears that doing so breaks other expectations -- because the glyph sizes now don't match the widths? I would prefer to NOT have the NSDISPLAYSIZES effects by default. If someone feels the benefits outweigh the problems then they should be able to optionally load NSDISPLAYSIZES. |
|
I would do it on just a switch in the scripts: NSDISPLAYSIZES = YES, NO. If NIL, then whatever default we pick
… On Jul 10, 2026, at 11:13 AM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2687)
<#2687 (comment)>
Do you mean something like export DISPLAYFONTDIRECTORIES=/home/paolo/medley/medley/fontsold; ./scripts/loadup-all.sh -apps for the loadup?
—
Reply to this email directly, view it on GitHub <#2687?email_source=notifications&email_token=AQSTUJMWACMW43DLZ3CI6LD5EEW43A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTHAZDGMBTGEY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4938230311>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJJ4J5NS4YKPVSWALTD5EEW43AVCNFSNUABFKJSXA33TNF2G64TZHMZDQMJVGE4TSNRUHNEXG43VMU5TIOBVGIYTAMJRGEZ2C5QC>.
You are receiving this because you authored the thread.
|
|
Looking at the virtualkeyboards revealed another separate issue, having to do with different codes with the same glyphs (I forget what the term is for that). Character set 342 of our Unicode mapping tables defines the International Phonetic Alphabet. Some of the codes there have the same glyphs as codes in other character sets. For example, the XCCS IPA code for c-cedilla xE2DA maps to Unicode x00E7, IPA code for k xE2DE maps to x006B. The problem appears when we read a UTF8 file that has a Unicode c-cedilla code 00E7: what MCCS/XCCS code should it show up as? The phonetic c-cedilla 342,332 or the extended Latin c-cedilla 361,255. We are currently getting the phonetic code in the UTOMCODE direction, and that is showing up as a black box in the virtual keyboard displays when that now-UTF8 file is read, because we haven't moved the c-cedilla glyph over to the phonetic code. That's how the problem emerged: the file has the unicode c-cedilla, we read it into the unintended MCCS code, and it's black. Not sure what to do. XCCS is making more distinctions here than Unicode. Simplest thing would be to exclude the IPA character set when we build the mapping tables. Other ideas? |
|
A further thought on the IPA homoglyph problem... I think we should just assert that the confusing homoglyphs in XCCS IPA don't exist in MCCS, that MCCS is like Unicode in this particular regard. That is, we remove those confusing correspondences from the UTOMCCS mapping tables: Unicode c-cedilla will map always to MCCS (XCCS) c-cedilla and not to IPA. In the extremely unlikely event that we encounter an XCCS file with an IPA c-cedilla code, we would read that to the normal MCCS normal c-cedilla. If we were then to write that file out, to MCCS or even again to XCCS, we would have lost the more specific XCCS encoding. Oh well. |
|
On 7/10/2026 8:45 AM, Paolo Amoroso wrote:
*pamoroso* left a comment (Interlisp/medley#2687)
<#2687 (comment)>
In CALENDAR the top of the year is slightly cropped in the year view.
That's odd. It looks normal to me, in a sysout with a MAKESYSDATE of
8-Apr-2026.
- Michele
|
|
The 8-Apr-2026 sysout didn't do the text enlargement of this branch my comment referred to. Se the text of the year, which is little bit larger in this branch, is slightly cropped at the top. |
@pamoroso is reporting the glitches that happen if the small NS fonts are bumped in size (NSDISPLAYSIZES), for better consistenty of nominal sizes across fonts. |
4 participants
This includes code for producing enlarged versions of NS display fonts as part of the font import process--the step of reading strike and ac files and producing the first set of equivalent medleyfont files. Those files then feed the rest of the offline process of MCCS code conversion, completion for missing glyphs and character sets, and faking bold/italic.
The effect is that Classic 10 display fonts, for example, have the larger glyphs taken from the Classic 12 AC fontfile source. These are the glyphs that would have been produced by loading the lispusers/NSDISPLAYSIZES package, but that would not have fixed all of the glyphs that had been inherited or faked from other sources as part of the offline font construction process. This conceptualizes the enlargement as just part of the importation process from funky external source files. This should obsolete the NSDISPLAYSIZES package.
The upside of this is that glyphs in small (less than nominal size 12) NS fonts will be more readable on the display, and they will be closer in size to the glyphs of the same nominal size for non NS fonts. Previously (without loading NSDISPLAYSIZES), there would be a visible size difference in a line that had Classic 10 characters next to Timesroman 10 characters. Now they are much closer.
The downside of this (as with the previous NSDISPLAYSIZES strategy) is that some characters or images that were carefully formatted with small NS fonts on the display may now not have the desired appearance--lines may overflow, characters may extend beyond intended boxes. But the hardcopy appearance is not affected.
This PR also includes new versions of all the medley display fonts (306 font files). I thought I could just include new versions of the small NS fonts, but I realized that Timesroman and other fonts were extended/completed by including glyphs from Classic/Modern of the same nominal size. So in the end I just re-imported everything.