Skip to content

Conversation

@rmkaplan
Copy link
Contributor

@rmkaplan rmkaplan commented Dec 4, 2025

\FINDFONTFILE does its own directory searching, avoiding the hyphen-processing of FINDFILE, as discussed in #2404 .

Looking up a non-existent display font with 2 directories and 2 extensions does 8 INFILEP's, 4 for the directory/extension combination times 2 for the charset/no-charset.

Before it did 32, because of parsing the family off as also a subdirectory.

Other devices, with single directories and single extensions (HTML?), should only do 2.

With more thought, we could also build in a little more knowledge (another FONTDEVICEPROP) about whether it is worth probing for the charset subdirectories c0>.

@pamoroso
Copy link
Contributor

pamoroso commented Dec 4, 2025

On Linux Mint 22.1 Cinnamon tracing INFILEP does indeed yield 8 calls for the test case of creating a nonexistent font.

@rmkaplan
Copy link
Contributor Author

rmkaplan commented Dec 4, 2025

If all the information in the Interpress and postscript font-files is instantiated when the charsets are read into font descriptors, then we can convert them all to equivalent medleyfont format files and systematically eliminate the extra factor of 2 that comes from also searching charset subdirectories.

At this point probably we can also set the default DISPLAYFONTDIRECTORIES and DISPLAYFONTEXTENSIONS in MEDLEY-INIT-VARS to point only to the medleyfont directory/extension. Anybody who wants to look at files in the old directories/formats can adjust their private values for these parameters.

In the end , with default settings there should be only one INFILEP the first time there is a probe for a given font (existing or not) on any device--the caches would record the result for later probes.

But this PR does not depend on those future updates.

@rmkaplan
Copy link
Contributor Author

rmkaplan commented Dec 5, 2025

Updated SPREADFONTSPEC macro: @hjellinek noted that it should use the FONTSPEC record rather than popping down the list

@pamoroso
Copy link
Contributor

pamoroso commented Dec 5, 2025

I updated to commit 707a415, still looking good.

Copy link
Contributor

@pamoroso pamoroso left a comment

Choose a reason for hiding this comment

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

It works with no issues in my tests.

@masinter masinter merged commit e7bf6e0 into master Dec 8, 2025
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.

4 participants