Parsing CFF blocks but getting different width from bounding box

[Mopaxian]

Hi,

I'm writing an opentype parser, and right now while parsing CFF blocks using Adobe's Kozuka Mincho Pro R font, version 4.001, I am getting strange results: The width values that I find for glyphs based on the charstring appear to be the right values, but when I do a quick SVG verification, making a rectangle with the glyph's width and then drawing the glyph inside it, the width of the bounding box for the character and the indicated glyph width do not match.

For instance, the glyph for plain lowercase latin 'j', index 75, has the follow charstring according to "tx":

[tx -6 -g 75 KozMinProR.otf]

## glyph[tag] {cid,iFD,LanguageGroup,path}

glyph[75] {75,12,0,

  266 width

  ...

  endchar}

When I fetch the data associated with this letter, my parser gives me the following data:

{"letter":"j", "width": 266, "height": 970, "baseline" : 880, "bounds" : [-107,-268,189,702], "path" : "m139 702c-29 0-50-25-50

-64c0-39 21-63 50-63c29 0 50 24 50 63c0 35-18 64-50 64m46-194l-10 6c-45-26-78-38-142-47l0-24c70 0 74-1 74-68l0-339c0-115-6-269-

87-269c-21 0-37 12-51 39c-13 25-23 41-47 41c-18 0-29-12-29-30c0-41 57-85 125-85c149 0 167 163 167 310"}

In this result, "path" is simply a compacted SVG path string based on the path instructions in the type2 charstring, and the "bounds" array is derived from simply running through the path and recording min/max bound values for x/y. ("height" is based on the bounds, "baseline" is the vertOriginY from the VORG table associated with the character's glyph index).

For this glyph, the indicated width is actually smaller than the width of the vector drawing that results from interpreting the outline data.

If I open photoshop, and write the letter "j" using the Kozuka Mincho Pro font, with weight "R", at a pointsize 1000 (to match the quad size for this font) then the width as indicated by the text cursor is 266 pixels, but the bounding box for the character when picking "free transform" has a width of 374 pixels. Where are these 108 pixels recorded in the font?

I'm currently using {fontdict->nominalwidth + charstring diff. with nominal} for width (or if there is no width value in the charstring, the fontdict's default width value) and base the glyph's bounding box on the vector-trace of the outline data - am I forgetting something in order to get the correct width/bounds?

- Mike "Pomax" Kamermans

nihongoresources.com

[MiguelSousa]

Mike,

Is this question different from the one you posted to the OpenType list?

The answer you got there was to use the -dcf option of tx and to run the command "tx -dcf -h" to get more information.

Do you still need more info beyond that?

[Mopaxian]

no, this question is very different.

I'm getting all the charstring information correctly, my interpretation matches what tx claims the interpretation should be, but somehow the width value derived from the charstring is not enough. There's an extra 108 pixels somewhere that determines the visual width, and I don't know where they're located. If I use max(charstring width, boundingbox width) then I still don't get to the width that Adobe's type manager gives when doing a free transform of the letter in Photoshop.

charstring width: 266 units

bounding box width: 296 units (already wider than the glyph width indicates)

full width according to type manager: 374 units

note that this real width exists even in the absence of other characters, so it's not derived from a specific kerning pair.

(red is charstring width, blue is bounding box width, black is full width)

[Mopaxian · Accepted solution]

Or the reason is obvious and I've been staring at it so long I completely missed it several times. It's of course {charstring width - bounding.minx}, which is 266 - (-107) = 373

Sorry for wasting some time with that one (don't you hate it when this happens =_=)

- Mike

[Mopaxian]

marked as answered - I simply missed the obvious.

[MiguelSousa]

Glad to see you got it.