- 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