You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by paul womack <pw...@papermule.co.uk> on 2008/05/06 14:16:01 UTC
variable size output (pages)?
I need to generate output (PDF) where the page
size (actually just page depth) varies
with the content.
In effect I want to generate "galleys" of text,
where the formatting width is known, but the depth
of the final output is determined by the amount
of text formatted, in effect fitting the page
to the content.
I have tried to search the documentation,
but am greatly hampered by not knowing
the terminology well enough to search effectively.
It appears that I can "fake" what I want by
either using imageprocessing to "autocrop"
the output, or (possibly) by doing
"something" to the XML area tree, and performing
a second pass, but if there's a proper
way to achieve my goal, that'd be great.
I would welcome either advice, or simply
a pointer to any relevant parts of the
specification(s) or documentation.
BugBear
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: variable size output (pages)?
Posted by paul womack <pw...@papermule.co.uk>.
Andreas Delmelle wrote:
>
> On May 6, 2008, at 14:16, paul womack wrote:
>
> Hi
>
>> In effect I want to generate "galleys" of text,
>> where the formatting width is known, but the depth
>> of the final output is determined by the amount
>> of text formatted, in effect fitting the page
>> to the content.
>
> What you would need:
> http://www.w3.org/TR/xsl/#page-height
>
> See the defined possible value of "indefinite"
>
> FOP does not implement this yet, unfortunately (while the compliance
> page /does/ indicate full compliance; correction/note needed)
>
> For the moment, your area tree idea is probably your best bet, unless
> you feel like joining us, and diving into the code yourself... ;-)
>
> FWIW: It has been discussed a couple of times on fop-dev@, so there are
> already ideas floating around.
A perfect, if disappointing answer :-(
Thank you.
BugBear
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: variable size output (pages)?
Posted by paul womack <pw...@papermule.co.uk>.
Andreas Delmelle wrote:
>
> I think the problem is that you have to specify the eventual renderer to
> mimic.
>
> Try
> ../fop -xsl lineage.xsl -xml lineage_eg.xml -at image/tiff lineage.at.xml;
Yes; that worked (in the standard sense of did what I wanted!)
Thank you very much, for all your help.
BugBear
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: variable size output (pages)?
Posted by Andreas Delmelle <an...@telenet.be>.
On May 8, 2008, at 14:52, paul womack wrote:
>>>
>>> q1) May I assume that any particular version of FOP would be able
>>> to consume an area tree (XML) that it had itself generated?
>> That's a reasonable assumption, I think.
>
> (I have noted your other information; thank you)
>
> This assumption may be reasonable, but it just failed
> a test (I think)
>
> generating tiff directly:
>
> ../fop -dpi 288 -xsl lineage.xsl -xml lineage_eg.xml -tiff a.tif
>
> gives me different line breaks to going via an "at" file:
>
> ../fop -xsl lineage.xsl -xml lineage_eg.xml -at lineage.at.xml; ../
> fop -atin lineage.at.xml -dpi 288 -tiff b.tif
>
> Unless these are different for a "valid" reason that I am ignorant of?
I think the problem is that you have to specify the eventual renderer
to mimic.
Try
../fop -xsl lineage.xsl -xml lineage_eg.xml -at image/tiff
lineage.at.xml;
^^^^^^^^^^
HTH!
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: variable size output (pages)?
Posted by paul womack <pw...@papermule.co.uk>.
Andreas Delmelle wrote:
> On May 8, 2008, at 14:17, paul womack wrote:
>>
>> O.K.
>>
>> I've found this documentation on the "area tree" internal modelling:
>>
>> http://xmlgraphics.apache.org/fop/dev/design/areas.html
>>
>> I think this page:
>> http://xmlgraphics.apache.org/fop/0.94/intermediate.html
>>
>> says that the XML format is "subject to change".
>>
>> q1) May I assume that any particular version of FOP would be able
>> to consume an area tree (XML) that it had itself generated?
>
> That's a reasonable assumption, I think.
(I have noted your other information; thank you)
This assumption may be reasonable, but it just failed
a test (I think)
generating tiff directly:
../fop -dpi 288 -xsl lineage.xsl -xml lineage_eg.xml -tiff a.tif
gives me different line breaks to going via an "at" file:
../fop -xsl lineage.xsl -xml lineage_eg.xml -at lineage.at.xml; ../fop -atin lineage.at.xml -dpi 288 -tiff b.tif
Unless these are different for a "valid" reason that I am ignorant of?
The "b.tif" files has lines going beyond the right hand side of
the raster; the lines appears to have been wrapped for a large
page width than I (actually) have.
BugBear
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: variable size output (pages)?
Posted by Andreas Delmelle <an...@telenet.be>.
On May 8, 2008, at 14:17, paul womack wrote:
>
> O.K.
>
> I've found this documentation on the "area tree" internal modelling:
>
> http://xmlgraphics.apache.org/fop/dev/design/areas.html
>
> I think this page:
> http://xmlgraphics.apache.org/fop/0.94/intermediate.html
>
> says that the XML format is "subject to change".
>
> q1) May I assume that any particular version of FOP would be able
> to consume an area tree (XML) that it had itself generated?
That's a reasonable assumption, I think.
> q2) And, a detail question, which I have not been (easily)
> able to find an answer to: in the area tree, what are the units?
1/1000 of a point (= non-standard 'millipoints'), or 1/72000 inches.
> My present plan is to identify the lower bound of the last text line
> from the area tree, then use that to perform a second fop pass (all
> the way from the start) with a "carefully contrived" page-height.
What I think would be the easiest approach:
-> generate an area tree using a relatively large page-height (enough
to fit the largest content)
-> use forced breaks (break-before="page") in the FO to trigger the
page-breaks
-> if you look at the area tree, you will then see <regionViewport />
elements generated for the region-body of each page; if the initial
used page-size is large enough, these should have the exact same
dimensions on every page
Finally, run the area tree through an XSLT transform, that simply
copies the input, but adds special processing for those
regionViewports: check the childnodes' accumulated 'bpd' attribute,
and shrink the regionViewport's bounds so it will fit nicely around
the content.
This is all a bit speculative, but this seems the most efficient way
I can come up with FTM, and it does presuppose some knowledge/
understanding of XSLT.
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: variable size output (pages)?
Posted by paul womack <pw...@papermule.co.uk>.
Andreas Delmelle wrote:
>
> On May 6, 2008, at 14:16, paul womack wrote:
>
> Hi
>
>> In effect I want to generate "galleys" of text,
>> where the formatting width is known, but the depth
>> of the final output is determined by the amount
>> of text formatted, in effect fitting the page
>> to the content.
>
> What you would need:
> http://www.w3.org/TR/xsl/#page-height
>
> See the defined possible value of "indefinite"
>
> FOP does not implement this yet, unfortunately (while the compliance
> page /does/ indicate full compliance; correction/note needed)
>
> For the moment, your area tree idea is probably your best bet, unless
> you feel like joining us, and diving into the code yourself... ;-)
O.K.
I've found this documentation on the "area tree" internal modelling:
http://xmlgraphics.apache.org/fop/dev/design/areas.html
I think this page:
http://xmlgraphics.apache.org/fop/0.94/intermediate.html
says that the XML format is "subject to change".
q1) May I assume that any particular version of FOP would be able
to consume an area tree (XML) that it had itself generated?
q2) And, a detail question, which I have not been (easily)
able to find an answer to: in the area tree, what are the units?
(I could reverse engineer, but I'd rather not)
My present plan is to identify the lower bound of the last text line
from the area tree, then use that to perform a second fop pass (all
the way from the start) with a "carefully contrived" page-height.
BugBear
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: variable size output (pages)?
Posted by Andreas Delmelle <an...@telenet.be>.
On May 6, 2008, at 14:16, paul womack wrote:
Hi
> In effect I want to generate "galleys" of text,
> where the formatting width is known, but the depth
> of the final output is determined by the amount
> of text formatted, in effect fitting the page
> to the content.
What you would need:
http://www.w3.org/TR/xsl/#page-height
See the defined possible value of "indefinite"
FOP does not implement this yet, unfortunately (while the compliance
page /does/ indicate full compliance; correction/note needed)
For the moment, your area tree idea is probably your best bet, unless
you feel like joining us, and diving into the code yourself... ;-)
FWIW: It has been discussed a couple of times on fop-dev@, so there
are already ideas floating around.
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: variable size output (pages)?
Posted by paul womack <pw...@papermule.co.uk>.
Peter Coppens wrote:
> Ic...so there is no way to know what the page size will have to be until
> the layout has been completed?
No, that's rather the heart of my problem.
Consider, if you like, a different example.
I wish to make rendered images of quotations
for placement on a web site.
Of course, quotations vary in length...
I know I want the images to be 350 pixels wide,
to fit my web site design.
So...
The depth of these images will need to vary
in order to accomodate the words, but I don't
know *how* deep until I've laid out the text, with
line wrapping, hyphenation etc.
BugBear
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: variable size output (pages)?
Posted by Peter Coppens <pc...@gmail.com>.
Ic...so there is no way to know what the page size will have to be
until the layout has been completed?
On 06 May 2008, at 14:25, paul womack wrote:
> Peter Coppens wrote:
>> Can't you use different page masters and select the one that is
>> appropriate using some (XSLT) pre-processing?
>
> I'd need an almost infinite range of
> masters - the line count could vary from 5-350,
> and even line spacing could vary due to superscripts,
> subscripts, emboldening etc.
>
> So I think the answers no; in anycase, a two pass
> solution (via the area tree) is already
> my fall back option, but it feels
> like a dirty hack.
>
> BugBear
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: variable size output (pages)?
Posted by paul womack <pw...@papermule.co.uk>.
Peter Coppens wrote:
> Can't you use different page masters and select the one that is
> appropriate using some (XSLT) pre-processing?
I'd need an almost infinite range of
masters - the line count could vary from 5-350,
and even line spacing could vary due to superscripts,
subscripts, emboldening etc.
So I think the answers no; in anycase, a two pass
solution (via the area tree) is already
my fall back option, but it feels
like a dirty hack.
BugBear
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: variable size output (pages)?
Posted by Peter Coppens <pc...@gmail.com>.
Can't you use different page masters and select the one that is
appropriate using some (XSLT) pre-processing?
On 06 May 2008, at 14:16, paul womack wrote:
> I need to generate output (PDF) where the page
> size (actually just page depth) varies
> with the content.
>
> In effect I want to generate "galleys" of text,
> where the formatting width is known, but the depth
> of the final output is determined by the amount
> of text formatted, in effect fitting the page
> to the content.
>
> I have tried to search the documentation,
> but am greatly hampered by not knowing
> the terminology well enough to search effectively.
>
> It appears that I can "fake" what I want by
> either using imageprocessing to "autocrop"
> the output, or (possibly) by doing
> "something" to the XML area tree, and performing
> a second pass, but if there's a proper
> way to achieve my goal, that'd be great.
>
> I would welcome either advice, or simply
> a pointer to any relevant parts of the
> specification(s) or documentation.
>
> BugBear
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org