- From: Lofton Henderson <lofton@rockynet.com>
- Date: Wed, 29 Apr 2009 07:32:22 -0600
- To: "WebCGM WG" <public-webcgm-wg@w3.org>
- Cc: "Forrest Carpenter" <forrest@sdicgm.com>, "Robert Orosz" <roboro@auto-trol.com>,Ulrich Läsche <ulrich@cgmtech.de>
- Message-Id: <5.1.0.14.2.20090429073045.019aa1f0@localhost>
Benoit --
I like it, thanks. (My prose muse seems to have been away from the office
yesterday!)
-Lofton.
At 09:22 AM 4/29/2009 -0400, Bezaire, Benoit wrote:
>Sorry Lofton,
>
>I meant to reply yesterday, but couldn't find the time. I thought your
>suggestions was a bit repetitive... I tried to make it shorter without
>changing the meaning.
>
>[[[
>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. Therefore, calculations assume that each glyph
>extends to the full ascent and descent vertical font values; and to the
>glyph's horizontal advance value. In CGM:1999 terminology, full ascent and
>descent are known as bottom-line to the top-line (see Figure 11, CGM:1999
>section 6.7.3.2). For example, the font's bottom-line and top-line
>typically correspond to 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 -- corresponds to the
>glyph's horizontal advancement value (WX) in the font databases of
>@@WebCGM's core thirteen fonts@@.
>]]]
>
>
>----------
>From: public-webcgm-wg-request@w3.org
>[mailto:public-webcgm-wg-request@w3.org] On Behalf Of Lofton Henderson
>Sent: Tuesday, April 28, 2009 7:01 PM
>To: WebCGM WG
>Cc: Forrest Carpenter; Robert Orosz; Ulrich Läsche
>Subject: 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
Received on Wednesday, 29 April 2009 13:33:28 UTC