API Addition: "Strict Mode"

[rcombs]

API Addition: "Strict Mode"

[rcombs]

Actually, after some further discussion, this sort of thing probably makes a lot more sense at the authoring-tool level than at the renderer.

Well, I doubt Aegisub actually parses ASS tags to a large extend - mostly it just generates and displays them, but the user is free to add whatever he wants. Also, subtitle creators (the one who use insane scripts etc.) probably would like to test whether their script does something stupid.

So this actually would make sense?

[rcombs]

Heh, I was mostly thinking about fonts, but yeah, there are plenty of other ways to be invalid that we could check in-renderer.

The problem with this is that we don't have any strict parsing anywhere.

[rcombs]

A specific case where this comes up (merging from #425):

When working in Aegisub, it's possible to enter a font name that will appear to work on your machine, but won't if the font is muxed. Example:

• The copy of MS PGothic that ships on macOS is non-PostScript, has fullnames MS PGothic and ＭＳ Ｐゴシック, and PostScript name MS-PGothic
• When searching for MS-PGothic, we won't match the font because the fullnames don't match and it's non-PostScript
• We then call default_provider->funcs.get_fallback, passing in MS-PGothic
• On macOS, CoreText helpfully returns MS PGothic
• We then search for MS PGothic and end up with the font we'd been looking for to begin with

This is hazardous, since it's possible to enter a font name, think everything is perfectly fine, mux it, and then be informed too late that it doesn't work on systems that don't have it installed (or that do, but are on a different platform).

When in strict mode/authoring mode, we should either explode and draw tofu if matching the requested font name fails, or pass Arial to default_provider->funcs.get_fallback. The latter would be simpler to implement, but the former would be more robust.