>> 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