Ernst Bunders <[EMAIL PROTECTED]> wrote: > I move this thread to dev becouse i think there are some developer related > issues i would like to point out. > Last weekend i looked into the current imagemagic and JAI implementation and > allso in the imagemagick java api that Michiel mentioned as an option for a > third converter implementation. I find that the current situation is a bit > awkward, and maybe will need to be changed in the future, with massive > backwards-compatability issues: > > 1 there is a small number of commands that are being abstracted from > implementation. This set is allso the currently implemented in ConvertJAI. > Apart from this set all other commands are just passed to imagemagick on the > fly. Errors can not be cougt and if the imagemagick people would decide > (unlikely, but beyond hour control) to change these commands all > non-abstracted imagetemplates in mmabse templates would be broken.
I'm not sure whether this was a good idea. It seemed like a more or less sensible, because it's hopeless the wrap every single one of the massive number of options that imagemagick provides in an 'abstraction' of our own. And then also hope that we could implement then excactly the same as in imagemagick somewhere else. > 2 Due to an apperant change in java (1.4.1) specifications it is no longer > possible to pass characters outside the ascii set to imagemagick. This makes > all text functions of imagemagick pretty much useless. The current java api > supports a limited set of commmands and i think text is not supported (yet). Yes, this really sucks. I invested litteraly hours, if not days, to get text in images working (it was not possible at all before I did that), only to find out that all effort is rendered useless in this ****** java 1.4 > 3 If you would want to make a more complete JAI implementation you would > practically hav to rebuild imagemagick in java in order to ensure backwards > competability. > What dous this lead to? I think it is unfortunate that the abstraction of > commands in the image templates has been dropped. It is not mmbase-like > seems and it seems that we are stuck with one implementation (imagemagick), > and that implementation dous not function well anymore becouse of the > different behavour of Runtime.exec (in java 1.4.1). The other alternative was not to provide the options of imagemagick, in which case you can just as wel not use it. Furthermore, some of these 'abstractions' IIRC gave a kind of feel of compatibility which was not really there, because they only provide approximately the same result. > It is perhaps not an immediate problem, but still it is messy, and perhaps > needs some kind of attention. I'd go for ImageMagic only, with 'jai' only as a fall-back. This provides a lot of features, which we don't have to support. It's a real petty that Runtime.exec is useless nowadays in java, so we have to look for an alternative. I suppose the java-interface to imagemagick would supply the same features. Consicely, I think supporting both complete abstraction of the convert-interface (independent from the used 'templates'), and a reasonalbly rich set of features is impossible. The current situation of a limited set of features which are 'abstract' and everything else simple translates directly to imagesmagick is I think simple and maintainable, though it should perhaps be documented more explicitily that using image-magick-features makes your site dependent on it. Michiel -- Michiel Meeuwissen Mediapark C101 Hilversum +31 (0)35 6772979 nl_NL eo_XX en_US mihxil' [] ()
