Re: [xmlroff] libfo interface and PHP ext

[Tony G. <Ton...@Su...>]

"Mauro C." <inc...@ya...> writes:
> --- Tony Graham <Ton...@Su...> ha scritto: 
>> "Mauro C." <inc...@ya...> writes:
...
>> I don't want to decide without further discussion. 
>> Does anyone else have any
>> input?
>> 
>> > I have the same problem with the output result:
>> > where can I get a pointer to result doc
>> > (FoDocGP->job)?
>> 
>> Yes, I guess so.

Actually, FoDocGP is capable of writing multiple output files if the page size
changes between page sequences.

>> > is the output file written when fo_doc_gp_finalize
>> is
>> > invoked?
>> 
>> Yes, which really happens when you run:
>> 
>>    'g_object_unref (fo_doc);'
>> 
>> I am open for suggestions on how to change that.
>
> my idea is to separate creation and file writing and
> have to call explicitly function to generate and other
>  one to get result or to write file.
>
> not see all the source of libgnomeprint, but ther is:
>
> GnomePrintJob->meta->buf
>
> guchar *buf;
>
> maybe the buffer used for the output result.
>
>> 
>> I don't want to expose the GnomePrintJob underneath
>> FoDoc any more than I
>> wanted to expose the xmlDocPtr under FoXmlDoc, but
>> it's obvious that the
>> current setup is not useful for your purposes.
>
> good strategy to not expose implementation expecially
> for libgnomeprint. so you can change print engine
> without force to recompile apllication that rely on
> libfo.

Against my better judgement, I'm currently working on a Cairo backend for
xmlroff.

A Cairo backend has long been talked about, but I figured that if we're going
to change the FoDoc interface, we might as well change it once so it works for
scripting languages and Cairo, instead of changing it once now and possibly
changing it again later for Cairo.

The Cairo backend looks fairly straightforward, though there's still the
possibility of surprises.  The hardest part looks to be... getting the output
result.

Regards,


Tony.