Bounding Boxes for Glyphs in Type 2(1) Charstrings

[v***@gmail.com]

Hi Everyone,

I'm currently working with a Type 2 font, and need to retrieve bounding
boxes for glyphs. I am looking through the Type 2 charstring spec
(which is fairly similar to Type 1 charstrings) and don't see any
'bounding box' operator or something similar - does this mean the only
way to get a bounding box is to manually step through the glyph path
and keep track of the bounds by hand? (Assuming there is no bounding
box field in the top dict)

If so, is there a quick way to do so (without doing hint/flex, subrs,
etc lookups)?

Thanks,
Jeff

[Ken Sharp]

Post by v***@gmail.com
I'm currently working with a Type 2 font, and need to retrieve bounding
boxes for glyphs.

Thinking about this further since my reply to your first post...

For what purpose do you need the bounding box of a glyph ? You can't get
that from a type 1 program either you know, except by processing a
setcachedevice operation.

Notice that the type 1 spec says 'It executes a setcachedevice
operation, using a bounding box it computes directly from the character
outline' That is, it actually renders the glyph, and then tells the
cache how big it is, the glyph is (obviously) rendered at the correct
point size and resolution.

Post by v***@gmail.com
I am looking through the Type 2 charstring spec
(which is fairly similar to Type 1 charstrings) and don't see any
'bounding box' operator or something similar -

I don't think there's anything like that in the type 1 spec either. The
setcachedevice operator is executed by the font interpreter, which
calculates the bounding box by rendering the glyph outline.
('rendering' in this case doesn't mean actually laying down pixels, just
calculating where they would lie)

Post by v***@gmail.com
way to get a bounding box is to manually step through the glyph path
and keep track of the bounds by hand? (Assuming there is no bounding
box field in the top dict)

Even if there were a bounding box in the top dict (which there isn't as
far as I'm aware) analogous to the /FontBBox, all that would tell you is
the maximum bounding box, not the bounds of each glyph.

Post by v***@gmail.com
If so, is there a quick way to do so (without doing hint/flex, subrs,
etc lookups)?

No, that's what the font interpreter is for. As you note, the bounding
box of the glyph (in device space) will depend on the font size and the
resolution of the device. You can probably ignore flex, and hinting,
unless you need a pixel perfect result. If you do need a pixel perfect
result then you have several problems:

1) The only way to figure this out is to do the entire job of a font
interpreter. Its a lot of work.

2) Even if you do that, your code will undoubtedly not match any real-
world implementation, so getting pixel-perfect results is defeated
anyway, unless you are doing the rendering yourself, in which case you
need a full font interpreter (round and round and round we go ;-)


So it isn't clear to me what you want, exactly, or why you want it, and
what you intend to do with it once you have it :-)

Perhaps if you could give a little background ?


Ken

[v***@gmail.com]

Hi Ken,

Thanks for all the insight (and sorry about the duplicate post, haha,
groups was being a pain yesterday). I'm currently working on
converting from an XPS (the new 'PDF' from Microsoft) to a PS document.
When I get a font from the XPS, it always comes to me in OpenType
format (which means it can include a CFF font as the Adobe side of
OpenType). When I do get a CFF, the XPS Spec gives a number of ways to
get the vertical/horizontal metrics from the font, and in certain cases
when a number of OTF Tables don't contain any information, the spec
says to "calculate the top of the glyph's bounding box from the CFF
charstring data". So in essence I don't necessarily need the entire
bounding box, but just the highest point.

I am still a bit interested in how indepth the XPS Viewer (a GDI
interpreter supplied by Microsoft) actually goes in its calculation,
the only hint that I have is from that one sentence which doesn't give
much info :P I imagine I wouldn't necessarily need pixel perfect
results however, so ignoring hinting and flexing might be a good option
(though stepping through the charstring might take a large chunk of
time depending on how large character descriptions can get).

Thanks again,
Jeff

Post by Ken Sharp

Post by v***@gmail.com
I'm currently working with a Type 2 font, and need to retrieve bounding
boxes for glyphs.

Thinking about this further since my reply to your first post...
For what purpose do you need the bounding box of a glyph ? You can't get
that from a type 1 program either you know, except by processing a
setcachedevice operation.
Notice that the type 1 spec says 'It executes a setcachedevice
operation, using a bounding box it computes directly from the character
outline' That is, it actually renders the glyph, and then tells the
cache how big it is, the glyph is (obviously) rendered at the correct
point size and resolution.

Post by v***@gmail.com
I am looking through the Type 2 charstring spec
(which is fairly similar to Type 1 charstrings) and don't see any
'bounding box' operator or something similar -

I don't think there's anything like that in the type 1 spec either. The
setcachedevice operator is executed by the font interpreter, which
calculates the bounding box by rendering the glyph outline.
('rendering' in this case doesn't mean actually laying down pixels, just
calculating where they would lie)

Post by v***@gmail.com
way to get a bounding box is to manually step through the glyph path
and keep track of the bounds by hand? (Assuming there is no bounding
box field in the top dict)

Even if there were a bounding box in the top dict (which there isn't as
far as I'm aware) analogous to the /FontBBox, all that would tell you is
the maximum bounding box, not the bounds of each glyph.

Post by v***@gmail.com
If so, is there a quick way to do so (without doing hint/flex, subrs,
etc lookups)?

No, that's what the font interpreter is for. As you note, the bounding
box of the glyph (in device space) will depend on the font size and the
resolution of the device. You can probably ignore flex, and hinting,
unless you need a pixel perfect result. If you do need a pixel perfect
1) The only way to figure this out is to do the entire job of a font
interpreter. Its a lot of work.
2) Even if you do that, your code will undoubtedly not match any real-
world implementation, so getting pixel-perfect results is defeated
anyway, unless you are doing the rendering yourself, in which case you
need a full font interpreter (round and round and round we go ;-)
So it isn't clear to me what you want, exactly, or why you want it, and
what you intend to do with it once you have it :-)
Perhaps if you could give a little background ?
Ken

[v***@gmail.com]

So in reading through the Type 1 Charstrings spec more, it seems like
the charstring is required (or perhaps strongly suggested?) to mark off
a top and bottom hstem hint (even if it has no horizontal stem at those
places, it creates "ghost" stems to take their place [Adobe Type 1 Spec
pg 57]).

Any idea if these could be searched for to quickly find a 'height' for
the glyph by subtracting the topmost from the bottommost? Or if all
fonts actually do create "ghost" stems or not (ie: are all glyph
charstrings guaranteed to have a bottom and top hstem?) The type 2
spec doesn't make mention of "ghost" stems, but this may just be
implied given that the horizontal/vertical hinting hasn't changed
between the formats.

Thanks,
Jeff

[Ken Sharp]

Post by v***@gmail.com
So in reading through the Type 1 Charstrings spec more, it seems like
the charstring is required (or perhaps strongly suggested?) to mark off
a top and bottom hstem hint (even if it has no horizontal stem at those

I don't think its a requirement, If I remember correctly ghost hints
were a later addition to the spec, and so can't be relied upon to be
present in early fonts anyway.

Post by v***@gmail.com
Any idea if these could be searched for to quickly find a 'height' for
the glyph by subtracting the topmost from the bottommost?

A type 1 charstring interpreter isn't hard to write, its trivial to
throw away everything except hints, so yes, you could do it. It wouldn't
be a whole lot faster (in operation, writing the code would be easier)
than doign a complete interpretation job.

Post by v***@gmail.com
Or if all
fonts actually do create "ghost" stems or not (ie: are all glyph
charstrings guaranteed to have a bottom and top hstem?)

I've seen plenty of fonts with no hints at all, and numerous others with
no top/bottom ghost hints. There are a lot of font tools about, and a
lot of them produce pretty nasty fonts (Fontogropher is both highly
popular and a major offender IMO).

Post by v***@gmail.com
The type 2
spec doesn't make mention of "ghost" stems, but this may just be
implied given that the horizontal/vertical hinting hasn't changed
between the formats.

Hmm, can't say I've ever thought about it. However I personally wouldn't
rely on something like this if I needed a bounding box. I would
interpret the whole outline and calculate the bounds. As I said, I think
its safe to ignore hinting for your purposes, which should only make a
difference of ~1 pixel on output anyway. Even at 600 dpi that should be
pretty well invisible.


Ken

[Ken Sharp]

Post by v***@gmail.com
When I get a font from the XPS, it always comes to me in OpenType
format (which means it can include a CFF font as the Adobe side of
OpenType). When I do get a CFF, the XPS Spec gives a number of ways to
get the vertical/horizontal metrics from the font, and in certain cases
when a number of OTF Tables don't contain any information, the spec
says to "calculate the top of the glyph's bounding box from the CFF
charstring data". So in essence I don't necessarily need the entire
bounding box, but just the highest point.

Hmm... Do you really care ? IIRC you either use the advance given in the
XPS file to position the next glyph or, if that isn't present, the
advance from the font.

You only need the 'metrics' if you want to generate the XPS file. Yo
know the outline is going to be OK, because you are going to convert
that from the OTF/CFF font. You know the size (its fromt eh XPS
document), you know where to put the glyp (again from the XPS document).

So in PostScript terms you set up the font, and show the glyph at the
correct position. If there are no specified widths, then you are at the
correct position for the net glyph and can show that. If there are, then
you need to adjust the current point by using the specified width for
that glyph (kerning in effect).

I'm not sure under what conditions you need the information about the
glyph bounding box. But then I'm not an XPS expert...

Post by v***@gmail.com
much info :P I imagine I wouldn't necessarily need pixel perfect
results however, so ignoring hinting and flexing might be a good option
(though stepping through the charstring might take a large chunk of
time depending on how large character descriptions can get).

Even complex charstrings can be handled relatively quickly. Its a good
idea to cache results like this, of course, since glyphs are often
reused, and there's no point in repeating the effort.


Ken

[v***@gmail.com]

That's true in most cases (we've only seen the need to go into the font
in two specific tests), but XPS doesn't require that the position
information be specified. And if not specified, you are supposed to go
into the OTF file and look at various tables. In some cases (when a
CFF font is being used), the OTF file opts to ignore any tables that
would describe vertical positioning - and thus XPS requires that a
consumer go into the CFF font itself and get the bounding box (so it
can figure out vertical positioning). This wouldn't necessarily be an
issue if interpreters would correctly get the vertical positioning
correct in the first place, but it seems that different interpreters
dissagree on where to put the glyph (and some interpreters ignore the
fact that you're doing vertical writing altogeather, meaning you must
give exact position data).

So yeah, down the trail of calculating the box I go! (I got a good
start yesterday thanks to your help Ken :) )

Thanks again,
Jeff