Tedit failures in HCFILES

[rmkaplan]

I have done some initial probing to try to see what's going on.

In the HC-FAILS file, there are 64 entries for TEDIT.TO.IMAGEFILE failures.

Of those, 41 were font failures:

 11 were failures in trying to find size 1 postscript fonts for Modern and Gacha.

 30 were failures in trying to find a display font.
        25 of those were  in Notecards>docs/user-guide-v1.2>  files looking for nonexistent size 13.
          5 were not notecards and not size 13 (Helvetica 6 and Timesroman 24).

The 13's are likely 10/13 smashes, but it is still surprising that it needs display fonts for hardcopy.
(The Helvetica 6 and Timesroman 24 also don't exist--probably there should be a table entry that allows coercion to something close)

[nbriggs]

./medleydisplayfonts/TIMESROMAND30-MRR.MEDLEYDISPLAYFONT
./medleydisplayfonts/TIMESROMAND72-MRR.MEDLEYDISPLAYFONT
./medleydisplayfonts/TIMESROMAND24-MRR.MEDLEYDISPLAYFONT
./medleydisplayfonts/TIMESROMAND36-MRR.MEDLEYDISPLAYFONT
./displayfonts/c0/TIMESROMAND36-MRR-C0.DISPLAYFONT
./displayfonts/c0/TIMESROMAND30-MRR-C0.DISPLAYFONT
./displayfonts/c0/TIMESROMAND72-MRR-C0.DISPLAYFONT
./displayfonts/c0/TIMESROMAND24-MRR-C0.DISPLAYFONT

You use "display" style fonts instead of body fonts for headlines, posters, etc. at large sizes. 24pts and up here are TimesRomanDisplay.

[nbriggs]

I guess the Alto fonts, and by inheritance the Interlisp-D fonts, didn't have a separate field in the face for "display" so it got folded into the name instead

The NY Public Library tells us that:

Times Roman is an everyday text font designed for small, narrow-column body text (10–12 points), while Times Display is designed for large headlines (usually 18+ points). Display fonts feature exaggerated stroke contrast and tighter letter spacing, whereas text fonts have thicker, sturdier strokes to remain legible at small sizes.

[nbriggs]

Helvetica 6 exists as an Interpress font, but not as a screen font. It should probably go to Modern 6.

[rmkaplan]

For these errors it is not looking for "D" fonts to render large headings and signs, it is looking explicitly for fonts for the DISPLAY device. It shouldn't need to do that for hardcopy.

[rmkaplan]

Fix for the postscript, helvetica 6, and timesroman 24 glitches in PR #2637.

[rmkaplan]

I took a closer look to see why it is creating DISPLAY fonts when only doing TEDIT.TO.IMAGEFILE to PDF, it isn't a bug but may be a legacy non-feature.

Tedit hardcopy applies to a Tedit stream created by OPENTEXTSTREAM. In the common case, the stream has been created and associated with a window and a process, and hardcopy is invoked on that stream by the generic hardcopy menu command. Even if the WINDOW argument is NIL at open, the stream is still set up on the assumption that the output eventually will go to a window (which can be assigned when TEDIT is called on the stream to set up the process).

Since the stream has already been created for the display, it already has display fonts. What happens during hardcopy is that an output image stream is created and passed to the line formatter, and then the magic happens: underneath the formatting algorithm, the font for the hardcopy device that corresponds to each display font is created (FONTCOPY), the hardcopy metrics are substituted for the metrics of the display font, and the formatting continues unaware of the switch.

So, in the hardcopy-only case, it still builds the textstream as if it were going to a window, even if the window argument is NIL...and we always get the display fonts that makes the substitution trick still work.

Another strategy would have been to reconsider the WINDOW argument of OPENTEXTSTREAM as an image destination, defaulting to display. But it isn't worth figuring out all the consequences of such a move (e.g. if the stream is created for pdf, can it then be assigned a window and process?).

[masinter]

maybe this doesnt matter, but I wonder if Venue sysout has the same problem of creating DISPLAY fonts unneccessarily?

I wish I could trace FONTCREATE but it has a stack overflow risk because printing the TRACE output to the trace window calls FONTCREATE. I'm wondering if we can turn off traceing if you're already in a call from a traced function, or breaking during a setup to breaking, etc.

[masinter]

{medley}<.github>workflows>doHCFILES.yml copies the sister repositories notecards, loops, test to be under medley and removes their .git directories.

[nbriggs]

I've managed to trace FONTCREATE in the Venue sysout by first tracing something else and running that to create the *TRACE-OUTPUT* window (or, better, setting it to a stream on disk before running the traced code), then tracing FONTCREATE so that everything is already set up. I haven't managed to do the equivalent of what HCFILES does - but I'm sure someone could.

[rmkaplan]

If all the fonts needed for the trace functionality exist, then it is safe to trace or break \CREATEDISPLAYFONT to see what new DISPLAY fonts will be created during a computation. (You can also break the generic \CREATEFONT, but that doesn't exist in the Venue sysout.)

You can create a Tedit file with an atypical font and save it. Then if you break \CREATEDISPLAYFONT in a fresh sysout (where that font doesn't yet exist but all the break/trace fonts do exist) and break \CREATEDISPLAYFONT, you should see what it is trying to do.

[rmkaplan]

3 of the HCFILES failures showed up as illegal argument errors for DATEFORMAT.

I have tried TEDIT.TO.IMAGEFILE on all three, with no problems (other than Tedit printimg a warning message on the bitmap gallery that page 9 is filled with headings). But the pdf's for all 3 are produced and look good.

So, what is the context in which HCFILES runs? Are its lispusers> and library> directories completely up to date?

[rmkaplan]

I wrote a function that does byte-swaps of CR and LF, and then ran TEDIT.TO.IMAGEFILE on the swapped versions of all the files that failed because of a missing font of size 13.

I got what look like reasonable pdf's for 23 of the 25. Should I push the swapped versions of those 23?

[MattHeffron]

I have tried TEDIT.TO.IMAGEFILE on all three, with no problems

When you did this, were you running with or without your INIT?
Anything that you've loaded, or variables set, that the HCFILES environment doesn't, could be the difference.