>> > This looks like a bug, both in documentation (which doesn't mention >> > it) and implementation (which doesn't correctly check for a valid `memory' >> > field). >> >> Sure, please find it attached :) -- were you thinking of something >> like that? If so, I can gladly push it with a ChangeLog entry, >> otherwise I'd kindly ask for change requests ;) > > I am still confused though. > "memory The memory manager to use to preload frames. This is set > internally by FreeType and shouldn't be touched by stream implementations." > This means that FreeType takes care of it. Now you suggest otherwise.
Not sure if we're talking about the same thing but _if_ we are, then the problem arises from `FT_Stream_OpenGzip' requiring a memory manager and due to its interface it can only acquire it through the source stream (spec. since there is no way of addressing the library itself ... there might be a good reason for `FT_Stream' not carrying around `FT_Library'). A such, the source stream within `FT_Stream_OpenGzip' has to provide the manager and whoever throws a stream at `FT_Stream_OpenGzip' has to make sure that such a manager exists. Agreed though, it feels somewhat unclean, at least at first glance. > Elsewhere in FT_Stream_OpenGzip and friends: > "The source stream must be opened before calling this function." > How? Well if a stream resides purely in memory (e.g. a simple conversion from some memory blob to `FT_Stream' with `FT_Stream_OpenMemory') this stream can be considered "opened" by default (IMO?) but it still does not contain a memory handle. Also, afaik, streams without memory handles circulate within FreeType so there might be a chance that they end up as input to `FT_Stream_OpenGzip' when using ` FT_Stream_OpenGzip ' without inspecting the code first. Maybe I got the whole stream interface wrong, however :) _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
