Hi Vincent On 17.02.2009 11:22:05 Vincent Hennebert wrote: > Hi Jeremias, > > My general view: we want to get rid of Renderers as soon as possible. We > don’t have enough resources to maintain two different rendering paths. > As far as I’m concerned, I don’t have knowledge about the rendering > stage. But if I ever had to work on that area, and now that > IFDocumentHandler exists, I would be strongly reluctant to invest any > time in the Renderer path.
I mostly agree. However, I'd say: I'd like to get rid of the Renderers for which we have equivalent (if not better) IF implementations. > As to your more specific questions: > > Jeremias Maerki wrote: > > Follow-up issues for after the merge where I'd be glad for feedback: > > > > - The new implementations currently all use a MIME suffix ";mode=painter". > > They are now sufficiently tested that I'm confident that we can switch > > over to them by default. One idea would be to put a switch in > > RendererFactory so we can say: prefer IFDocumentHandler instead of > > Renderer implementation. Or rather the opposite: by default use the > > IFDocumentHandler but allow to switch to the old mode should there be an > > unexpected incompatibility. Good idea or bad? > > Is that realistic to do it this way: no switch, we directly use > IFDocumentHandler, any rendering difference is a bug that shall be > corrected sooner rather than later. Anyway, we will first release a beta > version for that very purpose IIC. I believe that's a possible and realistic way. Not a bad one either. Just a bit more daring than my proposal. Maybe I'm too cautious. > If that really is unfeasible, then +1 to your latter proposal: > IFDocumentHandler by default, with a possibility to fall back to the old > Renderer if really necessary. > > > > - Given the performance figures I think it would be possible to > > deprecate the following implementations: PDF, PS, PCL and AFP. As for > > the Java2D implementations: the PNG, Print and AWT Preview parts are not > > implemented, yet, so a deprecation here is premature. TXT is probably > > good enough like it is. No change necessary there. After all, we won't > > deprecate the Renderer interface itself. Good idea or bad? > > Well, I think it’s perfect time for reconsidering which outputs we > really want to support. For me, that should be outputs for which there > is commercial support, I do commercial support for all of them if I get asked. ;-) Anyway, I don't think it's in the ASF spirit to make that dependent on the availability of commercial support. > or for which there is a large user base, or an Only measurable by user survey. And I'm not sure that would be representative. But then, who doesn't participate doesn't get to have a say. > active committer willing to maintain them. Which means: do we care about > PNG and TXT? Having PNG is a no-brainer if TIFF is already around. Just a few lines of code. I'm certain there are people who can use that. It just wasn't high on my priority list which is why I put that off. Give me a rainy Sunday and it's back in. As for TXT, I got the impression that there are still people who use that. Not many, granted. And also nobody complained when some special features were cut out a while back (did anyone other than me notice?). Basically, as long as no changes in the renderer layer are necessary I see no reason to just drop that support. The TXTRenderer did get some attention in the past year. > Both can easily be obtained from PDF. With software under a similar license as Apache FOP? I don't think so. PDFBox is getting there but right now I wouldn't just position it as a replacement. Furthermore, a two-step process is always slower than a direct approach. > Let’s make a poll on > fop-users, and abandon those that don’t attract enough interest. Those > users whose business critically depends on a particular output can I don't think we should just focus on the business side. There are other users, too. > always make sure that it gets moved into the ‘commercially supported’ > category. (Same question about Print and AWT, although I believe they > fall into one of the first two categories.) Print and AWT should be relatively easy to port. Maybe another rainy Sunday... Until then, the existing code works just fine. > Why wouldn’t we deprecate the Renderer interface? Does it have any > feature that the new interface can’t provide? Let’s deprecate it, and > remove it after ‘enough time’ has passed. That's not so easy. The Renderer layer contains functionality that the IF layer doesn't have: it converts the relative placement of areas to absolute marks. You could of course move that into the layout managers but that would change (or make obsolete) the area tree. Good on one side, but on the other side, that's a lot of work and our entire test suite depends on that. Imagine updating the checks for 500 tests. It also needs to be noted, that the new IF contains less information than the Area Tree XML. For layout engine tests, the Area Tree XML is still more attractive (although you can now write tests for both). People doing two-pass processing might still prefer the area tree XML in certain cases (I don't know). Just an idea: What about moving out the various output formats (especially AFP, since it's so big and used only by a few) to separate source trees? A "FOP Core" plus n output plug-ins. TXTRenderer could be on of them. It would be moved out and if for some reason it lagged behind because of any changes in the core, someone really interested could bring it back more easily than when we just remove it. I don't really like removing functionality that some people have invested a lot of time in. If it gets in the way, something can be done about it but I don't think TXTRenderer is in our way. At least I don't have a problem with it sticking around. And I see no imminent reasons for changing the Renderer layer now that we have the new IF. <snip what="JEuclid part"/> Jeremias Maerki
