Menu
▾
▴
Re: [xmlroff] Problems using libfo
|
From: Tony G. <Ton...@Su...> - 2003-07-08 11:44:28
|
Dave Malcolm wrote at 8 Jul 2003 01:29:56 +0000:
...
> For what it's worth, here a fragment of code that should give an idea of
> what I'm trying to do with libfo within Conglomerate... Hopefully we can
> meet somewhere in the middle.
I hope that we can. I don't have a hard and fast opinion on what the
interface should be like. I also accept patches.
> I've got a GnomePrintContext, to print to either a real printer, or to
> generate a print preview. I could pass a GnomePrintJob instead, if need
> be. However the FoDoc constructor for GnomePrint likes to create its
> own GPC, and could be a pain for me - perhaps I need some higher level
> object to pass. I looked through the go_doc_gp code and IIRC it can
> create new print jobs as it goes along, in the case that the paper size
> changes half-way through a job. Not sure how to go about getting that
> into the print preview dialog :-(
This mismatch between the XSL model -- where every page can be a
different size -- and the GNOME Print model -- where the page size is
set once and doesn't change -- is a major pain. (SVG Print may also
be a similar pain.)
FWIW, this approach was first proposed on the xmlroff Wiki on 2nd May
[1], and the existence of the 'GnomePrint' page was noted on this list
on 5th May.
Multiple possible and/or partial solutions come to mind:
- Add:
FoDoc * fo_doc_gp_new_from_job (GnomePrintJob *job)
to fo-doc-gp-private.h and make fo-doc-gp-private.h be installed.
- Add a fix_page_size property to FoDocGP so it doesn't always chop
and change GnomePrintContext objects.
- Add a child type of FoDocGP that supports only a fixed page size.
- Add a category to fo_area_tree_to_pdf() for FoAreaTree objects
(i.e., eventually add a draw() method for FoAreaTree) that can call
a method of FoDoc to do whatever is necessary to set up the rest of
the drawing. In support of GNOME Print type page models, the
FoAreaTree could pass the maximum height and maximum width of its
child FoAreaPage objects so the largest necessary page size is used
throughout.
- Improve the setting of parameters for FoDoc types, probably by
adding more parameters to FoLibfoContext and making FoLibfoContext
able to generate FoDoc objects.
> I've also got an xmlDocPtr, containing the document (i.e. with a fo:root
> as the root element); it's typically the result of a XSLT transform,
> which my GUI has hidden from the end-user.
That is how it's supposed to work.
> Here my pseudo-code - will this be a sane way of using libfo?
>
> void print_xslfo(GnomePrintContext *gpc,
> xmlDocPtr xml_doc)
> {
> FoDoc *fo_doc;
> FoFo *fo_tree;
> FoArea *area_tree;
> GError *error = NULL;
>
> g_return_if_fail(gpc);
> g_return_if_fail(xml_doc);
>
> fo_doc = fo_doc_gp_new ();
fo_doc = fo_doc_new_from_type ("gp");
But that will have to change once there's a way to pass in your
GnomePrintContext or GnomePrintJob.
> /* FIXME: need some way to pass our gpc or job to the FoDoc
> constructor; would a config do it? */
>
> fo_xml_doc_to_fo_and_area_trees (xml_doc,
> fo_doc,
> &fo_tree,
> &area_tree,
> 0, /* gint debug_level */,
> &error);
> /* FIXME: error handling! */
> }
You currently also need to call fo_area_tree_to_pdf() to actually get
any output. It doesn't happen automatically because there's supposed
to be an 'area-tree adjust' phase after the FO and area trees are
first made up.
I think that the solution to my hangup about installing area-to-pdf.h
is to make an fo_xsl_formatter_draw() function that doesn't do much
more than call area_tree_to_pdf().
Out of interest, why don't you just use FoXslFormatter (once there's a
way to pass in your GnomePrintContext or GnomePrintJob)?
Regards,
Tony Graham
------------------------------------------------------------------------
XML Technology Center - Dublin
Sun Microsystems Ireland Ltd Phone: +353 1 8199708
Hamilton House, East Point Business Park, Dublin 3 x(70)19708
[1] http://xmlroff.sourceforge.net/phpwiki/index.php/GnomePrint
|
