Re: serving compressed images

[Werner LEMBERG]

>> As Werner is working on improving the SBIX table support
>> (https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/139),
>> a topic of compressed images came up.  Right now, FreeType depends
>> on libpng to uncompress PNG, but SBIX can have TIFF and JPEG.  So I
>> was wondering if we should even bother uncompressing those.
>> FreeType could just serve compressed data.  With SBIX, FreeType
>> could still match the best strike to the requested size but then
>> just deliver FT_GLYPH_FORMAT_IMAGE with a tag, some minimal
>> metadata, and raw bytes under FT_GlyphSlot->other.
>>
>> This would be quite similar to the SVG plans currently slated for
>> the next release, i.e., we delegate uncompressing and rendering to
>> a client.
>>
>> Is there interest in such a feature?
>
> I agree that I don't see much use for JPEG and TIFF decoding in the
> library itself.  It might be convenient for a client to provide an
> optional function to decode those with its decoding library of
> choice, and have FreeType return the bitmap data obtained so far,
> since this would simplify code paths.

Adding support for TIFF and JPEG is not much code; it would be
configurable in the same way as PNG.

> As usual, it is important to avoid introducing too much complexity
> in the API or implementation related to pixel color formats, data
> layouts, and memory allocation / release.

I think this would be completely unaffected.

> At first, just returning the raw bytes is a perfectly valid option.

Two ideas come to my mind.

(1) New `FT_GLYPH_FORMAT_{PNG,TIFF,JPEG}` formats.  If a corresponding
    graphic library is not present, FreeType automatically loads the
    table data of the embedded bitmap unprocessed and sets the glyph
    format accordingly.  If a library is present, proceed with the
    current code and convert to a bitmap (or pixmap).

(2) A new `FT_LOAD_RAW_SBITS` flag, allowing the user to override (1).


    Werner