Once again, apologies to all for the long post. According to the SVG spec, a <use/> can only contain <desc/>, <title/>, <metadata/> and the "animate" elements.
Modifying an approach I've used to your problem would go something like: <use id="chair1" xlink:href="#chair" x="10" y="10"/> <use id="chair2" xlink:href="#chair" x="30" y="10"/> <use id="chair3" xlink:href="#chair" x="50" y="10"/> <g id="votelayer" visibility="hidden"> <use id="chair1vote" xlink:href="#chair" x="10" y="10"/> <use id="chair2vote" xlink:href="#chair" x="50" y="10"/> <use id="chair2vote" xlink:href="#chair" x="50" y="10"/> </g> <g id="namelayer" visibility="hidden"> <text id="chair1name" x="12" y="20">Wade</text> <text id="chair2name" x="22" y="20">Thomas</text> <text id="chair2name" x="22" y="20">Stefán</text> </g> Althought there is lots of repetition, this is easy to manipulate. While writing this up, I had another idea which is closer to what you asked. <svg xmlns:xlink="http://www.w3.org/1999/xlink"; xmlns="http://www.w3.org/2000/svg"; width="300" height="300" viewBox="0,0 100,100"> <defs> <g id="chair"> <rect x="0" y="0" width="5" height="5" style="stroke:black; stroke-width:0.5;"/> </g> <style type="text/css"><![CDATA[ .yes { fill:green; } .no { fill:red; } .none { fill:none; } .baselayer { visibility: inherit; fill: none; } .votelayer { visibility: hidden; } .namelayer { visibility: hidden; } text { font-size: 4; text-anchor:middle; } ]]></style> </defs> <g transform="translate(10,10)"> <use id="chair1" xlink:href="#chair" class="baselayer"/> <use id="chair1vote" xlink:href="#chair" class="no votelayer"/> <text x="2" y="10" class="namelayer">Wade</text> </g> <g transform="translate(30,10)"> <use id="chair2" xlink:href="#chair" class="baselayer"/> <use id="chair2vote" xlink:href="#chair" class="votelayer yes"/> <text x="2" y="10" class="namelayer">Thomas</text> </g> <g transform="translate(50,10)"> <use id="chair2" xlink:href="#chair" class="baselayer"/> <use id="chair2vote" xlink:href="#chair" class="votelayer none"/> <text x="2" y="10" class="namelayer">Stefán</text> </g> </svg> Manipulating the layers and states seems a bit more difficultto me. Now, to add/change a vote, you will need to combine a few classes as shown above. Turning the layers on and off will require modifying the styles for the various classes. (I haven't done this, so I don't know how hard that might be.) Later, G. Wade Stefán Freyr Stefánsson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Thanks so much for your reply. > > I have been looking into things today and in short I'm moving back towards > what you're saying... that is, to use standard SVG instead of extending the > SVG syntax for our purposes. > > I can see that I'm obviously suffering from lack of experience and things such > as this are something that I don't even think of :o(. Good thing that I can > turn to this list for ideas (thanks again). > > I have implemented a little application that reads a very basic floor plan and > I was able to dynamically update the image using a VotingSimulator thread > (yay). > (Oh, btw... it would be a good idea to make it more clear in the documentation > for Batik that JSVGCanvas's setDocumentState( JSVGCanvas.ALWAYS_DYNAMIC ) > _must_ be called _before_ setting the document with the setDocument( Document > ) if you want to be able to retrieve an UpdateManager from that JSVGCanvas > instance! It took me forever to figure out that getUpdateManager() always > returned null because I called the setDocumentState method after I had called > the setDocument method). > > I've pretty much decided on using standard SVG and I think your suggestion > about using internal stylesheets looks really good so I think I'll use that > too. > > There is, however, one little thing that I'm not quite shure on how to solve. > That thing is my "layer" concept. In my application, I'd want to be able to > turn on and off various information layers. For example, I'd like to be able > to turn off the voting "layer" so that all chairs are displayed normally. I > am able to imagine how that would be done (simply defining a class called > "off" in the stylesheet and setting all chairs to that) but I'm having a more > difficult time imagining how I could solve other types of layers such as the > name of the person sitting in that chair. I'd like to be able to somehow > "overlay" this information in the same location as the chair is put on the > basic floor plan (my goal is to keep the basic floor plan as simple as > possible so it is easy to update it, rearrange chairs and so on). This > information is pulled from a database so your suggestion of using the persons > name as the ID instead of an integer would not work for us, people can switch > chairs and so on and information about which person is sitting in which chair > is registered into a database. I'd like to be able to easily add such > information layers (where information is pulled from a database and rendered > on top of the chair location). Unfortunately I'm not quite getting how it > would be best to do that. Here are some questions that are related to this > problem: > 1) Is it possible in SVG to define anything within the <use> tag? What I mean > is that the chairs are rendered on the floor plan by referencing the "chair > definition". Is it possible to do something like: > <use xlink:href="#chair" x="20" y="20"> > <circle x="5" y="5" .../> > </use> > The way I see it is that the circle would then be rendered within its own > coordinate system and the area of the referenced element would be used as its > viewport (I hope I'm making myself clear). > > If this would be possible, adding information "layers" would be a piece of > cake by utilizing regular DOM manipulation like I've already done with the > fill element in my little test application. > > 2) If #1 is impossible, how would you suggest to achieve something similar? > > Kind regards and thanks for your answers, > Stefan Freyr > > On Thursday 07 August 2003 13:29, G. Wade Johnson wrote: > > Apologies in advance for a fairly long post. > > > > If I'm not misunderstanding, the basic design of what you want is > > relatively easy with just SVG and Batik. (Even without adding new > > attributes or elements.<grin/>) I'll have to defer to Thomas on the > > extending approach, I've not used that as yet. > > > > Modifying your example slightly, > > > > <svg xmlns:xlink="http://www.w3.org/1999/xlink"; > > xmlns="http://www.w3.org/2000/svg";> > > <defs> > > <g id="chair"/> > > <style type="text/css"><![CDATA[ > > .yes { fill:green; } > > .no { fill:red; } > > ]]></style> > > </defs> > > > > <use id="chair1" xlink:href="#chair" x="10" y="10"/> > > <use id="chair2" xlink:href="#chair" x="20" y="20"/> > > ... > > </svg> > > > > For a simple change in state like the vote, you could have the data > > stream that you read for updates contain the id and vote. For example, > > a CSV data stream with one change per line: > > > > chair1,yes > > chair2,no > > ... > > > > (For more complex changes, a more complex data stream might be > > necessary. But, to start, simpler might be better.) > > > > As each vote comes in you do the following, > > > > doc.getElementById( idstr ).setAttributeNS( null, "class", vote ); > > > > Of course, you will need the document in the 'doc' variable, and the > > 'idstr' and 'vote' need to be set up correctly. (Not to mention error > > checking.) But this is the basic idea. > > > > I could also see using a person's name for the chair id instead of > > a number, which could lead to other interesting features. > > > > If you want to keep up with more than a single state, associating > > a Java object with each "chair" would allow you to manipulate the > > the object in arbitrary ways. > > > > Also the "class" attribute can contain a space-separated list of > > classes. As long as the properties don't conflict, this allows > > you to make fairly complex visual effects. > > > > This approach would require you to develop less code and the SVG > > files could be created using standard tools. (That may not be an > > issue yet, but you can bet that someone is going to ask to make > > the picture more complex over time. Good tools would make that > > less of a hardship.) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > > iQEVAwUBPzJw970ge6mq4AL2AQLdsAf9E/s5xz4Yy4qvFrbzAjVLHVrByji689L2 > PBN7Sgmryd1J3CFJTxJGWsj3ZPOUcH9O0KGhJOuw7pzdjN0tH/2BirxewS7H6F/I > CR0eE75khX7+k5GD6gA7xZ9cuut7Yf8oimtFoz+i913Mxposqn3hjvuzx7Ut9AZn > cgdnviG6Kx9N5XQlH/xCgC2lKp+2jCQkyUCaD9J0mvKo2w8exgAOE+V3m3Isx38G > UP/fYHMkZUFrdxdZKuaZxPy2SKziKgRT+cbh903yOwEYLq794zLBcedEYRfu9Q2n > E/JvWo+BonaP5QPYss5wFxwRMkGoL+tgayYXpEZvZ2CHgtXyFyGqkw== > =fpst > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
