Hi Johan, First question for you is what library are you using to generate the SVG? Are you using a purpose built SVG library such as Batik or a generic XML library such as MSXML? If the former, then you will need to read the literature on Batik. If the latter then read on.
I use statically generated SVG wilthout using a fit-for-use SVG DOM. I do not require exact measurements of the text but I do generate a bounding box around them (that is close). I simly estimated a good width-to-height ratio for my text and get the width based on the text height x text string length. This of course is not very close to an exact science however its an engineering decision as this bounding box is not a strict necessity. Now, there's a much more exact option available to you that will require more computational power. This is done using SVG Fonts (<http://www.w3.org/TR/SVG/fonts.html>). Basically you get your SVG fonts file and for each character, you select the SVG Fonts file for the font/style in question, use an xpath to select the XML element for the given character, then you can retrieve the necessary font information directly from that element. Of course this way has a number of drawbacks. You will only have font support for the SVG Font files you have. Its also going to be computationally intensive depending on how many characters are found in your document. I personally have used this in the past in an XSLT library and it was very accurate. This library was for Math Formula layout for print. The device of a much smarter man than myself but amazingly useful for statically rendered SVG. If you have any questions on this feel free to give me a shout. Cheers, Alastair --- In [email protected], Johan Persson <[EMAIL PROTECTED]> 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. > > -- > > --------------------------------------------------------------------------------------------------- > Aditus Consulting is a Swedish company with registered address: > Emagatan 16, SE-128 46 Stockholm, Sweden. > VAT No: SE661128485901 > ------------------------ 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/
