Hello, > -----Original Message----- > From: John Jones [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 22. Dezember 2004 17:43 > To: Batik Users > Subject: SVG capabilities > > 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.
With Batik that should not be a problem. You can change every attribute of your SVG document dynamically and by this you can set the 'visibility' attribute to hidden/visible or set the 'display' attribute to 'none'. The difference between the two attributes is described here: http://www.w3.org/TR/SVG11/painting.html#VisibilityControl To include the information, which elements belong to what layer, you can add your own attributes to your document by using namespaces. Some information on this can be found at the SVG specs: http://www.w3.org/TR/SVG11/extend.html (I think, you will find a guess for your question 2., too) > 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? If I understood your idea the right way, I would think this should be possible. I would do it this way: In the scenario editor some things should be added to the map (not sure what your wargame will be like, say some evil villains ;-)). The added information can be saved to an scenario svg-file that also includes the view box value of the visible area for the scenario. The client application reads the scenario file and loads the appropriate elements from the reference map and adds them to the working map. Probably it is necessary, to add the values of the bounding boxes of the elements to your metainfo, so you won't need to process the whole reference map to get the bounding boxes of the elements (this would take some time on large maps). I am not sure, if this idea would work in detail, but as far as I am familiar with Batik, that's what I suggest as a basic approach. Have a nice christmas, Kai. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
