Hi Jeremias,

Jeremias Maerki wrote:
> Hi Vincent
> 
> On 17.02.2009 11:22:05 Vincent Hennebert wrote:
>> Hi Jeremias,
>>
<snip/>
>>> - 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.

Right. My wording was a bit unfortunate, but I basically agree with what
you say below. In short: as long as that works, fine. As soon as that
starts creating maintenance issues, let’s consider to get rid of it.


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

Exactly. That’s more what I was meaning actually. It’s also a matter of
communication. We can clearly state on the website: “Due to our limited
resources we are sorry to inform you that we have to drop support for
this and this...” Open-source, everyone free to participate, etc.


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

That’s where I can clarify a bit: I believe distinction can be made here
between corporate users and others. Corporate users shipping FOP with
their commercial product can invest time/money in the maintenance of
those renderers that they need. I tend to think that licenses are not
really a problem for individual users (may be wrong though). The example
I have in mind: if for some reason I want to put a text output of some
sample document on the wiki, I’m happy to use pdftotext (Poppler, GPLv2)
instead of FOP.


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

I’m ok with that but the concerns I have is: what do we do when it stops
working just fine? If some changes are made to the area tree that impact
the renderers? I’m afraid of the maintenance burden on a middle/long
term. But that’s probably a question for later.


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

Hmmm... no ;-)
Good point indeed. I forgot about the layoutengine 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).

Let me refine my concerns: granted, Area Tree XML is still needed, if
only for layout tests. But do ‘external’ people still need to use it,
now that IF is available? I don’t know. Probably not.
In other terms: do we want the Area Tree XML to be usable from outside
the project, hence maintain features and backwards compatibility? Or can
we keep it internal, in which case we don’t have to worry about cutting
functionalities away or whatever. If that makes sense at all.


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

This is a step towards modularization. I’m all for it!


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

Good, good, good.


> 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

Thanks,
Vincent

Reply via email to