Re: Help in using gsapi_set_stdio() to capture stdout into a memory buffer

Well, nothing really important. When I noticed that it writes quite  
smaller files (for the case I tested) I wondered it I could use it instead  
and in the way save some memory.

Joaquim

> As with most Ghostscript devices (and, in fact, most Ghostscript  
> internals) there isn't much option other than to dig into the source  
> code to learn about the 'bit*' devices.
>
> If you have specific questions, we might be able to answer, or possibly  
> know where to look to find the answer, or maybe know a man who can.....
>
> Chris
>
>
> On 17/03/16 16:17, Joaquim Luis wrote:
>> Ken & Chris
>>
>> Thanks for your replies. Because Chris suggestions sent me to unfamiliar
>> grounds it took me a bit to digest that. I've came out with a solution
>> based on pipes that seam to work.
>>
>> I'm using here the pbmraw device because it's a simple non compressed
>> format so I know how big is the buffer and also because ultimately
>> that's how I want the raster.
>>
>> One question still, where can I learn about the 'bitrgb' device  
>> structure?
>>
>>
>> NOTE: the code file is attached, as it was in my first message.
>>
>> Thanks
>>
>> Joaquim
>>
>>> On 16/03/16 01:13, Joaquim Luis wrote:
>>>> Hi,
>>>>
>>>> I am trying to learn how to capture the raster conversion of a PS file
>>>> into memory but it's not being easy.
>>>> The following example (adapted from one posted here before) correctly
>>>> prints in stdout a png version of the small PS embedded in code. I  
>>>> know
>>>> it's correct because I save it into a file I see it is. But my goal is
>>>> to save it in a memory buffer so, as an intermediate step, I wanted to
>>>> save it in file via gsapi_set_stdio.
>>>
>>> This is *known* not to work and there is, in fact, a bug open to that
>>> effect (with a summary of why it doesn't work):
>>>
>>> http://bugs.ghostscript.com/show_bug.cgi?id=694993
>>>
>>> The trouble is, without changing a fundamental assumption of the device
>>> API, it's unlikely to be possible.
>>>
>>> FWIW, your best solution would be to write your own device. If you are
>>> not doing high resolution or large page work, you could look at using
>>> the "display device".
>>>
>>> Lastly, a possible workable solution would be to use a named pipe: pass
>>> the named pipe to gs for output, and have your code read back from it -
>>> depending on the amount of buffering Windows does on named pipes, you
>>> might need to do some fiddling (maybe theads, maybe separate processes)
>>> to read as data is being written.... if it were me, I'd spawn a  
>>> separate
>>> process for gs.
>>>
>>> Chris
>>> _______________________________________________
>>> gs-devel mailing list
>>> [email protected]
>>> http://ghostscript.com/cgi-bin/mailman/listinfo/gs-devel
>>
>>
>> _______________________________________________
>> gs-devel mailing list
>> [email protected]
>> http://ghostscript.com/cgi-bin/mailman/listinfo/gs-devel
>>
> _______________________________________________
> gs-devel mailing list
> [email protected]
> http://ghostscript.com/cgi-bin/mailman/listinfo/gs-devel