Re: font/glyph metrics proposed wording

I agree with the concept of the proposed wording.

thx...Dave

On Tue, Apr 28, 2009 at 4:00 PM, Lofton Henderson <lofton@rockynet.com>wrote:

> 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
>
>