[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cgmo-webcgm] getObjectExtent for text
Lofton, This should have been sent to the list also. The spec states the full ascent and descent values for the font should be used to compute the values for text extent. These correspond to yMax and yMin in the Microcosm fonts that we use and the FontBBox for type 1 fonts found in the .acm file for the font. I will volunteer to provide the Microcosm values so we can standardize on the numbers everyone uses. These should be the same as the values Adobe provides with their version of the type 1 fonts. Regards, Forrest -----Original Message----- From: Lofton Henderson [mailto:lofton@rockynet.com] Sent: Tuesday, April 21, 2009 5:40 PM To: Forrest Carpenter Subject: RE: [cgmo-webcgm] getObjectExtent for text Forrest -- Did you mean to copy only me on this? I think we have a bit of a meaty issue here. We need to kick it around publicly. Anyway, some responses and brain-dump (which I'll repeat on the list if appropriate)... At 01:11 PM 4/21/2009 -0500, Forrest Carpenter wrote: >Lofton, All > >When we use the yMax value of 931 and the 207 for the descender the >getExtents would return (75,72.8,225,112.4) compared to Stuart's value of >(75, 72.8,225,105) > >In our metrics we have a value for yMin of -225. The yMax and yMin values >represent the maximum and minimum values of all glyphs in the font, this >would make the extent 1156, which would extent beyond the 1000 x 1000 grid >mentioned in CGM1999. > >I think we should change the spec to return base line to cap line, that way >for restricted type of box cap everyone will get the same results no mater >what metrics they use. If we do not do this we need to specify in the >Profile what the values are for top line and bottom line are for each of the >standard fonts. Base-cap is attractive because it easily solves the problem. But I wonder if it might introduce other problems? For example, I recall some of Stuart's use cases for using the gOE to reposition things contiguous to each other. Base-cap would cause descenders to be outside of the box, and diacriticals to be outside the box. While acceptable for hit testing, I don't know if it works for abutting objects flush, non-overlapping. Another possible problem: it disagrees with the SVG definition (full glyph box), which is the definition we use for non-RestrText. Maybe: use 1000 for the bottom-top extent? That would give everyone the same proportions, encompassing all of the text. But that would still, for Helvetica, leave the question of exactly where baseline is in the box -- how much of the leftover (1000-718) is below baseline, and how much is above. Our HSI software also used Microcosm fonts, and we commissioned them to write a text generator also. (Wish I still had that stuff!) Do you think the glyph coordinate system starts at (0,0) lower-left-box corner? Or (0,0) baseline-left-edge? Or ...? Or maybe: put a switch on gOE. Values: 1.) full-glyph-box, or 2.) baseline-capline [, or 3.) actual-strokes]. #3 would be really expensive. #1 might be hard to get consistent results. I think, upon further reflection, that bottom-top might be doable, if we just agree on and document the numbers. It is only 13 fonts, whose individual glyph metrics are spelled out in CGM:1999 appendix I, including the capheight value. And after all, Helvetica is Helvetica, right? I.e., there should not be variations. We have documented the glyph widths for a 1000x1000 box, and the capheight. Why not document (in WebCGM) the bottom-line and top-line? -Lofton. >-----Original Message----- >From: Lofton Henderson [mailto:lofton@rockynet.com] >Sent: Tuesday, April 21, 2009 11:43 AM >To: 'WebCGM' >Subject: Re: [cgmo-webcgm] getObjectExtent for text > >Forrest, All -- > >Good question. If you look at p.441 of CGM:1999... > >1.) capheight agrees (718) >2.) there are chars with diacritical marks, like A-umlaut. > >Therefore #2 implies that Top > Cap. > >Does anyone have the answer, what is (and where-to-find) the Top value for >Helvetica (and the other 12 standard fonts)? > >Forrest, what is the difference if you use the Helvetica 'ymax' >value? I.e., what does the gOE text expect and what is the ymax-based >result? > >-Lofton. > >p.s. I forgot to include this link earlier: >[1] >http://www.w3.org/Graphics/WebCGM/drafts/current-editor-21/WebCGM21-DOM.htm l >#getObjectExtent > > >At 11:17 AM 4/21/2009 -0500, Forrest Carpenter wrote: > >All, > > > >For text the getObjectExtent is based on bottomline-to-topline distance of > >the font. Is there some where this is specified for the standard WebCGM > >fonts? We are using metrics from Microcosm (Tom Wright) for ours. For > >Helvetica we have cap height = 718, ascender = 718 and descender = 207 >using > >these values we match Stuart's values for the text string in the > >getObjectExtentTransformed test. In our calculations we use the yMax value > >for the topline calculation which for this font is 931 and gives a >different > >value than Stuart's. What values should be used for the topline >calculation? > > > >Regards, > >Forrest > > > > > >-----Original Message----- > >From: Galt, Stuart A [mailto:stuart.a.galt@boeing.com] > >Sent: Monday, April 20, 2009 6:07 PM > >To: WebCGM > >Subject: [cgmo-webcgm] getObjectExtent and getObjectExtentTransformed > > > >Hello, > > > >I have updated the getObjectExtent.htm and the > >getObjectExtentTransformed.htm > >files on the FTP server. > > > >For both tests: > >- I have added a try block so if the getObjectExtent() call fails then I > > > > put "getObjectExtent not implemented" in the result table. > > > >- Changed the calculated box value for the text string to take into > >account > > the decender of the 'g' > > > >For getObjectExtentTransformed: > >- Changed the how far the circle was translated from 40 to 120. > > > >Stuart. > > > >-- > >Stuart Galt > >SGML Resource Group > >stuart.a.galt@boeing.com > >(206) 544-3656 > > > > > >--------------------------------------------------------------------- > >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 > > > > > > > > > >--------------------------------------------------------------------- > >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 > > >--------------------------------------------------------------------- >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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]