Re: [PROPOSAL] multi-page image extension for FOP

[The Web Maestro]

On 12/20/07, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> I've been playing with the idea for some time and the time has come to
> bring this up. I would like to write an FO extension which allows to
> insert a multi-page document into an FO document, so each page produces
> a new page of exactly the same dimensions as the bitmap image in the
> final format (by default). With fo:external-graphic it's only possible
> to embed one single image somewhere inline. Of course, it's possible to
> position the fo:external-graphic so it takes up the whole page and you
> can even address individual pages (#page=3) with the new image
> package but you'd still need to know at least the number of pages at
> XSLT time to get this right. Instead, I'd like to do this with a single
> extension element on the same level as fo:page-sequence. I've called it
> fox:external-document for now. Here's the proposed specification:



> While writing this it occurred to me that this could also be implemented
> as an FO-preprocessor (SAX filter). However, since this proprocessor
> would have to generate page masters depending on the images which have
> to be inserted at the beginning of the FO file, this could be
> inefficient. The only benefits I see is that it could be used with other
> FO implementations, too, and that it wouldn't add code to FOP which has
> to be maintained. So, I would prefer to implement this as a layout
> manager.
>
> I know this is again something that doesn't really bring FOP closer to
> version 1.0. Again, it's simply coming from people using FOP on a
> day-to-day basis.
>
> WDYT?
>
> Jeremias Maerki

Looks interesting... I recall wishing 0.20.5 had something like this
back in the day. +1 from me.

-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: [PROPOSAL] multi-page image extension for FOP

[Jeremias Maerki]

On 21.12.2007 16:01:22 Vincent Hennebert wrote:
> Hi,
> 
> In theory this would be more logical to finish implementing the features
> that the spec does describe. However, I can hear the business
> motivations behind this proposal. I have nothing against it, I just
> won’t try and make a big effort to provide support (either dev or user).
> 
> So this is a +0 from me.
> 
> A few comments inline.
> 
> Jeremias Maerki a écrit :
> 
> > :
> > Value: auto | 
> > Default: "auto" which means all pages of the document.
> > integer-range allows values such as "7" or "1-3"
> 
> What about 1,3-5,7,11-? :-P

I want to keep it simple for now. Adding that later will be easy.

> > Benefits of the extension:
> > - It is mostly useful for multi-page TIFF files (scanned documents and
> > faxes) and PDFs (with my PDF-in-PDF plug-in).
> > - It removes the necessity to post-process the generated output file
> > (for example with PDFBox or iText).
> 
> But PDFBox will still be necessary to insert the external document in
> the sequence of pages? Just curious.

If you want to insert a PDF file, yes, my plug-in and PDFBox will be
necessary. But for inserting multi-page TIFFs (faxes, for example),
PDFBox won't be necessary as I strictly use the features of our existing
area tree to position the images. The new ExternalDocumentLayoutManager
simply creates a new page sequence in the area tree with the minimal
elements necessary to paint the image. The individual sub-images will be
addressed using URIs in the form:
http://localhost/images/myimage.tif#page=3

> 
> > While writing this it occurred to me that this could also be implemented
> > as an FO-preprocessor (SAX filter). However, since this proprocessor
> > would have to generate page masters depending on the images which have
> > to be inserted at the beginning of the FO file, this could be
> > inefficient. The only benefits I see is that it could be used with other
> > FO implementations, too,
> 
> Do we really care about that? :-P  “Sorry, it only works with FOP,
> you’ll have to use FOP to benefit from this feature.” Isn’t that
> a shame.

Hehe.

> 
> > and that it wouldn't add code to FOP which has
> > to be maintained. So, I would prefer to implement this as a layout
> > manager.
> 
> As long as it doesn’t turn the current architecture upside down. But
> I guess it won’t, will it?

No, the implementation was quite easy and relatively non-invasive.
However, I've created a new superclass for PageSequence and
PageSequenceLayoutManager which fleshes out shared functionality and
fields into a common base class, for example, for the whole page number
and ID handling. That could mean some increased complexity in
understanding the PageSequenceLayoutManager but it also could also be
the opposite since the topics are better grouped together: ID handling,
page production, layout control

> > I know this is again something that doesn't really bring FOP closer to
> > version 1.0. Again, it's simply coming from people using FOP on a
> > day-to-day basis.
> 
> Which makes FOP live, anyway.
> 
> 
> > WDYT?
> 
> Have fun ;-)

Fun's already over. It's working. But more fun is waiting. And having a
few days off will be fun, too.

Jeremias Maerki

Re: [PROPOSAL] multi-page image extension for FOP

[Jeremias Maerki]

FYI, I've now already got working code for FOP Trunk including
documentation but without multi-page support which I'll add in the image
package branch. I know it's nearly weekend and Christmas but I'd still
like to commit this by next Wednesday or Thursday. So if anyone has
anything against this please let me know.

On 20.12.2007 10:38:05 Jeremias Maerki wrote:
> I've been playing with the idea for some time and the time has come to
> bring this up. I would like to write an FO extension which allows to
> insert a multi-page document into an FO document, so each page produces
> a new page of exactly the same dimensions as the bitmap image in the
> final format (by default). With fo:external-graphic it's only possible
> to embed one single image somewhere inline. Of course, it's possible to
> position the fo:external-graphic so it takes up the whole page and you
> can even address individual pages (#page=3) with the new image
> package but you'd still need to know at least the number of pages at
> XSLT time to get this right. Instead, I'd like to do this with a single
> extension element on the same level as fo:page-sequence. I've called it
> fox:external-document for now. Here's the proposed specification:
> 
> fox:external-document
> 
> Child of: fo:root
> Contents of fo:root would be changed to this:
> (layout-master-set,declarations?,bookmark-tree?,(page-sequence|page-sequence-wrapper|fox:external-document)+)
> 
> The fo:external-document extension element is used to generate a
> (sub-)sequence of pages where each page will contain the necessary areas
> to display each page of a potentially multi-page document on a separate
> page.
> 
> The size of each sub-image will define the size of the page it generates
> unless the width, height, content-width, content-height properties are
> used.
> 
> Contents:
> EMPTY
> 
> The following properties apply:
> - (Common Accessibility Properties)
> - (Common Aural Properties)
> - block-progression-dimension
> - content-height
> - content-type
> - content-width
> - display-align
> - height
> - id
> - inline-progression-dimension
> - overflow
> - pages:  (see below)
> - reference-orientation
> - scaling
> - scaling-method
> - src
> - text-align
> - width
> 
> :
> Value: auto | 
> Default: "auto" which means all pages of the document.
> integer-range allows values such as "7" or "1-3"
> 
> Benefits of the extension:
> - It is mostly useful for multi-page TIFF files (scanned documents and
> faxes) and PDFs (with my PDF-in-PDF plug-in).
> - It removes the necessity to post-process the generated output file
> (for example with PDFBox or iText). It's not necessary to implement this
> post-processing for each output format in use and it's not necessary to
> manually play with the intermediate format to add this functionality.
> - Attaching existing PDF files to PDFs generated by FOP has been a
> frequent topic on fop-users.
> - FOP could be used this way to convert multi-page TIFF files to PDF or
> whatever output formats FOP supports. We could provide a command-line
> option for that if we want.
> 
> While writing this it occurred to me that this could also be implemented
> as an FO-preprocessor (SAX filter). However, since this proprocessor
> would have to generate page masters depending on the images which have
> to be inserted at the beginning of the FO file, this could be
> inefficient. The only benefits I see is that it could be used with other
> FO implementations, too, and that it wouldn't add code to FOP which has
> to be maintained. So, I would prefer to implement this as a layout
> manager.
> 
> I know this is again something that doesn't really bring FOP closer to
> version 1.0. Again, it's simply coming from people using FOP on a
> day-to-day basis.
> 
> WDYT?
> 
> Jeremias Maerki
> 




Jeremias Maerki

Re: [PROPOSAL] multi-page image extension for FOP

[Vincent Hennebert]

Hi,

In theory this would be more logical to finish implementing the features
that the spec does describe. However, I can hear the business
motivations behind this proposal. I have nothing against it, I just
won’t try and make a big effort to provide support (either dev or user).

So this is a +0 from me.

A few comments inline.

Jeremias Maerki a écrit :

> :
> Value: auto | 
> Default: "auto" which means all pages of the document.
> integer-range allows values such as "7" or "1-3"

What about 1,3-5,7,11-? :-P

> Benefits of the extension:
> - It is mostly useful for multi-page TIFF files (scanned documents and
> faxes) and PDFs (with my PDF-in-PDF plug-in).
> - It removes the necessity to post-process the generated output file
> (for example with PDFBox or iText).

But PDFBox will still be necessary to insert the external document in
the sequence of pages? Just curious.


> While writing this it occurred to me that this could also be implemented
> as an FO-preprocessor (SAX filter). However, since this proprocessor
> would have to generate page masters depending on the images which have
> to be inserted at the beginning of the FO file, this could be
> inefficient. The only benefits I see is that it could be used with other
> FO implementations, too,

Do we really care about that? :-P  “Sorry, it only works with FOP,
you’ll have to use FOP to benefit from this feature.” Isn’t that
a shame.


> and that it wouldn't add code to FOP which has
> to be maintained. So, I would prefer to implement this as a layout
> manager.

As long as it doesn’t turn the current architecture upside down. But
I guess it won’t, will it?


> I know this is again something that doesn't really bring FOP closer to
> version 1.0. Again, it's simply coming from people using FOP on a
> day-to-day basis.

Which makes FOP live, anyway.


> WDYT?

Have fun ;-)


Vincent

-- 
Vincent HennebertAnyware Technologies
http://people.apache.org/~vhennebert http://www.anyware-tech.com
Apache FOP Committer FOP Development/Consulting

Re: [PROPOSAL] multi-page image extension for FOP

[Chris Bowditch]

Jeremias Maerki wrote:


I've been playing with the idea for some time and the time has come to
bring this up. I would like to write an FO extension which allows to
insert a multi-page document into an FO document, so each page produces
a new page of exactly the same dimensions as the bitmap image in the
final format (by default). With fo:external-graphic it's only possible
to embed one single image somewhere inline. Of course, it's possible to
position the fo:external-graphic so it takes up the whole page and you
can even address individual pages (#page=3) with the new image
package but you'd still need to know at least the number of pages at
XSLT time to get this right. Instead, I'd like to do this with a single
extension element on the same level as fo:page-sequence. I've called it
fox:external-document for now. Here's the proposed specification:


+1 from me. This is a good idea. There is a definitive business 
requirement for being able to process multi-page Tiffs and PDFs.


My application already uses pre-processors to split up multi-page Tiff 
and PDFs, so if the FO Formatter does it then it saves me the bother. 
Also the ability to vary the pages based on the images actual size is a 
level of flexbility my pre-processor currently doesn't support.


Chris

Re: [PROPOSAL] multi-page image extension for FOP

[Manuel Mall]

On Thursday 20 December 2007 18:38, Jeremias Maerki wrote:
 
>Benefits of the extension:
> - It is mostly useful for multi-page TIFF files (scanned documents
> and faxes) and PDFs (with my PDF-in-PDF plug-in).
> - It removes the necessity to post-process the generated output file
> (for example with PDFBox or iText). It's not necessary to implement
> this post-processing for each output format in use and it's not
> necessary to manually play with the intermediate format to add this
> functionality. - Attaching existing PDF files to PDFs generated by
> FOP has been a frequent topic on fop-users.
> - FOP could be used this way to convert multi-page TIFF files to PDF
> or whatever output formats FOP supports. We could provide a
> command-line option for that if we want.
>

> WDYT?
>
In the main business application of FOP I am supporting this feature 
would be of immediate benefit as we are processing bundles of scanned 
and/or faxed documents and we have to artificially split the multi-page 
images into individual one page images so they can be processed by FOP.

So I am all for it.

> Jeremias Maerki

Manuel

[PROPOSAL] multi-page image extension for FOP

[Jeremias Maerki]

I've been playing with the idea for some time and the time has come to
bring this up. I would like to write an FO extension which allows to
insert a multi-page document into an FO document, so each page produces
a new page of exactly the same dimensions as the bitmap image in the
final format (by default). With fo:external-graphic it's only possible
to embed one single image somewhere inline. Of course, it's possible to
position the fo:external-graphic so it takes up the whole page and you
can even address individual pages (#page=3) with the new image
package but you'd still need to know at least the number of pages at
XSLT time to get this right. Instead, I'd like to do this with a single
extension element on the same level as fo:page-sequence. I've called it
fox:external-document for now. Here's the proposed specification:

fox:external-document

Child of: fo:root
Contents of fo:root would be changed to this:
(layout-master-set,declarations?,bookmark-tree?,(page-sequence|page-sequence-wrapper|fox:external-document)+)

The fo:external-document extension element is used to generate a
(sub-)sequence of pages where each page will contain the necessary areas
to display each page of a potentially multi-page document on a separate
page.

The size of each sub-image will define the size of the page it generates
unless the width, height, content-width, content-height properties are
used.

Contents:
EMPTY

The following properties apply:
- (Common Accessibility Properties)
- (Common Aural Properties)
- block-progression-dimension
- content-height
- content-type
- content-width
- display-align
- height
- id
- inline-progression-dimension
- overflow
- pages:  (see below)
- reference-orientation
- scaling
- scaling-method
- src
- text-align
- width

:
Value: auto | 
Default: "auto" which means all pages of the document.
integer-range allows values such as "7" or "1-3"

Benefits of the extension:
- It is mostly useful for multi-page TIFF files (scanned documents and
faxes) and PDFs (with my PDF-in-PDF plug-in).
- It removes the necessity to post-process the generated output file
(for example with PDFBox or iText). It's not necessary to implement this
post-processing for each output format in use and it's not necessary to
manually play with the intermediate format to add this functionality.
- Attaching existing PDF files to PDFs generated by FOP has been a
frequent topic on fop-users.
- FOP could be used this way to convert multi-page TIFF files to PDF or
whatever output formats FOP supports. We could provide a command-line
option for that if we want.

While writing this it occurred to me that this could also be implemented
as an FO-preprocessor (SAX filter). However, since this proprocessor
would have to generate page masters depending on the images which have
to be inserted at the beginning of the FO file, this could be
inefficient. The only benefits I see is that it could be used with other
FO implementations, too, and that it wouldn't add code to FOP which has
to be maintained. So, I would prefer to implement this as a layout
manager.

I know this is again something that doesn't really bring FOP closer to
version 1.0. Again, it's simply coming from people using FOP on a
day-to-day basis.

WDYT?

Jeremias Maerki