Re: [Freetype-devel] Re: listing the supported file formats

[suzuki toshiya]

Dear tcll5850@tutanota.com

Basically I support Werner's opinion.

I'm afraid that your plan might something like:
step 1) getting the human-readable "supported font file format" list from 
FreeType, instead of the module names in FreeType.
step 2) check whether the list can cover the file which you're going to load, 
*before* passing it to the FreeType.

My (and maybe Werner's) position is against the step 2. Without invoking the FreeType, or any other 
detailed font driver, it is unreliable to determine whether the font file is really supported by 
the FreeType. I concern (and maybe Werner concerns too) that you may think as "it's very easy, 
because what I would do is strncasecmp() with the suffix of the filename". It is 
misunderstanding. Most traditional fonts for PostScript, and many legacy fonts for macOS do not 
have the suffix, and their contents are not always same (some are only bitmap, some are TrueType, 
some are TrueType format but without outline, some are Type1, some are CFF, etc etc). We cannot 
identify their file formats without passing them to real font driver. Also, how do you distinguish 
which color font format is used in given "xxx.ttf" file? There are at least 3 variants 
(embedded PNG, Microsoft's COLR, and OT-SVG). Also Apple's specification allows more variants.

I'm not against if you write your own wrapper functions to get the human-readable 
"supported font file format", but requesting it in the FreeType API would not 
be welcomed, because it would be an addition of unreliable feature.

However, I can sympathize the feeling "oh, so, should I pass all files to FreeType? 
to find which file is correctly supported? it sounds expensive". If it's the key 
issue, I suggest to consider using fontconfig library, which caches the tested results 
for the files in the specified locations, and you don't have to repeat the checking 
process.

Regards,
mpsuzuki

On 2021/11/22 5:03, Werner LEMBERG wrote:
> [You have again missed to use 'reply to all'.  In the future I won't
>   answer to e-mails from this thread sent to me privately.]
>
> > Not a request: to fix freetype, all of the modules would need a
> > static constant returned on a `module.get_formats()` call but
> > freetype would also need a function for `FT_Get_Supported_formats()`
> > which could return a hashed (removing doubles) string array split by
> > 0s as polled from the modules.
> >
> > however since this isn't available (and is too late now to consider
> > without a major revision), the best I could potentially do would be
> > to poll the available modules and associate local metadata for
> > everything known about the modules (unless I can do better) at init
> > time.
>
> It would be possible to add such a function without big difficulties.
> However, I don't see any benefit in doing so.
>
> > I don't really need to know the modules specific to each format just
> > the total amount of expected formats specifically that could
> > potentially be shared between modules.
> >
> > basically it helps at preventing the processing of garbage data in a
> > local fonts/ directory ;) (an extra layer of cope for stupidity)
>
> I don't understand why you need that.  FreeType gets continuously
> tested by fuzzing engines; it is very robust and can digest (and
> correctly reject) non-font files.  IMHO, such an additional layer is
> not necessary.
>
>
>      Werner