Re: xmlroff interface for writing output?

"Mauro C." <[email protected]> writes:
> Hi to all,
>
> --- Tony Graham <[email protected]> ha scritto: 
>
>> "Mauro C." <[email protected]> writes:
>> > --- Tony Graham <[email protected]> ha scritto: 
>> ...
>> >> > I have the same problem with the output result:
>> >> > where can I get a pointer to result doc
>> >> > (FoDocGP->job)?
>> >> 
>> >> Yes, I guess so.
>> >> 
>> >> > 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.
>> 
>> The real point of doing the Cairo backend now was so
>> any changes we make to
>> the interface for writing output will also work with
>> a Cairo backend.
>> 
>> Cairo is similar to GNOME Print in that the output
>> isn't completely written
>> until you dereference the object representing the
>> Cairo document.
>
> Just start to look cairo src, in particular
> cairo-pdf-surface.c (cairo_pdf_surface_create).
>
> for now the solution is to write a tmp file and then
> for examples if necessary a php script can read file
> and send it within an http response.

GNOME Print does support writing to streams the way that Cairo does.  I was
going to suggest that if FoDoc had a function for opening a stream instead of
a file, that FoDoc could also fake a stream from a file for the GNOME Print
backend.  However, extrapolating from
http://www.cairographics.org/manual/bindings-streams.html it seems it would be
better if you did the tmp file trickery in PHP so you could do better error
handling/reporting.

The functions for opening an output would become:

------------------------------------------------------------
void          fo_doc_open_file   (FoDoc          *fo_doc,
				  const gchar    *filename,
				  FoLibfoContext *libfo_context,
				  GError        **error);
void          fo_doc_open_stream (FoDoc          *fo_doc,
				  FoDocWriteFunc  write_func,
				  FoLibfoContext *libfo_context,
                                  void           *closure,
				  GError        **error);
------------------------------------------------------------

It looks like FoDoc needs a function to close the output, e.g.:

------------------------------------------------------------
void          fo_doc_close       (FoDoc          *fo_doc,
				  GError        **error);
------------------------------------------------------------

fo_doc_close() could be called by FoXSLFormatter as part of
fo_xsl_formatter_draw(), but then you'd never be able to get to the
GnomePrintJob underneath a FoDocGP.  It may be better to let the program that
is using libfo -- e.g., xmlroff -- explicitly close the FoDoc.

Would it be useful (and not too dangerous) to be able to get to the underlying
implementation, e.g.:

------------------------------------------------------------
void *        fo_doc_get_implementation (FoDoc *fo_doc);
------------------------------------------------------------

> it would be interesting to have the pdf object
> hierarchy directly for post elaboration, for examples
> insert encrypt or/and digital sign or linearize pdf
> file.

That would be interesting, but I don't know of any free library that supports
it.

Regards,


Tony.



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642