https://bugs.documentfoundation.org/show_bug.cgi?id=151123
--- Comment #13 from Eyal Rozenberg <[email protected]> --- ... continued ... > It should be technically possible. There are multiple ways it can be > implemented: > 1. Check the “meta” table of the font, but many fonts do not have it and it > can be unreliable of the font author did not set it correctly. > https://learn.microsoft.com/en-us/typography/opentype/otspec184/meta In your experience, how common is it for authors to set this incorrectly? And more specifically, to err in favor of claiming support for an unsupported script, vs disclaiming support for an actually supported script? If the error is almost always just on one-side, we could use this as an initial filter (with or without second-guessing later). > 2. Check the “OS/2” table of the font for Unicode range bit. We already have > that, but it is also unreliable (fonts often lie about Unicode ranges it > supports because some Windows app reject the font if it does not declare a > certain range supported), and the bits are exhausted and new ranges added to > Unicode can’t be supported to these (this also uses Unicode ranges not > languages or writing systems, so the mapping will not be faithful either > way). So, that sounds like something we would not want to do... > 3. Check the “cmap” table of the font. Most reliable but can be slow if done > to tens or hundreds of installed fonts at startup. This brings up several possibilties: I. Gradation in determination of supported formats. II. Caching resolved script support info. III. Lazy computation of the supported scripts (or script-types) I. Gradation: We could perhaps start with the first method (the 'meta' table), if its error is always on the side of over-reporting support for scripts; and maybe if it isn't. We can then start the more involved computation, using the cmaps, while the app is already responding to the user. II. Caching: Suppose we have some easy-to-compute key for a typeface (so that upgrading it can be noticed). We can cache the mapping of font-key-to-supported-scripts (or for now, script-type's), somewhere in the LO profile; and load it when LO starts. III. Lazy: We could avoid performing the categorization of fonts on startup, and only start it when the typeface selection drop-down list-box is expanded; or perhaps when Format... | Character... is opened. PS - Ilmari, Khaled - can one of you confirm please? -- You are receiving this mail because: You are the assignee for the bug.
