xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcin Tustin <marcin.tus...@gmail.com>
Subject Re: Producing & archiving FOP intermediate format
Date Tue, 14 Feb 2012 09:31:03 GMT
In general it is a poor idea to rely on undocumented or
software-specific formats for long term archival purposes. If you
always also store the FOP, then you're likely to be fine.

On Mon, Feb 13, 2012 at 23:24, Alexios Giotis <alex.giotis@gmail.com> wrote:
> Any thoughts or comments on this ? Of course, I don't expect anybody to make a commitment
that it will change in backwards compatible ways.
>
> Alexios
>
>
> On Feb 8, 2012, at 5:30 PM, Alexios Giotis wrote:
>
>> Hi,
>>
>> I am already storing some millions per month of files containing FOP intermediate
format (FOP_IF) using a private patched branch based on FOP 1.0. The current use case is performance.
If a document is found in the store containing FOP_IF, then use it and create the final output
format (typically PDF). If not, then start from XML. The retention period of the FOP_IF files
is 6 months to 1 year. The XML files are kept for at least 10 years. In my tests, 85% of the
time is spent on the layout and the rest for rendering. This has worked well, especially for
big documents (with thousands of pages). I have no worries about the FOP_IF format and how
it will evolve as I know that they will be gone after 6 months or one year max. And for sure,
I can keep an older version for that long.
>>
>> I am now planing to use FOP in different ways and use cases such as:
>>
>> 1. Bypassing FOP's layout engine and it's quirks in XSL:FO input, cpu-time and memory.
This means directly creating FOP_IF. With the same effort, I could use PDFBox (or iText 2.x)
to create PDF files. But having FOP_IF, I also produce AFP, PS and PCL which I need and I
know no other open sources renderers.
>>
>> 2. Longer storage of FOP_IF. Compared to storing XML, it's faster, less components
are involved until the final output and it allows for easier versioning. For example, given
the same XSL:FO input, FOP 2.0 will not produce the *identical* content as FOP 1.0 (I hope
somebody will disagree to this :) Compared to storing PDF, the required space is much less
as I have big volumes on expensive EMC storage. Secondly I retain the flexibility on selecting
parts to render. Not all users have the permissions to see all parts of the documents. Also,
some users see masked values (e.g. stars in place of a card number).
>>
>>
>> For both cases, I really need to know your thoughts and plans for FOP_IF. Watching
the lists the last 2 years, I have not noticed anything related to it.
>>
>>
>> Greetings,
>> Alexios Giotis
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>



-- 
Marcin Tustin
Tel: 07773 787 105

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Mime
View raw message