I need to create graphics for documentation, e.g. different functions of soft-keys or pin assignments for embedded systems with different firmware. My first thought was to use an SVG template, i.e. comfortably create the basic graphic with e.g. Inkscape and then use some XML library to set/replace respective strings for labels automatically. The SVG then can be embedded or rendered to any other format required.
I would like to know other ideas, or if there is some sort of standard method of doing this.
SVG is just XML, hence is fairly easy to generate.
You can easily generate SVG using XSLT: http://www.carto.net/papers/svg/samples/xslt/
Many programming languages provide efficient APIs for manipulating XML, which can also be applied to generate SVG. For example, I have had good success using Python and the lxml library.
Related
As part of my software I have to somehow convert and display Esri ASCII (.asc) files on a leaflet map.
The files are in the filesystem and the backend is in nodeJS.
.asc is a raster format and gdal_translate manages to translate the files as I like. Unfortunately I can't use GDAL in node and as far, as I see it, gdal-node is not able to convert the files. Manually converting files is not an option.
My data is always somehow geo referenced, so if I get an image, it has to be placed on the right spot on the worldmap.
Help would be highly appreciated, because I feel kinda overwhelmed by all this GEO stuff.
If you want the normal set of features Leaflet offers, like zooming, what you need is called a map tile service.
There are a few map tile standards that Leaflet supports. Generally though, making map tiles is complicated — particularly if your ASCII grids are in lat/long but you're using a background layer from Google, Bing, OSM that's in "web Mercator" — so you probably don't want to write one in Node yourself.
Look at GeoServer and see if that will fit into your setup.
I am writing a program that will output 3D model files based on simple geometric shapes (e. g. rectangular prisms & cylinders) with known coordinates in 3-dimensional space. As an example, imagine creating a 3D model of stonehenge. this question suggests that OBJ files are the easiest to generate, but I'm struggling to find a good tutorial or easy-to-use library for doing so.
Can anyone either
(1) describe step-by-step how to create a simple file OR
(2) point me to a tutorial that describes how to do so
Notes:
* Using a GUI-based program to draw such files is not an option for me
* I have no prior experience with 3D modeling
* Other formats such as WRL or DAE would work for me as well
EDIT:
I do not need to use textures, just combinations of simple geometric shapes positioned in 3D space.
I strongly recommend to use some ASCII exchange format there are many out there I usually use these:
*.x DirectX object (it is a C++ source code)
this one is easiest to implement !!! But there are not many tools that can handle them. If you do not want to spend too much time coding then this is the right choice. Just copy the templates (at the start) from any *.x file to get started.
here some specs
*.iges common and importable on most CAD/CAM platform (Catia included)
this one is a bit complicated but for export purposes it is not that bad. It supports Volume operation like +,-,&,^ which are VERY HARD to implement properly but you do not have to use them :)
*.dxf AutoCAD exchange format
this one is even more complicated then IGES. I do not recommend to use it
*.ac AC3D
I first saw this one in flight gear.
here some specs
at first look it is quite easy but the sub-object implementation is really tricky. Unless you use it you should be fine.
This approach is easily verifiable in note pad or by loading to some 3D model viewer. Chose one that is most suitable for your needs and code save/load function to your Apps internal model class/struct. This way you will be compatible with other software and eliminate incompatibility problems which are native to creating 'almost known' binary formats like 3ds,...
In your case I would use IGES (Initial Graphics Exchange Specification)
For export you do not need to implement all just few basic shapes so it would not be too difficult. I code importers which are much much more complicated. Mine IGES loader class is about 30KB of C++ source code look here for more info
You did not provide any info about your 3D mesh model structure and capabilities
like what primitives you use, are your object simple or in skeleton hierarchy, are you using textures, and more ... so it is impossible to answer
Anyway export often looks like this:
create header and structure of target file format
if the format has any directory structure fill it and write it (IGES)
for sub-objects do not forget to add transformation matrices ...
write the chunks you need (points list, faces list, normals, ...)
With ASCII formats you can do this inside String variable so you can easily insert into or modify. Do all thing in memory and write the whole thing to file at the end which is fast and also add capability to work with memory instead of files. This is handy if you want to pack many files to single package file like *.pak or send/receive files through IPC or LAN ...
[Edit1] more about IGES
fileformat specs
I learned IGES from this pdf ... Have no clue where from I got it but this was first valid link I found in google today. I am sure there is some non registration link out there too. It is about 13.7 MB and original name IGES5-3_forDownload.pdf.
win32 viewer
this is free IGES viewer. I do not like the interface and handling but it works. It is necessary to have functional viewer for testing yours ...
examples
here are many tutorial files for many entities there are 3 sub-links (igs,peek,gif) where you can see example file in more ways for better understanding.
exporting to IGES
you did not provide any info about your 3D mesh internal structure so I can not help with export. There are many ways to export the same way so pick one that is closest to your App 3D mesh representation. For example you can use:
point cloud
rotation surfaces
rectangle (QUAD) surfaces
border lines representation (non solid)
trim surface and many more ...
What's the simplest, most reliable way to test if a browser / user agent / client supports the Raphael.js library? Raphael uses Javascript to create and control SVG vector graphics, or, if SVG isn't available but VML is (e.g. in Internet Explorer versions 6 to 8), it creates and controls equivalent graphics using VML.
One method would be to feature-detect SVG, then, if it's not available, feature-detect VML. There's an old question from 2009 with answers including some code for feature-detecting VML and SVG. However, the comments suggest that it might not work in all cases, and I'm sure a lot has changed since 2009. Also, there might be a simpler way specific to Raphael.
A simpler alternative might be to use some Raphael internal flags or functions. It already sets variables for whether it is operating in SVG mode or VML mode. Can this be used to reliably detect a 'neither' condition?
Or maybe there's a reliable approach based on creating an empty Raphael object and testing its properties or functions?
For general background, as far as I know the only common browser to not be compatible with Raphael is the Android stock browser in versions 1.x and 2.x, however, I'd prefer to use feature detection rather than browser version detection if possible (unless there's a good reason why that's actually unusually a better solution in this case).
Check the official docs: http://raphaeljs.com/reference.html#Raphael.type
if (!Raphael.type) alert('Your browser does not support vector graphics!');
I'm looking at some older code which is rendering some images, animations, etc... for a website by generating a web page containing significant SVG elements. The result is a fairly complicated, interactive, interface. I've been tasked with migrating the application to instead generate WebGL calls.
This is a non-trivial task, considering all of the niceties that come with SVG, which are not directly available if going straight to a WebGL implementation. I've been debating whether I should pitch migrating to using something like Three.js instead, but don't know enough about the available options to make a good decision.
What are some reasonable options I should consider when trying to build my battle plan here?
I would suggest you look at http://code.google.com/p/canvg/ as an option.
I assume it is using getContext("2d") not getContext("experimental-webgl") or getContext("webgl").
WebGL provides a 3d interface and I am not sure if there is any advantage to using it for 2d graphics, since you don't have any 3d transforms for the GPU to work on. If they are interested in Canvas not specifically webgl ... Canvg would bring over some of the niceties of SVG which would be the source content.
If the issue is lack of support for SVG in browsers http://code.google.com/p/svgweb/ goes a long way to solving that problem.
It seems like SVG has be "deprecated" in Flex 4 in favor of Adobe's FXG. What can I do if I have a bunch of SVG graphics that I want to keep using. Is there something reliable to convert SVG to FXG? Are they in feature parity? Is there a converter out there that won't cost me $1500?
Inkscape also exports fxg now (see comments #24 and #42), but with some limitations.
It uses simple XSLT as extension, so you can write simple script in any language that supports XML transformations to produce FXG from your SVG's.
Actually if you are programming in flex 4, check out the spark path primitive. For path data it uses a string that has the same syntax as an svg path. You just have to parse it out but actionscript fully supports regular expressions so it shouldn't be too hard to load an svg as a text/xml file with urlrequest and parse out the path data for your primitives.
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/spark/primitives/Path.html
Path Objects only support transforms on their entire path so if you want to manipulate path data in real time you will just have to parse the data in a data structure and convert to a string for display.
It used to be that if you wanted to display an svg path with the actionscript 3.0 graphics library you would have to approximate the cubic berzier with quadratic berziers upon display but the spark primitive does do away with that by accepting path data in cubic form-- although even the spark primitives, when they draw themselves out, do seem to be approximations that are reaaallly close.
Depends how much work you want to do to interpret the svg data. If you want to do things like implement styles, masks/clipping and blur effects, the functionality is there in flex 4 with path and all of it's properties but implementing it from the data is going to require work.
Most of the svg graphical elements(shapes and text) can be converted to path data in programs like inkscape. Even so, actionscript has draw method geomitries that most likely support the basic shapes.
Also transforms on groups of elements will have to be parsed if you want to use that as well, or you can just not use groups, they are rather pointless when you aren't manipulating them.