Re: [xmlroff] Problems using libfo

[Dave M. <da...@da...>]

On Tue, 2003-07-08 at 11:46, Tony Graham wrote:


> 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.)

BTW, does PDF support changing page sizes?

> 
> 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.


I thought that perhaps what needs to be done is a fix to the GnomePrint
API. But I think it's acceptable for my application to restrict users to
having a single paper size for the entire document;  I'm targetting home
and office desktop users doing fairly simple word processing tasks
rather than an all-singing all-dancing system like JDF that can collate
print from multiple trays, apply colour correction etc etc.  Plus I'm
doing this as a hobby and there's only so much time I'm willing to spend
fixing the GnomePrint API - unless someone's willing to pay me to do
this work :-)

As far as I understand XSL-FO, it's fairly easy to tell if an input
document has a consistent page size, and what the size should be.  Just
look at the <fo:simple-page-master> elements - though it could give
false negatives if you have the case where you have e.g. a set of page
masters of which some are A4 and some are A5, but only the latter
actually get used when the <fo:page-sequence-master> tags select them;
so alternatively it should determine page size when it has the actual
pages...

So I think I want a FoDoc subclass that takes either an existing
GnomePrintJob or GnomePrintContext as input, and restricts the input to
having simple-page-masters all the same size (either the entire set, or
those that get used).

In terms of GUI, I suspect I need to refactor my stylesheets so that the
paper size part of the XSL-FO output is determined by GnomePrint's
print/paper selection dialog (whereas the rest of the XSL-FO comes from
a standard transform).  This might make sense to split off and provide
as part of libfo (or maybe a libfognomeprintui thing).

What happens if there's a mismatch between the sizes in GnomePrint and
in the <simple-page-master>?  Does it crop, or scale?

> 

> 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.

The above sound like what I want.

>  - 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)?

Err... because I didn't see it.  I'm still learning to find my way
around your source tree.  For that matter, I'm also still learning both
the GnomePrint API and XSL-FO, so this is all a bit rough-and-ready at
the moment.

Another question: is there an XML serialisation format for the area
trees?  I had a brief look through the "area" subdir; the closest I
could see was the fo_area_area_debug_dump_properties function.

Thanks!

-- 
David Malcolm
www.conglomerate.org