Re: serving compressed images
>> Adding support for TIFF and JPEG is not much code; it would be >> configurable in the same way as PNG. > > You probably mean libjpeg-turbo and libtiff as external dependencies. Yes. > This is a GNU approach. Yes, and it is a good, modular one. > Other systems might have an abstraction layer that handles an > arbitrary set of image formats. I mean Windows since GDI+, or Skia, > or Qt. Truth be told, those systems are more successful on desktop > because of these abstraction layers, perhaps. Hard to tell. You get a complete package, and handling of compressed image formats is a miniscule part of it. > Skia might not be using FreeType on Windows however. If they do, > they might not appreciate depending on libjpeg-turbo as well. My suggestion to add a new load flag would cover this situation. > The same way as PNG is not necessarily the only or the best way to > handle compressed images. That is why FreeType should probably stay > out of it. I disagree. Firstly, we already have PNG support, thus it is natural to handle other formats. Secondly, we can't make Skia the measure of all things. It should be served well, of course, but other use cases must be covered also. > But then, we have a parallel discussion about handling color > palettes in FreeType for Skia. Who would have anticipated that? I think FreeType is the right layer for managing (which is probably a better word than 'handling') palettes. Werner
Re: serving compressed images
> > Adding support for TIFF and JPEG is not much code; it would be > configurable in the same way as PNG. > You probably mean libjpeg-turbo and libtiff as external dependencies. This is a GNU approach. Other systems might have an abstraction layer that handles an arbitrary set of image formats. I mean Windows since GDI+, or Skia, or Qt. Truth be told, those systems are more successful on desktop because of these abstraction layers, perhaps. Skia might not be using FreeType on Windows however. If they do, they might not appreciate depending on libjpeg-turbo as well. The same way as PNG is not necessarily the only or the best way to handle compressed images.That is why FreeType should probably stay out of it. But then, we have a parallel discussion about handling color palettes in FreeType for Skia. Who would have anticipated that? Alexei
Re: serving compressed images
>> 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
Re: serving compressed images
Le jeu. 10 févr. 2022 à 05:32, Alexei Podtelezhnikov a écrit : > Hi All, > > 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. 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. At first, just returning the raw bytes is a perfectly valid option. > Thanks, > Alexei > >
serving compressed images
Hi All, 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? Thanks, Alexei
