After working on implementing the A* path finding Algorithm in Xojo I will take a look at that. Thank you again!
I think the ideal scenario for me would be to be able to export an SVG from Illustrator, drag it into Xojo and then reference that as the icon in a WebToolbarButton or similar.
Another problem is the support of the “collaborative svg project” while the time ellapsed.
It would be good, if a collaborative effort is done, to be able to give the baby to Xojo, so they will be able to re-check the sources and to add it into Xojo and support it by themselves.
Your feeling ?
Remember the feature request (written by) dates from: Roger Meier on 4 janv. 2010 at 02:19.
[quote=121032:@Ian Jones]I think the ideal scenario for me would be to be able to export an SVG from Illustrator, drag it into Xojo and then reference that as the icon in a WebToolbarButton or similar.
[/quote]
For that one would likely need the full SVG spec implemented…
What Norm is taking about is just supporting what Object2D’s can to which is much more limited.
IMO in general to have good vector graphics capacities, at a minimum Object2D would need to also support gradients and patterned lines. That would be useful even without SVG support.
- Karen
As Norman has indicated, exporting Object2D structures to SVG is simple, as is reading back the SVG thus generated as O2D. Making available a module that does this would enable any Xojo program using O2D to export SVG for use in HTML5 browsers and graphics editors that support SVG. It would also enable Xojo programs to exchange O2D graphics through the clipboard/pasteboard.
As a check on this, I jwrote a simple class that traverses O2D and calls a method for each O2D primitive. I then subclassed it to: export the O2D structure as text (for debugging purposes); export it as SVG; calculate the bounding box for the SVG (needed to export the SVG if it is not already known).
RectShape, RoundRectShape, OvalShape, CurveShape, FigureSshape, PixmapShape and StringShape all have SVG equivalents and convert simply. However, ArcShape does not because O2D draws the border on the arc only whereas SVG draws it on the complete sector. To represent O2D ArcShape I generated seperate SVG paths for the boundary and for the fill.
Reading back the generated SVG to an O2D structure is simple, except for the ArcShape where one has two recognize that two paths together represent one O2D ArcShape.
Notes:-
The regenerated O2D is the same image as the original O2D and suitable for import, but is not the same O2D structure as the original. This is because O2D compiles graphics on the fly (e.g. Group2D and FigureShape scaling and rotation is immediately applied to the contained objects), and because seveal O2D types transform to a single SVG type.
The import of the generated SVG makes virtually no contribution to the import of SVG from other sources. The only SVG primitives involved are very particular cases of rect, ellipse, path, text and image, and constitute a tiny fraction of the richness of SVG.
The generated SVG goes beyond the SVG Tiny specification which does not support elliptical arcs in paths.
The generated SVG renders correctly in Safari and Internet Explorer 10, both of which now seem to have strong SVG support.
Adobe Illustrator in CS6 doe not render everything correctly because it does not honor stroke-width or stroke-miter-limit – that was surprising as Adobe has been a strong advocate for SVG.
EazyDraw rendered everything correctly except for a minor glitch with rotated rounded corner rects (which Dave Mattson has just confirmed and says will be fixed in the next release).
There are some glitches in O2D rendering of the fill of ArcsShapes and FigureShapes with wider borders. Spurious fill is generated suggesting that the fill algorithm for borders has a bug.
I added SVG export to my app several years ago but not through O2DSVG conversion. My graphic data structures are complex objects and I convert them to:- O2D for printing and for export to the clip (as 3x scaled PNG which prints as well as vector when scaled down and satisfies word processor users); SVG grouped and tagged with the ID of the original object to make it easy for users to edit the SVG.
This suggests that some facility for tagging and commenting would be useful in an SVG export module.
Conclusions:-
A Xojo module to export an O2D structure as SVG requires little effort and would satisfy those who need SVG export. It could also provide the facility to import the exported SVG as an O2D structure.
This does not address the feature request for general SVG import which would involve very much greater effort. That might best be addressed by recoding for Xojo an open source reference implementation of an SVG renderer such as that in Batik to render to the graphics primitives of the underlying operating systems (which are very much more advanced than they were when O2D was developed).
This suggests that the feature request should be split into two distinct requests, one of which would be reasonable short-term, and the other of which would be a longer term project requiring substantial effort.
[quote=121235:@Karen Atkocius]For that one would likely need the full SVG spec implemented…
What Norm is taking about is just supporting what Object2D’s can to which is much more limited.
IMO in general to have good vector graphics capacities, at a minimum Object2D would need to also support gradients and patterned lines. That would be useful even without SVG support.
- Karen[/quote]
Yes, I really want to see the full monty, especially in Web Apps, and would prefer that there wasn’t any conversion so that we get native support for retina.
[quote=121422:@Dr Brian R Gaines][/quote]
Brian,
in your working, do you get any error, malfunction that suggest Object2D are not 100% working in Xojo2014R2.1 (I mean “current Xojo version”) ?
[quote=121533:@Emile Schwarz]Brian,
in your working, do you get any error, malfunction that suggest Object2D are not 100% working in Xojo2014R2.1 (I mean “current Xojo version”) ?[/quote]
Hi Emile, I was still on 2014R2 so just downloaded 2.1 and ran my O2DSVG test environment. The only errors I see are in the fills of CurveShapes and Arcs with wide boundaries where there are major artifacts which would make the rendering unacceptable. I think these have always been present as I recollect sending a bug report on erratic boundary filling in O2D when Joe Strout first released it, but it was not fixed. I worked around by creating my own boundary fills with concentric single pixel boundaries.
I also ran my main app which creates much bigger O2D structures and nave not had any crashes or other problems.
All this on a new Mac Pro under OS X 10.9.4 with Cocoa builds.
What problems are you seeing?
None, but due to:
a. clipboard troubles I had
b. save / load,
c. O3D deprecation/removal
I had bad feeling about O2D present and future.
Thank you for your kind answer.
I was fooling around and falled on:
[url=http://www.w3schools.com/html/html5_svg.asp]w3schools: html5_svg/url]
I do not took time to read them, yet.
HTH.
A number of people have asked me for a copy of my O2DSVG code. I have cleaned it up and posted it at
http://cpsc.ucalgary.ca/~gaines/O2DSVG.zip
As noted in the copyright notice, the code is in the public domain and anyone is welcome to use any of it for any purpose without acknowledgement.
The project posted is an O2D testbed to exercise the classes which allow any O2D structure to be exported as SVG, and the exported SVG to be imported as an O2D structure.
If you simply wish to export SVG in your project then just include the classes: O2D (an O2D structure-traversal base class); O2DSVG (which creates an SVG string from a passed O2D structure); and O2D Bounds (which computes a bounding box for the SVG if you do not already have one – if you have one, this can be passed to O2DSVG and O2DBounds is unnecessary).
The class SVGO2D will import the SVG thus created and return an O2D structure. It will not read SVG in general, and is intended as proof of feasibility of one suggestion on this list, that SVG could be used to pass O2D structures between different Xojo programs. However, to be useful in this respect there needs to be agreement on a standard format so this class is not intended to be immediately useful.
I noticed some glitches in the filling of ArcShape and FigureShape boundaries and have reported these as Feedback case 35000 - “Object2D has artefacts in FigureShape and ArcShape thick boundary fills.”
This is fantastic news Dr. Gaines, and thank you so much for sharing. Your code is a great help!
if the class O2DSVG the method NStr should use str(n,"-#.##") instead of format(n,"-#.##") to be international savvy
It’s this that I think is most important/interesting:
http://www.w3schools.com/svg/svg_path.asp
Object2D is not a good replacement when we need to draw curves and paths.
We really need full built-in ability to render and alter any complex svg that a browser can render. For now I’m assuming we could just overlay SVG divs on an HTML viewer. But saving these back as an image becomes trickier. On a desktop you could get the color of the picture at each location but in a web or console app there isn’t much you could do. (alternative ideas?)
That’s why I’m thinking showing it as an HTML viewer will yield the best results but the downside is you can’t export this or render this as an image easily.
Not to mention other components like:
http://www.w3schools.com/svg/svg_fegaussianblur.asp
http://www.w3schools.com/svg/svg_grad_linear.asp
[quote=123615:@Brock Nash]Not to mention other components like:
http://www.w3schools.com/svg/svg_fegaussianblur.asp
http://www.w3schools.com/svg/svg_grad_linear.asp
[/quote]
In general Xojo graphics certain/drawing capabilities are at least a decade or more behind what is supported by all the OSes these days it supports … And that includes object2Ds.
I am not optimistic about OS level support for modern graphics capabilities in the foreseeable future.
- Karen
SVG isn’t “native” most anywhere
Browsers are about the only place they have decent support
[quote=123625:@Norman Palardy]SVG isn’t “native” most anywhere
Browsers are about the only place they have decent support[/quote]
Did not say that… I was speaking more generally.
What i meant was much of what it can do IS part of the OS graphic graphics capabilities these days…
In general the capabilities of Xojo graphics APIs seem to me to be significantly less than the lowest common denominator on the desktop for OS capabilities these days.
Thanks Antonio. Yes, one does not want internationalization of the SVG numbers and I should have used Str.