2011/9/22 Carnë Draug <carandr...@gmail.com>: > 2011/9/21 Philip Nienhuis <pr.nienh...@hccnet.nl>: >> Carnė Draug wrote: >>> >>> Hi Philip, >>> >>> an user (Juan Pablo Carbajal) has recently submitted some new >>> functions for inclusion in octave-forge to load SVG files. While in >>> the original request he mentioned the image package, I have recently >>> talked to him on #octave and he mentioned maybe the IO package would >>> be more appropriate. I was going to commit them to the package but >>> would like to know if you find them suitable for inclusion on the >>> package since you are its maintainer. They can be downloaded from the >>> feature request tracker on SF >>> >>> https://sourceforge.net/tracker/download.php?group_id=2888&atid=352888&file_id=423885&aid=3410112 >> >> Having had a quick look, I wouldn't be sure what the best place would be. >> >> Are the returned SVG structures only, or predominantly, useful within the >> scope of image processing? >> => if Yes, IMO the image pkg would be more appropriate >> => if No, the io pkg could be used. >> In either case a separate "svg" section would be appropriate. > > I don't think they will ever be used in the realm of image processing. > But I also see that it doesn't fit on the IO package perfectly. It > occurred to me now, that maybe a new package, geometry, would be > appropriate for the following reasons. Juan has also submitted some > other functions > (http://sourceforge.net/tracker/download.php?group_id=2888&atid=352888&file_id=423886&aid=3410135) > that would maybe fit nicely there (he originally suggested to include > them in the msh packeg). I also understand that he tried to get in > contact with the devs of matGeom and intends to make them work > properly in octave (and those could all go in a geometry package). > Finnaly, it's a large enough field and octave-core also has a group > for them. > >> Regardless of what the files do, I don't know what they are used for, or can >> be used for, or are intended to be used for, so I can't maintain them >> anyway. >> But OK let's say I only maintain the "package" (= the "container") :-) > > That's what I meant yes. I wouldn't dream of imposing anyone with > maintaining somebody else's code. Apologies if it sounded otherwise. > > On 21 September 2011 21:59, Juan Pablo Carbajal <carba...@ifi.uzh.ch> wrote: >> Regarding the maintenance of the files. I can offer to send new >> versions and extensions as they are generated. I wouldn't qualify for >> a maintainer of any of the two packages. > > Juan, since you are their creator and can see their objective and > usage better than anyone, what do you think about having a geometry > package for them functions? Would the other ones from data2geo and > matGeom also fit better there? > > Carnë > Dear all,
Definitely, I think putting all this functions inside a geometry package is the best. data2geo and SVG functions can go in a sub set "Input / Output". Shall I prepare the package? Best regards, -- M. Sc. Juan Pablo Carbajal ----- PhD Student University of Zürich http://ailab.ifi.uzh.ch/carbajal/ ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
