Nobody is Here [2005-02-14 21:20 UTC] I think the Image_Drive could be really useful. IMO interoperability between the Image-Packages would be a great thing.
Jesper Veggerby [2005-02-28 07:04 UTC] Anybody?
Philippe Jausions [2005-03-06 19:26 UTC] Have you looked at the Image_Transform package? I see some related philosophy there.
-Philippe
Nobody is Here [2005-03-06 19:46 UTC] Philippe: Image_Transform just implements a driver concept. But the idea of Image_Driver is to provide a unified interface for functions like drawing lines, circles, etc. no matter if the output is an jpg, png or other file-format. Further it allows to share one driver in multiple packages to draw their output in the same image (think about a 3d representation - Image_Isomteric - of statistics - Image_Graph - rotated 90 degrees clockwise - Image_Transform).
Jesper Veggerby [2005-03-07 08:42 UTC] Rolf is right here, Image_Transform (AFAIK) performs actions on an already existing image where as Image_Driver is used for creating this image - it's basically the canvas with (as Rolf says) operations for painting on it.
The idea was to provide a common interface, so that developers of packages in the Images category, simply passes the drivers amongst each other to avoid:
1) Redundancy
2) Format independency
Think of Image_Graph passing a driver on to Image_Isometric "ordering" it to paint the 3D figures on it making out a cool 3D plot. Or maybe all Images packages passing their driver to Image_Text to write text, Image_Color to do the color handling, etc...
Jesper Veggerby [2005-03-07 08:46 UTC] That should of course not be "avoid" format independency, but "achieve" :)
Philippe Jausions [2005-03-07 15:46 UTC] Ok, I see what you mean... In this case the "Image_Driver" name doesn't seem to reflect that... Maybe "Image_Builder"...
Also, the statement "independent from GD" is a bit misleading. You do seem to require the GD extension to generate binary-based images. That statement made me think that you would generate any images with PHP interpreted code only...
I just want to make sure packages don't step on each other's toes, that would be a waste of resource... With all the Image_* packages going around, it would be best to put everybody's effort to reach a common goal. For instance a similar new package Image_Polygon was recently proposed... and another Image_XBM was just approved...
Yes, it would be good to define an image or piece of image with this package and passing it to another Image_* package for plotting or whatever...
If I ever get my CVS karma fixed so I can do some real work on Image_Transform, this is something I could look into...
So basically, I like the idea of this package, just the name and description would need retouch for me. Doordination with other (future and existing) Image_* packages is also very very essentials. We can't have PEAR have multiple Image_* package that can't talk to each other anymore.
-Philippe
Jesper Veggerby [2005-03-19 18:52 UTC] Philipe: I'm open for a name change, driver was "just" a good option, don't know if builder is the right one, but...
I see your point regarding the possible confusion the description can give, I'll be sure to give it a brush up! Thanks
/Jesper
With regards to Image_XBM I'm sure we can (easily?) create a driver (or whatever we'll call them) that enables users to use this package as well.
Alan Knowles [2005-03-21 02:17 UTC] Image_Canvas strikes me as a better name, the fact that it has drivers for backends seems less relivant than the intent of being able to do drawing stuff.
Jesper Veggerby [2005-03-21 18:47 UTC] Alan: That does seem like a fitting name. I'll rename first thing!
Jesper Veggerby [2005-07-11 17:51 UTC] With respect to the current voting on Image_3D I'd like to revive my proposal for Image_Canvas, since I can see cool aspects in having fx./in particular Image_3D and Image_Graph support this to create 3D graphs.
So please comments/ideas/input?! Just a note is the idea good or bad?
I just added a section on the main proposal page describing the current functionality to give perhaps a small overview to enable to comment on the proposal without necessarily having to do a deep source review (CS **should** be ok :))
/Jesper
Jesper Veggerby [2005-07-19 17:25 UTC] Any comments, before we'll have a go and see if the voting goes?
Alan Knowles [2005-07-20 08:19 UTC] You probably want provide links to the .phps of the code - makes everyones voting decissions easier.
Tobias Schlitt [2005-07-20 20:24 UTC] A few hints/wishes from my point of view:
- rename write() to addText()
- split done() save() and show()
- me personally hates functions with extremly long parameter lists, use arrays with speaking keys, that's more comfortable (or even better: offer the possibility to use a hashmap instead of single params, but allow this also)
Beside that, I like the package. :) Please get in touch with Kore regarding the use in Image_3D. I believe he has some more ideas.
Jesper Veggerby [2005-07-20 20:48 UTC] Toby:
If changing write() and done() means a +1 from you, then it's fine with me :)
Regarding your wish for arrays as parameters, I see the best/only use for them when having need for overloads.
Especially when having to document these arrays I find them a pain, but also having to write the extra (seemingly uncessary) array(..) bothers me, and even worse if it's "hashed".
But of course it offers greater flexibility, but at the high price of "clearness-of-code" (you can't just take the header of the method and understand the parameters)
However (after this looong speak against :)), in many methods (factory, done, setFont, etc), I already employ the use of associated arrays, so for the sake of consistency in the package I agree on your point and I will change them.
/Jesper
|
