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 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
