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

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
>