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. -- --------------------------------------------------------------------------------------------------- Aditus Consulting is a Swedish company with registered address: Emagatan 16, SE-128 46 Stockholm, Sweden. VAT No: SE661128485901 ------------------------ Yahoo! Groups Sponsor --------------------~--> Get to your groups with one click. Know instantly when new email arrives http://us.click.yahoo.com/.7bhrC/MGxNAA/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/
