Hi Johan, svg-developers@yahoogroups.com wrote on 05/29/2006 05:43:31 PM:
> 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. Using Batik you can convert any TTF font into an SVG Font (with subsetting) the SVG Font's metrics should match the original TTF font's metrics. So you might consider constructing your SVG file to reference an SVG Font. If you are really using Java, Batik is 100% pure java so including it in your app should be fairly simple. If you don't have access to the TTF on the server then you must do the layout on the client in ECMAScript... > 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. This is certainly possible, it will likely mean 'duplication' of code between your SVG ECMAScript and your current C++/Java layout engine. > 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. From what I recall of PostScript there isn't much difference between stringwidth (PS) and <text element>.getBBox().getWidth() (SVG). So I'm not sure how PS would be any easier. Anyway good luck! > > /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 svg-developers@yahoogroups.com, 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 > > > > ----- > 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 > > > > > > > ------------------------ 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/
