Re: [ft-devel] Accessing FT_Stream API

[armin]

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