>>>>> "JM" == Jeremias Maerki <[EMAIL PROTECTED]> writes:
>> FOP is a special customer and I am actually quite surprised that
>> you are creating subclasses of GraphicsNode (I understand what is
>> being done there but I could have suggested a couple of 'better'
>> ways to do it I think).
JM> Well, it's the way it is done now. It would be great if you could
JM> outline better ways to do what we need to do.
I would have simply attached the JpegImage as a rendering hint on
the standard Batik RasterImageNode. Then the PDF Graphics can check
if the hint is present when drawImage is called, if so use that hint.
Alternately, I would have derived off the existing RasterImageNode (a
known concrete class) rather than creating a new subclass of an
abstract class.
Both of these preserve the normal workings of the rendering engine
yet enables you to annotate the GraphicsNode tree with your additional
information.
We also should have made the construction of the
RasterImageGraphcisNode a method you could easily override.
>> I don't think Batik is in a position to do this yet. I would say
>> that when 1.5 goes final we might be willing to offer that
>> assurance for releases in the '1.5' branch. But we still need at
>> some point to support SMIL Animation I can guarantee you that this
>> will involve incompatible API changes/extensions/etc.
JM> Sounds to me like some problems could be avoided by separating
JM> non-interactive and interactive APIs. Like subclassing
JM> AbstractGraphicsNode to AbstractInteractiveGraphicsNode (which
JM> contains the getSensitiveBound() method). Just a thought, I'm not
JM> familiar enough with Batik.
If we had done this from the start this might have helped FOP in
this particular case but the addition still would have hurt anyone
extending the existing dynamic portion of Batik. So it might have
limited the impact but it would not have eliminated it, and I had
already considered the fact that the impact was limited to people who
were extending GraphicsNode which is already a _very_small_ population
AFAIK (as I said I was a bit surprised that even FOP, who I knew was
pretty deeply involved with Batik, was extending Graphics Nodes).
JM> With my findings above I think it would even make sense to have an
JM> additional mechanism to check binary compatibility (just some
JM> runtime tests using JUnit, for example) between projects (CVS of
JM> project 1 against release xy of project 2).
>> Binary compatibility is really, really hard to ensure and I think
>> it only makes sense on 'point' releases, so 1.5 and 1.5.1 _should_
>> be binary compatible, 1.5 and 1.6 may not be (and similarly 1.5b4
>> and 1.5b5 do not need to be) - all of course IMHO - other Batik
>> developers may (and probably will :) disagree.
JM> Batik's in beta mode, FOP's in release candidate mode....for a
JM> very long time. :-) That basically makes each beta/rc releases
JM> quite important. But you're right, except that I would expect
JM> compatibility over a full version (1.x).
This then just becomes a 'naming issue'.
JM> I think you're missing my point about that idea: Testing a project
JM> CVS against dependent releases may be a good way to make a
JM> developer think twice (TM). That's basically the only thing I
JM> ask. Anyway, it was just an idea.
I think it's better of developers just think twice (TM). BTW I
did think twice about about this change but it really is needed. I am
sorry about the trouble.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
