Robert J Burns wrote: > > > I hadn't thought of that, but you're probably right. However this is > either 1) a variation on the same bug I described earlier or 2) a font > that is old and not yet updated to support U+3008 and U+3009. Again, > an updated font, if it supports a particular character, should support > all of canonically equivalent characters for that character since it > does not require producing another glyph, but simply adding a mapping > for an already designed glyph to another character (or character > sequence). > why would U+3008 and U+3009 share the same glyph shape as the canonically equivalent characters? Not sure this is necessary, nor even desirable in many contexts. But harmonising typographic design within multi script fonts can be problematic at the least. One of the reasons its better to use appropriate fonts for the language and contents of a document. The shape of each glyph is a design consideration by the font developer base don the context of its usage. I'd assume the designer would develop the glyph and its metric to suit its usage, and harmonise with the script it is most likely to be used with. The characters may be canonically equivalent, but this does not mean that they need to be visually identical or share a glyph. For instance: a font may use the same glyph for <U+0065 U+0302 U+0301> and <U+1ebf>. Alternatively it may use different glyphs for each. It hinges on the intention of the font's designer and their intended audience and use of the font. But then a well designed font (intended for generic use of Latin script languages) will have more than one glyph available for the character <U+1ebf>. -- Andrew Cunningham Senior Manager, Research and Development Vicnet State Library of Victoria 328 Swanston Street Melbourne VIC 3000 Ph: +61-3-8664-7430 Fax: +61-3-9639-2175 Email: andrewc@vicnet.net.au Alt email: lang.support@gmail.com http://home.vicnet.net.au/~andrewc/ http://www.openroad.net.au http://www.vicnet.net.au http://www.slv.vic.gov.au
Received on Friday, 6 February 2009 00:29:02 UTC