@Mosu
My point is,
if MKVToolNix started using "font/" suddenly, there could be a lot of confusion. If you have a plan to migrate to the new types, I suggest you
advertise in advance that there will be compatibility-breaking changes, so that subbers can make informed decisions. Warning from mkvmerge (CUI, not GUI) is one of the possible things you could do, but if it's not easy, that's fine. There are other things we could do, such as simply posting a short explanation in subtitle-related forums or making a user-friendly font-attachment FAQ page.
Maybe some subbers don't want to migrate to the new types. Technically,
RFCs explicitly guarantee that one can freely use private x-tokens such as application/x-truetype-font as long as both parties (in this case muxer and player) agree on it. As such, it will be perfectly fine and standard-compliant (perhaps even recommended) to keep using x- MIME types privately inside Matroska (note:
SSA/ASS itself is a private format, not officially standardized). In fact, when font-embedding was first implemented by Haali (as a patch to Gabest's splitter), it was
announced in doom9 that one MUST use application/x-truetype-font.
On the other hand, since Matroska is an open-spec format, where FileMimeType is defined as the MIME type, one may (and perhaps now should) use the registered MIME types. The catch is, doing so will generate MKVs that older players don't understand. In the worst case, subtitles will be unreadable at all. Sometimes the problem will be only stylistic (wrong font faces), though I imagine young typesetters will be upset when that happens (old typesetters know that font-embedding is optional to begin with, e.g. disabled by default in Haali Splitter until like 2007).
Yet another concern is, unless clearly documented (ideally as a footnote to FileMimeType in the official specs on Matroska.org), some of the legacy types might be forgotten quickly and new-generation players in the future won't play old MKVs right. There are actually as many as 10 different MIME Types that may be used for attached fonts. Implementers generally don't know this undocumented, confusing situation. For example, LAV Filters were fixed in v0.74 saying "Fonts embedded in MKVs without a
proper mimetype were not being imported" - where it is assumed that the legacy types are the
proper mime types. As another example, application/font-sfnt is registered but was/is poorly supported (even by mpv).
End users (including myself) are even more clueless. I only noticed this problem recently, though the top-level type "font" was registered in 2017. Imho, it could be helpful if mkvmerge warns when "problematic" MIME types are specified. But like you said, some of the "problematic" types are actually "good" (officially registered) ones, and there is no fool-safe solution to this dilemma. That said, there are a few end-users who happened to use new types such as application/font-sfnt simply because their tool chains had been updated that way, even though they wouldn't have used such poorly-supported types if warned about them.
I'd say, a warning like "
font/ttf may cause problems. This is not an error. It's fine if you know what you're doing" wouldn't be "punishment". Seeing that, 1% of the users would be cool, like "yeah, I know why this warning is shown. This is a difficult problem and I see mkvmerge is trying to be helpful" and 99% of the users would be like "did I do something wrong? I'll have to check about this" - both would be good. In the second case, ideally they will do some search and will be like "I now understand the problem. I tested several players. I'll use font/ttf" - or they'll be like "I now understand the problem. I'll keep using x-types". Both options sound fine to me. Let them make an informed decision about their own files
As for the error status of GUI, it's ok if it's by design. I just wanted to point out that it could be confusing when one uses GUI as a one-time front end, and not as a batch-job front end.
~~PS~~
About the status bar message on GUI, I'd think two minor text changes might be helpful.
1) In the main manu: "Job queue" -> "Job queue/log"
2) In the context menu: "Show job queue" -> "Show job queue/log"
Unfamiliar with this GUI, one may assume the queue is empty in the example I described above (the same status bar says "Jobs to execute = 0, 0, 0", certainly looking like the queue is empty). This may be just me, but intuitively, one has no reason to look into the "Job queue" when an error is reported. But if the context menu item says "Show job queue/log" when "error(s)" is right-clicked, it'll be immediately clear where to look.