Can we reduce the complexity of our SkAdvancedTypefaceMetrics API? |
|
|||||
Project Member Reported by reed@google.com, Apr 18 2013 | Back to list | |||||
Issue descriptionCan the use cases for SkAdvancedTypefaceMetrics be itemized into a set of smaller-looking APIs? This request is part of us reformulating the SkFontHost and SkFontMgr APIs.
Apr 18 2013
,
A historic note: When the API was added some where still skeptical of PDF, so everything that PDF needs to know about fonts is packaged up into the one API. It seems perfectly reasonable to pull it apart into multiple requests; adding info to some existing APIs and creating some new ones. A quick look through the current API... - font name, type, max glyph id, total bbox, em size (there are multiple consumers em size) -- these can all be bundled together as a general info about a font, or pulled apart into separate calls. - style info (flags, italic angle, ascent, descent, stemv, cap height) - get advances (horizontal or vertical) - guess unicode table - get glyph names (type 1 only) multimaster bit isn't really used. Happy to talk more on this if useful.
Apr 18 2013
,
Certainly one way to break things up is if the requested info is per-glyph or font-wide.
Sep 15 2014
,
Sep 2 2015
,
Assigning to current PDF owner.
Oct 22 2015
,
Oct 22 2015
,
why ice-box? I find that interface gigantic and hard-to-understand. Since its private (afaik), lets make it a priority to fix/reduce it.
Oct 22 2015
,
If this should happen, I'm not the person to do it. I think bungeman@ should own this. He can provide any internal API on SkTypeface, as long as everything SkPDFFont needs is provided somehow. |
||||||
►
Sign in to add a comment |
Comment 1 by reed@google.com
, Apr 18 2013Owner: ----