W3C home > Mailing lists > Public > www-svg@w3.org > March 2014

RE: [svg2] Text bbox calculations

From: David Dailey <ddailey@zoominternet.net>
Date: Wed, 12 Mar 2014 22:48:59 -0400
To: 'Erik Dahlström' <ed@opera.com>, <www-svg@w3.org>
Message-ID: <001b01cf3e66$c9342da0$5b9c88e0$@net>
Erik writes [much stuff about measuring glyphs], including analysis of SVG2's current language]. (Alas, I didn't quite follow it, but perhaps someone can set me straight):

 From https://svgwg.org/svg2-draft/coords.html#BoundingBoxes:
For text content elements, for the purposes of the bounding box calculation, each glyph must be treated as a separate graphics element. he calculations must assume that all glyphs occupy the full glyph cell. For example, for horizontal text, the calculations must assume that each glyph extends vertically to the full ascent and descent values for the font. An exception to this is when the ‘width’ or ‘height’ attribute has been specified on the ‘text’ element, in which case the element's content area is its bounding box.

Hi Erik,

I'm not sure what the 'full glyph cell' means but I do sense the following:
a) An author ought to be able to interrogate the actual size of a given glyph as drawn in the browser/viewer (even if SVG 2 ends up not supporting svg-fonts).

b) I was terribly disappointed to find out just how inconsistently browsers handled text measurements in such places as [1,2,3, 4, 5, 6]. These inconsistencies are not much different now than they were back then (2009), so far as I can tell -- maybe a bit more dysfunctional if anything.

c) I was even more disappointed to hear that browsers weren't really supposed to be able to measure text and that there were other techniques than bbox (that were inconsistently implemented) that had been intended (by some) to measure glyphs. Someone was concerned (as I recall) that someone might be concerned that someone (like me) might use measurements of glyphs to reverse-engineer a font and hence steal the damn thing!  Is it better to take pictures of fonts and then massage the bits to create all the wonderful modern and ancient  typographic effects that readers of the written word have come to expect ? [4,7] Of course not -- accessibility, semantics, automated inference, humor, art and science all go out the window;) -- (btw, if anyone is still reading this,  the link at [7] has some pretty cool pictures of historical layouts that are non-rectilinear!)

d) I got the idea that SVG might include a method for actually converting a glyph back to a path (so that one can actually do stuff with it without sacrificing accessibility). Once it becomes a path, then measuring it shouldn't be too hard ;) In the Book of Kells, for example [7], one knows the geometry of a glyph so that one can draw other semantic elements inside it!

Perhaps current discussion is taking all of these issues into account already, but as is often the case when I eavesdrop on WG discussions, I'm not completely sure if or how the discussion relates to previous concerns. In this case, the topic just sounds very similar to something we've talked about before. 

How will SVG2 draw a tight rectangle around a glyph, since it seems like SVG1.1 only gave Opera and ASV the ability to perform that particular magic? 


[1] http://srufaculty.sru.edu/david.dailey/svg/TopAlignBrowsers.png 
[2] http://granite.sru.edu/~ddailey/svg/tspanmeasure.svg 
[3] http://granite.sru.edu/~ddailey/svg/tspanmeasure4.svg
[4] http://cs.sru.edu/~ddailey/svg/GeometricAccessibility.html
[5] http://lists.w3.org/Archives/Public/www-svg/2011Jun/att-0006/00-part 
[6] http://lists.w3.org/Archives/Public/www-svg/2011May/0143.html 
[7] http://cs.sru.edu/~ddailey/NonRectangles/HistoricalExamples.html 
Received on Thursday, 13 March 2014 02:49:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:51 UTC