SVG capabilities

[John Jones <ch...@openwarsim.net>]

I have a few questions that the masters out there could certainly chime 
in on, if they have the time.  During my research and learning phase of 
this project I am working on, I am gathering all of the knowledge that I 
can in order to design this application in the best way possible.

The project is a wargame written in Java, using Batik as the graphics 
engine.

My questions:

1.  Can an SVG app be coded so that the map file (.svg or a 'wrapper' 
file that contains an SVG file + meta data 'header', etc) contains 
layers that can be turned on and off within the program, using SVG's 
visibility?  An example would be allowing a viewer to turn off grid 
lines, for instance, or turn off the foliage+terrain shading and turn on 
terrain lines only (no fills) using menu options.  The SVG file would 
contain this layer information, so that each map would be self-contained.


2.  One of the ideas I have for one of these layers is a gray-scale 
height map that the application uses as a terrain map during 
calculations of Line-Of-Sight checks.  One of the issues I will have to 
tackle is having a 'reference' somehow embedded into the map file that 
gives the app a height in meters for a particular shade of gray.  I was 
considering having the map file consist of the svg itself, in addition 
to other metadata, such as this height reference, author/date 
information and authenticity/"Certified" status/CRC signature of some sort.

My current thought on this is a SAX parser in-app that splits this 
metadata away from the actual SVG, rebuilding the svg data separately 
and using that as map data.  The metadata will be used/checked by 
different aspects of the application simultaneously.  This 'wrapper' 
format would be used to distribute maps in one file, obviously.

The question here is, given that SVG is XML, can these 'metadata 
elements' be contained inside the SVG element tree itself without 
confusing the Batik rendering sections of the code?  It is possible, I 
think, using CDATA elements, but what are the thoughts of everyone out 
there?


3.  This one is a long-shot, and I am relatively sure the answer is 
'no', but the designer in me begs to ask:  Can an app/viewer/loader be 
built that reads in a large svg file (say, a 100km x 100km map file), 
allows the user to find a smaller section of a map to use for a scenario 
(say a 20km by 20km square of that), and 'crop' the map data into a 
smaller memory footprint svg?  A sort of sub-svg file?

My idea was to allow a scenario description file to describe the map, 
describe the upper left corner of this 'zoom square' and a size of said 
'zoom square'.  This way, if the entire 100km x 100km (1600x1600px) map 
file takes up 10M of memory when fully loaded normally, a scenario 
designer could crop this down to a 1M sub-map, without having to 
distribute a new map file (all players would already have the map with 
the distribution).  Can you see it as possible for an application to be 
able to do this sort of 'crop-and-discard-all-other-data' operation to 
conserve memory?

I believe it would be possible, difficult but possible.  Or am I just 
too starry-eyed?  :)

Thanks for any questions or pointers.  I am mostly interested in



---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

Re: SVG capabilities

[Tonny Kohar <to...@kiyut.com>]

Hi,

> 1.  Can an SVG app be coded so that the map file (.svg or a 'wrapper' 
> file that contains an SVG file + meta data 'header', etc) contains 
> layers that can be turned on and off within the program, using SVG's 
> visibility?  An example would be allowing a viewer to turn off grid 
> lines, for instance, or turn off the foliage+terrain shading and turn on 
> terrain lines only (no fills) using menu options.  The SVG file would 
> contain this layer information, so that each map would be self-contained.

I think you can simulate layer in SVG by using <g> element and use
visibility on/off

> 2.  One of the ideas I have for one of these layers is a gray-scale 
> height map that the application uses as a terrain map during 
> calculations of Line-Of-Sight checks.  One of the issues I will have to 
> tackle is having a 'reference' somehow embedded into the map file that 
> gives the app a height in meters for a particular shade of gray.  I was 
> considering having the map file consist of the svg itself, in addition 
> to other metadata, such as this height reference, author/date 
> information and authenticity/"Certified" status/CRC signature of some sort.

> The question here is, given that SVG is XML, can these 'metadata 
> elements' be contained inside the SVG element tree itself without 
> confusing the Batik rendering sections of the code?  It is possible, I 
> think, using CDATA elements, but what are the thoughts of everyone out 
> there?

I am not really sure about this one, I think SVG support Metadata out of
the box. Beside for SVG 1.2 there is really interesting stuff such as
xbl, etc. Check out the SVG 1.2 spec for more info

> 3.  This one is a long-shot, and I am relatively sure the answer is 
> 'no', but the designer in me begs to ask:  Can an app/viewer/loader be 
> built that reads in a large svg file (say, a 100km x 100km map file), 
> allows the user to find a smaller section of a map to use for a scenario 
> (say a 20km by 20km square of that), and 'crop' the map data into a 
> smaller memory footprint svg?  A sort of sub-svg file?

About the memory footprint, I think it is depend on the UA itself,
but for pure SVG, I think you could use viewbox. I forget then name (if
I am not wrong), svg have attribute that can give hint to UA not to draw
the thing not currently displayed. Maybe this can save some memory.

Regards
Tonny Kohar
-- 
Sketsa 
SVG Graphics Editor
http://www.kiyut.com



---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org