font height calculations with positive (vs negative) descent specified by the font

[James K]

I've got a question about font height calculations because I'm having
issues with certain fonts not leaving enough vertical room in my
output. From a thread last October it looks like there's an assumption
that descent is a negative number:
http://groups.google.com/group/prawn-ruby/browse_thread/thread/a744d3e6c0d93cab/c4fa5fd5c46c815a?lnk=gst&q=font+height#c4fa5fd5c46c815a

1) :at specifies the baseline position. without the :at, you are
using the current y value which will specify the top edge of the text
(including a line gap)
2) font.height is equal to the ascender + descender + line_gap
3) and remember each font style will have different values for these
4) descender is actually a negative value so font.height is more
accurately ascender-descender+line_gap

I am working with a font (Lucida Fax) that has a positive descent
specified. Is that a violation of a font standard, or should prawn be
tolerant of this and negate the descent if it's positive? I imagine
this would be an easy enough change, and I'll probably patch it in to
get this working if so, but I would like to know if this is something
that I should contribute back, or if this is an aberration?

Here's the output of ttfunk for Lucida Fax (that renders jumbled-
vertically), followed by MS gothic (which renders fine) - note the
sign difference on the descender field

ruby example.rb ../ruby-pdf/LucidaFaxRegular.ttf
-- FONT ------------------------------------
revision : 000100c4
name : Lucida Fax Regular, Lucida Fax, Lucida Fax, Lucida Fax
Regular, Lucida Fax, Lucida Fax, Lucida Fax, Lucida Fax, Lucida Fax,
Lucida Fax, Lucida Fax, Lucida Fax, Lucida Fax, Lucida Fax
family : Lucida Fax, Lucida Fax
subfamily : Regular, normal, Standard, Regular, Normal, Normaali,
Normal, Normale, Standaard, Normal, Normal, Normal, Normal, Normal
postscript: LucidaFax
-- FONT METRICS ----------------------------
units/em : 2048
ascent : 1579
descent : 420
line gap : 49
bbox : (-592,-420)-(2100,1925)
-- SIMPLE CHARACTER -> GLYPH LOOKUP --------
character : ☜
character code: 9756
glyph id : 0
glyph type : simple
glyph size : 78b
glyph bbox : (128,0)-(896,1480)
-- COMPOUND CHARACTER -> GLYPH LOOKUP ------
character : ë
character code: 235
glyph id : 115
glyph type : compound
glyph size : 46b
glyph bbox : (123,-25)-(1004,1456)
components : 2 [72, 142]

ruby example.rb "/Users/jkk/Library/Fonts/MS Gothic.ttf"
-- FONT ------------------------------------
revision : 0002851f
name : MS Gothic, ?l?r ?S?V?b?N, MS Gothic, ?-?3 0?0?0?0?
family : MS Gothic, ?l?r ?S?V?b?N, MS Gothic, ?-?3 0?0?0?0?
subfamily : Regular, Regular, Regular, jn?
postscript: MS-Gothic
-- FONT METRICS ----------------------------
units/em : 256
ascent : 220
descent : -36
line gap : 0
bbox : (-31,-35)-(255,220)
-- SIMPLE CHARACTER -> GLYPH LOOKUP --------
character : ☜
character code: 9756
glyph id : 1805
glyph type : simple
glyph size : 396b
glyph bbox : (9,33)-(243,145)
-- COMPOUND CHARACTER -> GLYPH LOOKUP ------
character : ë
character code: 235
glyph id : 173
glyph type : simple
glyph size : 180b
glyph bbox : (13,2)-(115,171)



thanks for your insights.

[Gregory Brown]

On Mon, May 25, 2009 at 12:08 PM, James K <jkeb...@gmail.com> wrote:

> I am working with a font (Lucida Fax) that has a positive descent
> specified. Is that a violation of a font standard, or should prawn be
> tolerant of this and negate the descent if it's positive? I imagine
> this would be an easy enough change, and I'll probably patch it in to
> get this working if so, but I would like to know if this is something
> that I should contribute back, or if this is an aberration?

The TTF reference[0] says:

"The values for ascent, descent and lineGap represent the design
intentions of the font's creator rather than any computed value."

I don't feel comfortable making assumptions here, though if I can do
something to make your patch easier to add at the user level, let me
know.

-greg

[0] http://developer.apple.com/textfonts/TTRefMan/RM06/Chap6hhea.html

[James Kebinger]

One additional data point here - I opened up the font that has a positive descent in FontForge in order to see if I could flip the sign on the descent and rebuild the font, but FontForge refuses to save with a negative descent.

I've created a fork on github to take a look at how prawn calculates height. Right now there are five test failures, all in test_spec (a text box) - is that expected? (just making sure my environment is ok before proceeding)

thanks
-james

[James Kebinger]

Thanks to the ttfunk source, I was able to track down some more information about my errant font. I saw that the descent is set by first checking the os2 data, then the horizontal header data. I checked that data using FontForge, and found weird data - a value of -59 for Typo Ascent Offset, and 830 for Typo Descent Offset.
So after learning more about font meta-data than I ever imagined, I can fix the font I need for my current project by zeroing out these two fields, and now prawn can use the font just fine.
As Greg said originally, it is probably dangerous to make assumptions to attempt to handle cases like this, especially without knowing how common errors like this may or may not be. In this case, looking at the odd signs on the Typo data might have been enough to possibly ignore them at the ttfunk level and fall back to the horizontal header information, but I don't know enough about fonts to make that call.

-james

[Gregory Brown]

On Mon, May 25, 2009 at 7:01 PM, James Kebinger <jkeb...@gmail.com> wrote:

> One additional data point here - I opened up the font that has a positive
> descent in FontForge in order to see if I could flip the sign on the descent
> and rebuild the font, but FontForge refuses to save with a negative descent.
>
> I've created a fork on github to take a look at how prawn calculates height.
> Right now there are five test failures, all in test_spec (a text box) - is
> that expected? (just making sure my environment is ok before proceeding)

If you didn't fork within the last couple hours, you probably have a
broken build. Check spec_helper.rb. If it requires prawn instead of
prawn/core, do a pull.