xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mehdi houshmand <med1...@gmail.com>
Subject Re: Producing & archiving FOP intermediate format
Date Tue, 14 Feb 2012 08:23:35 GMT
Hi Alex,

I'm not 100% what you're asking here, I must say. If it's more of a
general question of backward compatibility, then I think  we get back
to a topic of discussion we've been having lately about FOPs API. I'd
argue that IF itself is part of FOPs API (though I wouldn't make the
same argument for the Area-Tree), since it's so widely used and we
need to maintain some semblance of compatibility.

However, and this is a big caveat, at what cost? At what cost do we
want to maintain compatibility? I think if there's a compelling reason
it's OK to break compatibility, which obviously affects users like
yourself. As a user, you have to mitigate that risk, by either locking
down the FOP version or holding onto the XSL-FO (obviously not valid
if you're creating custom IF). As a more general argument, it really
isn't in the interest of broader user-base that FOP 1.0 and 2.0 create
identical output be that IF or PDF/AFP/whatever; FOP is evolving,
there will be new features added, bugs fixed etc, all of which change
the output. If I'm not mistaken, the new TaggedPDF branch merge, will
create IF that's incompatible with previous versions (breaking both
backward and forward compatibility). However this was well justified,
since the previous accessibility architecture was limited in design an
we were really pushing against the glass ceiling in terms of features.

Apologies if that hasn't been a particularly helpful answer, but if
you're wanting some reassurance that there won't be gratuitous changes
to IF, or some transparency on plans to rip apart IF structure, then I
can tell we don't plan either. However, we don't have the regression
tests to guarantee backwards compatibility, and I don't think having
them is a good idea.

As a side note, I do think if anyone changes IF in a way that breaks
compatibility, that will be made publicly clear, and it will be
discussed on fop-dev (if you haven't subscribed to that, I'd advise
you do). The community will decide whether said change is acceptable,
and discuss the cost/reward of such a change.

Mehdi

On 13 February 2012 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
>

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