[kovidgoyal]

Originally Posted by nabsltd

To me, that meant you might be thinking about it, but not really putting it on the "to do" list. So thanks for the change.

You're welcome -- and miscommunication is one fo the "features" of the internet

I jumped hard because it's one of those very much not intuitive UI things that the programmer thinks is really easy to use, but other users don't. And, it could be made much, much easier if the user could just click a font file in the "not quite matching" list and say "OK, that's the one I meant...embed that, and make sure the @font-face definition that gets created matches the selector you found, thanks". This would also make it do what users seem to expect it will do.

It's also one of those things that is a lot of effort to implement for a relatively rare use case. Software development is all about tradeoffs. If you feel my judgement of this tradeoff is incorrect, you are welcome to submit a patch.

A user that has this expects the font from the selector to be exactly the same one that shows up when they use a word processor, pick the "Adobe Garamond Pro" font, and choose "bold".

So, yeah, I read the spec...and Calibre's editor (which is acting as a UA at that point) doesn't follow it when embedding.

You cannot have both of those properties, they are mutually exclusive, because word processors do not follow the CSS spec on font matching. And see my post from a couple of days before, quoting myself:

What I can do, is implement a basic fallback mechanism for when a font is not found, so that the matcher tries to find the "closest" available font, which will hopefully be the right one most of the time. However, this is a lot of work to implement.