Thanks for the tips. This is basically the workaround I have but unfortunately it's simply not good enough. The library I was contemplating an SVG backend for is JpGraph which is a PHP (an unholy mix of C/C++ and Java) server side graph generating library that I written. It has quite a lot of advanced text formatting (like tables, columns etc) which adjusts itself to the user selected TTF font and the actual text strings.
Without drastically reducing the functionality I need to be able to give the end user of the library his/her choice of TTF fonts. At the moment the library generates raster images encoded as either jpeg, gif or png with user selectable TTF fonts. The only approximate solution I can think of is to build in some heuristics that given a certain text string and font I try to guesstimate the bounding box. With the way the libary works now the end user never has to think about adjusting things like margins, column widths, etc. it's all taken care of automagically and I like to keep it that way. But of course, this requires the library to be able to calculate bbox:es. The "perfectionist" in me has a problem with this approach since it can never be guaranteed to work 100% and will either have to much "safety margin" or things will start overwrite each other. More problematic is the fact that the raster image and the SVG image will possible have quite different proportions. The library will generate SVG output directly without the use of any external library (just some utility SVG classes to keep track of things like grouping, viewboxes etc.) The only guaranteed solution seems to be to add some automatically generated DOM script that will "backpatch" (possible every coordinate in the scene) depending on the actual strings and fonts the user have selected. I will have to do some experimental coding to even validate that this is in fact possible at all. It might just turn out that I have to resort to add a PS backend which will definitely not be easier but PS has the "stringwidth" operator which makes life for me easier. /Johan On Monday 29 May 2006 17:32, Alastair Fettes wrote: > 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 > > ----- > 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 --------------------~--> Protect your PC from spy ware with award winning anti spy technology. It's free. http://us.click.yahoo.com/97bhrC/LGxNAA/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/
