font/glyph metrics proposed wording

All --

Looking at the attached below message, we chose Option 3.  In the telecon, 
Benoit raised the question about horizontal extent of the text.  It is a 
good one, because the answer is not totally obvious when you look in the 
helvetica.afm file.

We talked some more, and here is my draft of the changes to the current 
(15th March) editors text.  Specifically, replace the 4th paragraph of that 
text [1].
[1] 
http://www.w3.org/Graphics/WebCGM/drafts/current-editor-21/WebCGM21-DOM.html#getObjectExtent

Current 4th pgph:

[[[
For the purposes of the object extent (bounding box) calculation, each 
glyph is treated as a separate graphics element. The calculations assume 
that all glyphs occupy their full glyph cell. In particular, the 
calculations assume that each glyph extends vertically from the bottom-line 
to the top-line of the font (see Figure 11, CGM:1999 section 6.7.3.2) -- 
i.e., the vertical extent of each glyph includes the full ascent and 
descent values for the font, regardless of whether the particular glyph 
actually has ascenders and/or descenders.
]]]

Proposed:

[[[
For the purposes of the object extent (bounding box) calculation, each 
glyph is treated as a separate graphics element. The calculations assume 
that all glyphs occupy their full glyph cell, in both the vertical and 
horizontal directions. In particular, the calculations assume that each 
glyph extends vertically from the bottom-line to the top-line of the font 
(see Figure 11, CGM:1999 section 6.7.3.2) -- i.e., the vertical extent of 
each glyph includes the full ascent and descent values for the font, 
regardless of whether the particular glyph actually has ascenders and/or 
descenders.  The font's bottom-line and top-line (full ascent and descent 
values) typically correspond to font-metric information in the font 
database, for example the ymin/ymax values of the fontBBox item found in 
the databases of @@WebCGM's core thirteen fonts.@@  Similarly, the full 
horizontal extent of the glyph cell for the particular glyph -- as distinct 
from actual drawn extents of the glyph -- is typically found in the 
individual glyph-metric information in the font database, for example each 
glyph's horizontal advancement value (WX) in the font databases of 
@@WebCGM's core thirteen fonts@@.
]]]

I admit that the language is a little awkward in places -- I'll clean it 
up, or feel free to make suggestions for clean-up.

Mainly, I want WG endorsement of the basic content -- what we're saying -- 
and how we're presenting it ("for example").

Regards,
-Lofton.

At 05:01 PM 4/27/2009 -0600, Lofton Henderson wrote:
>Forrest has finished his action item to illustrate the font metrics:
>[1] http://lists.oasis-open.org/archives/cgmo-webcgm/200904/msg00131.html
>
>Have a look at the great picture that he generated.
>
>This should allow the dependent tests [gOE and gOET] to go forward.
>
>For the spec, our question is:  what changes, if any, should go into the 
>WebCGM spec to clarify this for future implementors?
>
>Options:
>1.) none -- the existence of "FontBBox -166 -225 1000 931" in the AFM data 
>(Helvetica in this example) should be sufficient.
>2.) normatively add to WebCGM spec the information from the AFM for the 
>core-13 fonts of WebCGM.
>3.) in the WebCGM spec, informatively explain or add or point to the 
>information from the AFM.
>4.) other?
>
>We will discuss on Tuesday.
>
>Note that options #2 and #3 don't answer the question for any font outside 
>of the core-13, which can be any font that has an associated FONT 
>PROPERTIES element.  (My opinion:  those generator/viewers need to figure 
>out and understand what is 'bottom' and what is 'top' for the "odd" fonts, 
>just as we have figured it out for core-13).
>
>-Lofton.
>
>>X-Mailer: QUALCOMM Windows Eudora Version 5.1
>>Date: Mon, 27 Apr 2009 16:02:18 -0600
>>To: "'WebCGM'" <cgmo-webcgm@lists.oasis-open.org>
>>From: Lofton Henderson <lofton@rockynet.com>
>>Cc: David Cruikshank <dvdcruikshank@gmail.com>
>>
>>
>>Forrest -- that's great!  I think your results unambiguously answer that 
>>AFM ymin is CGM:1999 'bottom' and AFM ymax is CGM:1999 'top', for all 
>>intents-and-purposes.
>>
>>Stuart -- you should be able to check/update your tests to ensure that 
>>you're using the right numbers for 'bottom' and 'top'.
>>
>>All -- we will discuss on the Tuesday vF2F agenda, what (if anything) to 
>>do about this in the WebCGM specification.  (Which has normative 
>>reference indirectly to other bits of the AFM via CGM:1999 annex I.)
>>
>>Regards,
>>-Lofton.
>>
>>At 01:56 PM 4/27/2009 -0500, Forrest Carpenter wrote:
>>
>>>All,
>>>
>>>
>>>
>>>Attached are the adobe AFM file, a png image and a CGM file showing 
>>>characters drawn with a cap height of 71.8 mm. The characters included 
>>>are the A-ring which shows the max y of 931 and the C-cedilla which has 
>>>the min y of -225. The image was generated on UNIX using the Microcosm 
>>>font for Helvetica which is visually and metrically equivalent to the 
>>>Adobe font. When drawn on Windows mapping Helvetica to Arial we get 
>>>different results.
>>>
>>>
>>>
>>>Regards,
>>>
>>>Forrest
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe from this mail list, you must leave the OASIS TC that
>>>generates this mail.  Follow this link to all your TCs in OASIS at:
>>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php