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

Hi-

For the record, this was just my personal observation.  We will be 
discussing this in an upcoming SVG WG meeting for the final word, but if 
you have anything to add, feel free to send in another comment and we 
will take it into account.

Regards-
-Doug (on behalf of himself)

Doug Schepers wrote:
> 
> Hi, Jonathan-
> 
> I'm always interested in comments that allow me, as an author, to have 
> reliable interoperability between browsers.  Thanks for bringing this up.
> 
> 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].
> 
> We take it a step further in SVG Tiny 1.2, where we unify and clarify 
> the various discussions of bounding box [3], and we add the 
> pointer-event value 'boundingBox' [4].
> 
> This does not allow authors to use the "complete" bbox for text 
> elements, but it does do so for textArea.  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.
> 
> [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
> 
> 
> Regards-
> -Doug
> 
> Research and Standards Engineer
> 6th Sense Analytics
> www.6thsenseanalytics.com
> mobile: 919.824.5482
> 
> Jonathan Watt wrote:
>>
>> Dear SVG WG,
>>
>> SVG implementations seem to have diverged due to a lack of a 
>> definition for the term "character cell" which is used in:
>>
>>   http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty
>>
>> Mozilla defines this to be the rectangle that exactly fits to the 
>> edges of the painted area of each glyph. This might make sense in the 
>> case of text along a path or where each glyph is positioned 
>> individually, but in the case of a run of text along a straight line 
>> (without any extra character spacing) it leads to hit-test gaps 
>> between glyphs. Other implementations seem to use a larger box so they 
>> don't have these gaps. Perhaps they simply decide to use a single box 
>> around runs of text along a straight line? Or maybe they define 
>> "character cell" to be the box that is the advance of the glyph in 
>> question wide, by the largest font ascent to largest font decent high? 
>> (Details from other implementers would be welcome.)
>>
>> At any rate, please define the term "character cell" so that 
>> implementors can eliminate this difference between their implementations.
>>
>> Regards,
>> Jonathan
>>
>>
> 
> 
> 
> 


-- 

Regards-
-Doug

Research and Standards Engineer
6th Sense Analytics
www.6thsenseanalytics.com
mobile: 919.824.5482

Received on Wednesday, 7 February 2007 21:35:05 UTC