- From: Nikolai Grigoriev <nikolai@grigoriev.ru>
- Date: Sun, 12 Jun 2005 11:30:35 +0400
- To: "Thomas DeWeese" <Thomas.DeWeese@Kodak.com>, "Jon Ferraiolo" <jon.ferraiolo@adobe.com>
- Cc: "Boris Zbarsky" <bzbarsky@MIT.EDU>, <www-svg@w3.org>
Thomas, > Just to clarify the API to access this info already exists on > the text content interface (getExtentOfChar). This is really > a request to add a bbox attribute to the glyph element that > contains the tight bounding box of the glyph data. From a > data normalization point of view this is problematic The data normalization point of view implies that you treat SVG font as a glyph database - i.e. something that roughly corresponds to PFA/PFB in the world of legacy font formats. But fonts are more than glyph databases - they also specify a whole lot of metric data in a form accessible to application writers that don't have access to printer hardware. That's why AFM is always supplied along with PFB for Type1 fonts. > (what > happens when the bbox data doesn't match the real char?). Suppose you have filters in the glyph definition, and your character is blurred. Where does its bbox end? Wouldn't it be natural to permit the font designer to specify edges as he wants them to be? > Also I did some poking and even in AFM the bbox data > appears to be optional. Yes, the spec lets you skip them (though I have never seen a professional font without glyph BBox data in the AFM). Why couldn't the same approach be followed in SVG? Let's make 'bbox' of glyph elements optional. I dare claim that the common usage in typography is to provide app writers with bbox data. SVG seems to part with the tradition. I wonder if data normalization is by itself a sufficient reason for it. Regards, Nikolai
Received on Thursday, 16 June 2005 01:31:09 UTC