Possible feature: Avoid loading mt- files. Solution here.

[ghost]

I asked about this at tex.stackexchange.com a couple of days ago. Since then, I came up with a simple solution that will not affect existing usage.

Near the beginning of microtype.sty, add this: \ifdefined\MTprefix\else\def\MTprefix{mt}\fi

In macro \def\MT@find@file change each mt-#1 to \MTprefix-#1

Then the user could write \def\MTprefix{something} in the document preamble, prior to loading microtype. If file something-FontName.cfg` is found, it will be used. A trick is to intentionally provide a non-existent prefix. Then, when no file is found, microtype will use the config file.

Advantage: The config file can input a larger settings file, then follow it with changes. But the config file cannot change settings that were loaded by one of the mt-FontName.cfg files.

[schlcht]

I wouldn't mind following your suggestion, however, I'm still not convinced of the actual use value. I think you can achieve the same thing by (1) having your local settings in a place where tex will find it first (texmf-local or the current directory), and (2) using \LoadMicrotypeFile (see doc, chapter 5.7), which does allow you to change settings from the provided config files. Granted, it is currently not possible to have microtype ignore existing config files (your trick with the nonexistent prefix), but I have a hard time seeing the purpose of that.

So again, I'm not opposed to adding this, but I would ask you to better explain your use case and why it doesn't work with the existing means.

(Just for reference, here's the TeX.SX question: https://tex.stackexchange.com/q/675160/7674)

[ghost]

I should explain that I am writing a document class, which restricts what the user may or may not do, to meet certain commercial printing specifications. That is beyond the scope of the question, but it means that the things I can do are limited.

The printer has software that robot-inspects an incoming PDF. If anything (such as the bounding box of a character) protrudes into the "forbidden zone" at the page edges, then the PDF will be rejected.

It is possible to require margins that are larger than the forbidden zone, so that font protrusion into the margins will still remain outside the forbidden zone. That is what I do now. Unfortunately, when the book size is small (these are print to paper real books), it is best to keep the margins as small as the printer allows. Otherwise, the smaller textwidth will cause more issues with line breaks.

At the left side, characters such as Jjy are often a problem. At right, f and ff are often a problem. And, if italics are used, the potential problems are greatly increased. It is not sufficent to disable protrusion, because the problem characters naturally have negative left or right side bearings. They would need to be un-protruded, so to speak.

There is a Lua solution for this, not involving microtype. But I see that a lot of good work has been done with microtype built-in protrusion settings, What I wish to achieve is to use the settings wherever possible, and tweak the ones that I need to tweak via my own config file.

The books in question are popular fiction, not academic. Paragraphs are usually short, and there is a lot of horizontal whitespace due to short dialog.

Since I first asked, I have found a do-it-yourself hack that appear to work. In my *cls file, I use this:

\LetLtxMacro\@realrmfamily\rmfamily\relax % Maybe could simply use \let instead.
\ifdefined\MTprefix\else\def\rmfamily{doesnotexist}\fi % \MTprefix per my original request.
\RequirePackage[<options>]{microtype}
\LetLtxMacro\rmfamily\@realromanfamily\relax

Then, unless \MTprefix is defined, microtype will not find any mt- file. But it will still load my config file, which has what is necessary. In fact, the config file inputs the existing mt-EBGaramond.cfg then follow it with the tweaks to SetProtrustion.

General remark: "Easy things should be easy; possible things should be possible." You already have the easy part. I request the possible.

[schlcht]

Still, I think what you want would be easily possible with the existing means:

load microtype with

\RequirePackage[config=<your config file>]{microtype}

then in this config file load the existing settings:

\LoadMicrotypeFile{EBGaramond}

which you can finally overwrite or extend. No?

[ghost]

I will look at that in more detail, and report back ( might be a couple of days). My custom document class loads things in a specific order, with defaults if unset, and possibly there is a timing issue that I need to resolve myself. Or not.

Low urgency, seeing as how I can self-hack if necessary. Meanwhile, thanks for your attention.

[ghost]

I tied what you suggested, but it did not work as intended. Probably this is because my (custom) document class must load things in a specific order, and sometimes change settings dynamically, based on other settings. The details are beyond the scope of microtype, so there is no need for further attention to this request.

I found a solution that works for me, and should continue to work, without the need to modify microtype.sty. In Preamble:

\RequirePackage[<options>]{microtype}
\makeatletter\def\MT@find@file#1{}\makeatother

Then, when \MT@setup@ is executed AtBeginDocument, macro \MT@find@file does not load any mt-*.cfg files at all.

But microtype.cfg or the alterative user-set config file is still loaded. In particular, a user config file can \input any mt-*.cfg file, if desired, then subsequently modify any of its settings.

If there are modifications, microtype will issue warnings about that. The silence package can turn them off. You might consider demoting some of the less-important microtype warnings to information messages.

In my specific case, with a custom document class, I use package etextools to provide \AtEndPreamble (which precedes AtBeginDocument). I put \def\MT@find@file#1{} in there, so the user does not need to write it.

[schlcht]

Good that you've found a solution to your problem! I've added the possibility to change the prefix anyway (cf. here: b33feca), hoping that it might be useful.

[ghost]

Thanks! I am sure that others will also find it useful.