[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cgmo-webcgm] getObjectExtent for text
Forrest -- Thanks for your comments, and especially the offer to generate more info! More information is what we need now, to decide how to disambiguate the result of gOE(text). Next week, when all implementors are present, we can sort out the best solution. What would really be great is some pictures. Could we (anyone) draw a string with at least one descender, at least one diacritical, and some reference lines? Maybe this string: "Text string: Ö". (That final character is O-umlaut.) The reference lines would be baseline, capline, ymin, ymax, and any other interesting vertical reference points that might be in the font. (And where might the canonical 1000 vertical glyph-box extent of CGM:1999 I.2.2 be?) -Lofton. p.s. As I looked at WinXP Character Map when copying Ö (Arial) -- programs > accessories > system tools > character map -- I see interesting distribution of whitespace. Tight fit on top, extra whitespace below descenders on bottom. Is that significant? I.e., does that font/glyph definition include extra whitespace beyond basic glyph box for aesthetic inter-line spacing? At 12:43 PM 4/22/2009 -0500, Forrest Carpenter wrote: >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 > > > > >--------------------------------------------------------------------- >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]