Re: A definition for "character cell" is not provide in the spec

Hi Doug,

Thanks for your reply.

Doug Schepers wrote:
> I'm pretty sure we cover this in the SVG 1.1 spec (although we normally 
> describe it in terms of bounding boxes rather than glyph cells).  It's 
> kind of scattered throughout the spec, but it's perhaps most explicit 
> here [1].

I really can't see how "character cell"/"glyph cell" can be equated with 
"bounding box" based on any version of the spec. (BTW, can the spec choose one 
of the former two terms and stick with it please - assuming "character cell" and 
"glyph cell" are actually interchangeable of course!) Even Tiny 1.2 seems to 
consider "bounding box" to be a separate things [3] ("Elements that do not 
derive from SVGLocatable do not have a bounding box,..." which even excludes 
tspan from having a bounding box). Glyph cells may _contribute_ to bounding 
boxes, sure. But SVG 1.1 doesn't in any way equate them in my opinion, and 
NEITHER SHOULD it.

By the way, I don't think "scattered throughout the spec" is an acceptable way 
to define a term. Terms used should be clearly defined in a single place that's 
dedicated to defining the said term (and can be linked directly).

> We take it a step further in SVG Tiny 1.2, where we unify and clarify 
> the various discussions of bounding box [3],

Defining the term "glyph cell" inside the definition for "bounding box" is the 
wrong place to do it. In my opinion this sentence:

   For example, for horizontal text, the calculations must assume that each
   glyph extends vertically to the full ascent and descent values for the font.

should be removed and a definition for "glyph cell" should be given _alongside_ 
the definition for "bounding box" (not in it).

Besides that, the above sentence is ambiguous. Does "full ascent and descent" 
refer to the full ascent and decent of the specific glyph in question from the 
font (in which case the glyph cells will vary in height along a string of text) 
or to the _maximum_ ascent and decent of all glyphs in a font (the 
interpretation I'd prefer).

I'd be happy to try and come up with a definition for "glyph cell" if that would 
help.

> and we add the 
> pointer-event value 'boundingBox' [4].

Which isn't even mentioned in the section below that begins "For text 
elements..." for what it's worth. It would also seem to back up "character cell" 
!= "bounding box" since the phrase "character cell" is used to define all of the 
values for pointer-events for text.

> This does not allow authors to use the "complete" bbox for text 
> elements, but it does do so for textArea. 

Umm. Not sure what the relevance is here since the topic at question is glyphs, 
not elements.

> If you think this is still 
> unclear, or if you don't think the functionality will suffice, we could 
> add it as an errata item.

I think it is still unclear and that to solve this the terms "character cell" 
and "glyph cell" need to be unified and defined in a single place as suggested 
above. Again, I'm willing to suggest some text for that definition.

> [1] http://www.w3.org/TR/SVG11/text.html#ObjectBoundingBoxUnitsTextObjects
> [2] http://www.w3.org/TR/SVG11/text.html#TextSelection
> [3] http://www.w3.org/TR/SVGMobile12/intro.html#TermBoundingBox
> [4] http://www.w3.org/TR/SVGMobile12/interact.html#PointerEventsProperty

Thanks Doug.

-Jonathan

Received on Thursday, 8 February 2007 01:37:15 UTC