Getting Rid of Jimi

[Thomas DeWeese <Th...@Kodak.com>]

Hi all,

    It is certainly true that javax.imageio is the direction
to go in the future.

    However, It is probably worth pointing out that you already
include a PNG encoder/decoder with the FOP distribution,
from Batik!

      org.apache.batik.ext.awt.image.codec.PNGImageEncoder
      org.apache.batik.ext.awt.image.codec.PNGImageDecoder


    Let me know if you want/need more info (including pointers
to where FOP does the image loading would be helpful as well).

Jeremias Maerki <de...@greenmail.ch>

> No apologies required!
> 
> Image IO (javax.imageio) support is not there, yet, I'm afraid. But if
> you created an implementation for Image IO then your idea would work.
> Shouldn't be very hard. Check the org.apache.fop.image package. You
> wouldn't need to use JIMI. Think of JIMI, JAI and ImageIO as equals.
> They all provide an API to access bitmap images.
> 
> 
> On 23.01.2004 16:08:55 Dalibor Topic wrote:
>> > A possible work-around is to establish a better plug-in concept for our
>> > image lib adapters in HEAD (not 0.20.5) so interested parties can create
>> > plug-ins outside of the ASF to use LGPL libraries.
>> 
>> I'm not very well aware of the differences between all the different 
>> image io APIs, so please excuse me if my next question is a typical 
>> newbie question. If, for example, we had javax.imageio support working 
>> for PNG images in GNU Classpath (and Kaffe), would/could FOP 
>> automatically use that, or would it still need to use JIMI?
>> 
>> The reasoning behind this being that PNG image support seems to be part 
>> of JDK 1.4 anyway, so it will be implemented in free runtimes eventually 
>> as well.

Re: Getting rid of JIMI

[Glen Mazza <gr...@yahoo.com>]

Very classy response.  (You're getting good at knowing
how to handle me... ;-)

Glen

--- Jeremias Maerki <de...@greenmail.ch> wrote:
> Noted. I will make it a point in the proposal so the
> Batik people will
> be able to comment and we can develop mechnisms to
> ensure quality.
> 
> On 25.01.2004 18:42:20 Glen Mazza wrote:
> > The current (lowered) committer standards on the
> FOP
> > team definitely needs to be explained to the Batik
> > team before we get write access to their
> > project--something I'm still far from
> recommending. 
> > Jeremias, being perhaps the leading proponent of
> the
> > new committer standards, is probably in the best
> > position to explain this to Thomas--I still don't
> > understand it myself.
> 
> 
> Jeremias Maerki
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

Re: Getting rid of JIMI

[Jeremias Maerki <de...@greenmail.ch>]

Noted. I will make it a point in the proposal so the Batik people will
be able to comment and we can develop mechnisms to ensure quality.

On 25.01.2004 18:42:20 Glen Mazza wrote:
> The current (lowered) committer standards on the FOP
> team definitely needs to be explained to the Batik
> team before we get write access to their
> project--something I'm still far from recommending. 
> Jeremias, being perhaps the leading proponent of the
> new committer standards, is probably in the best
> position to explain this to Thomas--I still don't
> understand it myself.


Jeremias Maerki

Re: Getting rid of JIMI

["J.Pietschmann" <j3...@yahoo.de>]

Jeremias Maerki wrote:
> I will probably have some time next month to write a proposal on how our
> two projects can move closer together to make the code sharing happen.

Stuff that comes to mind immediately:
- fonts, metrics, character and word width
- various configuration stuff
- character normalization and line breaking (for SVG flow text)
- command line wrapper
- common area rendering
- embedded images, of course
- API concerns, as discussed: hooks for custom resolvers for fonts,
  images, URLs in general

J.Pietschmann

Re: Getting rid of JIMI

[Glen Mazza <gr...@yahoo.com>]

--- Jeremias Maerki <de...@greenmail.ch> wrote:
> 
> I will probably have some time next month to write a
> proposal on how our
> two projects can move closer together to make the
> code sharing happen.
> 
> Jeremias Maerki
> 

Ummm...Jeremias, remember, your recent nominations for
FOP committers included those who don't even know Java
[1][2] and haven't submitted any code patches (and
barely any--*if* any--doc patches at that.)  Per you
and Joerg's new standards, to be a committer on the
FOP team, just being helpful on the mailing lists
suffices.[3]

The Batik team, like Xalan, Struts, HTTPD, and other
successful projects, however, still keeps programmatic
committer standards and pretty high ones at that. 
(Take a look at the solid backgrounds of the Batik
committers [4], for example.)  To protect their user
base and their excellent products, they don't
gratuitously (and dangerously) hand out write access
to people as tokens of appreciation.

If you and Joerg want to insist on committers who
haven't even learned CVS and Ant yet, then interfacing
with other teams is going to be problematic, if only
for the safety of their code.  I wish you had both
thought out the consequences beforehand (I certainly
didn't appreciate being made into the "mean one" on
this issue)--regardless, the Batik team should be
aware of this issue.

The current (lowered) committer standards on the FOP
team definitely needs to be explained to the Batik
team before we get write access to their
project--something I'm still far from recommending. 
Jeremias, being perhaps the leading proponent of the
new committer standards, is probably in the best
position to explain this to Thomas--I still don't
understand it myself.

Glen

[1]
http://marc.theaimsgroup.com/?l=fop-dev&m=106640132114490&w=2
[2]
http://marc.theaimsgroup.com/?l=fop-dev&m=107262232610618&w=2
[3]
http://marc.theaimsgroup.com/?l=fop-dev&m=107271927618049&w=2
[4] http://xml.apache.org/batik/whoAreWe.html

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

Re: Getting rid of JIMI

[Jeremias Maerki <de...@greenmail.ch>]

On 25.01.2004 12:46:08 Thomas DeWeese wrote:
> Jeremias Maerki <de...@greenmail.ch> wrote:
> 
> > Damn, you're right. I wonder why we haven't made use of this, yet. BTW,
> > is this code from JAI (like the classes Oleg Tkachenko uses in his TIFF
> > renderer) or is this separately developed code (ASF origin)?
> 
>     This was contributed by Sun and is I believe the code came
> from JAI (great group of guys).  There have been some bug
> fixes/improvements since then but it is basically that code.
> 
> > You know that there's a number of people who would actually be
> > interested in creating/having a BSD-style image (codec) library? 
> 
>    Sure, but given imageio does it make sense to put a lot of
> effort into an independent codec library?  If I were going to
> create a codec library I would create one that plugged into
> image-io.

I agree that the codec library should plug into ImageIO, but this API
is only available since JDK 1.4. I'm sure that if there's enough
interest in supporting the image library under pre-1.4 JDKs there will
be contributions to make that happen. No need to lose too much time if
it's not needed at first.

> > I think that should be one of the packages that should be separated 
> > out, when FOP and Batik get closer together.
> 
>     This probably makes sense.

I will probably have some time next month to write a proposal on how our
two projects can move closer together to make the code sharing happen.


Jeremias Maerki

Re: Getting Rid of Jimi

[Jeremias Maerki <de...@greenmail.ch>]

Damn, you're right. I wonder why we haven't made use of this, yet. BTW,
is this code from JAI (like the classes Oleg Tkachenko uses in his TIFF
renderer) or is this separately developed code (ASF origin)?

You know that there's a number of people who would actually be
interested in creating/having a BSD-style image (codec) library? I think
that should be one of the packages that should be separated out, when
FOP and Batik get closer together.

On 24.01.2004 12:21:48 Thomas DeWeese wrote:
>     It is certainly true that javax.imageio is the direction
> to go in the future.
> 
>     However, It is probably worth pointing out that you already
> include a PNG encoder/decoder with the FOP distribution,
> from Batik!
> 
>       org.apache.batik.ext.awt.image.codec.PNGImageEncoder
>       org.apache.batik.ext.awt.image.codec.PNGImageDecoder
> 
> 
>     Let me know if you want/need more info (including pointers
> to where FOP does the image loading would be helpful as well).

Jeremias Maerki