|
From: Dave M. <da...@da...> - 2003-07-10 14:47:02
|
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
|