Pardon me for butting in, but have you tried to render serverside using Batik, gtk2, or librsvg?
Admittedly, text bounding boxes are a thorny problem with serverside generation. My own Perl SVG library totally ignores the canvas and leaves it to the implementer to use their own canvas-model-providing solution serverside. Batik has a canvas model, and therefore I believe that it can return bounding box information within the application being used to build the content serverside. Hence, you should be able to render the image serverside as needed to determine the image bounding box, and then work with this. Presumably, any library with an internal canvas model should do the trick SVG is xml, which is clear text. You can therefore create SVG in any text generator, whether or not it has a concept of text geometry. It is not up to the SVG recommendation to tell vi, notepad, or kedit (or any other editor you choose) what it should do with the XML text you generate. The same thing goes for serverside SVG generators. After all, this is exactly the same problem as with server-side html generation. Also, have you considered using svg1.1 or svg1.2? Both support textboxes to an extent, and may solve some of your problem. Best of luck. Ronan On Sunday 28 May 2006 21:30, Johan Persson wrote: > Hi, > > Well, I do understand that not everyones taste can be catered for in a > specification and I do realize that you can ask for the bbox in a DOM > script (in the viewers that support this). But for basic entities like > text, which I think most people can agree on is needed most of the time > even in images this omission makes life so much more difficult. > > For complex graphs with multiple texts this omission of bbox as a > declarative entity would force the backend to generate some > "self-modifying" script. > > Basically with the kind of layout needs that I have it could easily require > every coordinate in the scene to be dependent on one or more bbox for > various text strings in order to properly line things up. > > What I need to do apparently is to spend a few days and see how a typical > scene can be modified with some additional DOM scripting that will have to > modify potentially every other coordinate in the scene depending on the > actual text strings. > > Since I'm not that used to SVG (yet) my initial impression is that this > will get quite messy but I might be able to find some "clean" way of > structure such code. > > The biggest probably will most likely be that the library (for which I'm > writing the SVG backend) makes assumption that the bbox is available when > the code is generated on the fly. Changing the layout engine into working > in harmony with this back-patching of bbox:es will most likely be the > biggest challenge. > > Thanks for all Your comments > > Johan > > On Sunday 28 May 2006 20:36, Robin Berjon wrote: > > On May 28, 2006, at 19:58, Johan Persson wrote: > > > I'm still so surprised about this omission since it basically > > > renders SVG > > > useless for anything involving graphics with TTF fonts and texts > > > (without > > > resorting to things like a fixed font where one could calculate an > > > approximate bounding box outside the viewer used and hope for the > > > best). > > > > > > One of the replies to my original posting mention that there are no > > > plans to > > > add anything like this to the upcoming 1.2 specs. > > > > > > Can anyone share any light why this humungus omission has come to be? > > > > SVG is used for a hugely varied amount of things, therefore someone's > > humongous omission is someone else's trifle feature. > > > > Unless I've missed something, what you describe can be done in > > script: you can always ask for the bbox of text, as well as a number > > of other aspects. If it were to become declarative (as in Cam's > > excellent constraints work) I would expect that it would live in a > > specification separate from SVG so that it could be reused elsewhere > > (I sure have at times wanted to use something like that with HTML/CSS > > as well). > > > > -- > > Robin Berjon > > Senior Research Scientist > > Expway, http://expway.com/ > > > > > > > > > > ----- > > To unsubscribe send a message to: > > [EMAIL PROTECTED] -or- > > visit http://groups.yahoo.com/group/svg-developers and click "edit my > > membership" ---- > > > > > > > > > > SPONSORED LINKS > > Xml format Svg Format > > Data > > > > > > YAHOO! GROUPS LINKS > > > > > > Visit your group "svg-developers" on the web. > > > > To unsubscribe from this group, send an email to: > > [EMAIL PROTECTED] > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. -- Ronan Oger Director RO IT Systems GmbH ...Building Web2.0 with SVG since 2001 http://www.roitsystems.com ------------------------ Yahoo! Groups Sponsor --------------------~--> Everything you need is one click away. Make Yahoo! your home page now. http://us.click.yahoo.com/AHchtC/4FxNAA/yQLSAA/1U_rlB/TM --------------------------------------------------------------------~-> ----- To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ---- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
