Re: [xmlroff] Problems using libfo

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

Dave Malcolm wrote at 10 Jul 2003 15:47:46 +0000:
 > On Tue, 2003-07-08 at 11:46, Tony Graham wrote:
...
 > BTW, does PDF support changing page sizes?

Yes.  Every 'Page' object can set its own 'MediaBox' entry.

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

I can't see the GnomePrint API being 'fixed' since the PostScript
model is the same 'all-for-one-and-one-for-all' page size model.

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

Currently there's no way for the FoDoc to quiz either the FO tree or
the Area tree to see what size pages were either specified or used.

In my previous message, I did, however, mention a possible way for the
FoAreaTree to 'tell' the FoDoc the limits of the page sizes.

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

I would need more details before I can comment.

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

Right now there is no mismatch because the FoAreaPage sets the page
size for the GnomePrintContext and, as you know, the FoDocGP makes a
new GnomePrintJob whenever the page size changes.

There are, of course, numerous options for what to do if there's a
mismatch between the externally-specified GnomePrint page size and the
FoAreaPage page size.  Possibly an FoDocGP child type could have
properties specifying what to do when the FoAreaPage is larger or
smaller than the GnomePrint page size.  Options include:

Smaller:     100%
	     Scale up uniformly
	     Scale up X and Y independently to fill GnomePrint page

Larger:	     Crop (i.e. 100% despite being larger than GnomePrint page)
	     Scale down uniformly
	     Scale down X and Y independently to fill GnomePrint page

 > > Multiple possible and/or partial solutions come to mind:
...
 > >  - Add a child type of FoDocGP that supports only a fixed page size.
 > 
 > The above sound like what I want.

I'll look into it.  Please file an enhancement request on SourceForge.

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

That's fine.  It's certainly much better than if you'd said it
wouldn't work for you.

Part of the reason for the libfo-examples package is to show people
what can be done.  (The other part is to prove that libfo can be used
with programs that aren't built in the xmlroff project's source
directory.)

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

My understanding of the GnomePrint API is similarly rough-and-ready.

Have you read
http://xmlroff.sourceforge.net/phpwiki/index.php/DirectoryStructure
and was it useful to you?

I am contemplating putting in a SourceForge support request to get the
fo, property, area, datatype, and expr subdirectories put under the
libfo directory in the CVS repository.

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

No, there isn't an XML serialisation format for the area trees.

So far there hasn't been any call for one, but it would be easy enough
to start adding one.

But do you want the area tree as it exists or do you want sufficient
information to be able to render the area tree?  For example, things
that aren't going to change, such as border colour, are maintained in
the FO property values and don't appear in the area tree.  Anything
that is a length-conditional, a length-range, or otherwise can vary
depending on the layout has (or should have) a single value in the
area tree.

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