On Nov 15, 2006, at 6:55 AM, Brent Robinson wrote:
Thanks Drew you definitely got me on the right track. I have now
written a function that will use the PDF component to provide the
glyph size and work for any font. I was not sure about the /1000 *
font size thing which you got me...
Drew and Brent-
Did you miss my message from yesterday morning? <http://
www.nabble.com/forum/ViewPost.jtp?post=7343094&framed=y&skin=16154>
I commend you for your ingenuity in developing those functions. While
they may be working now for your immediate needs, they have a few
problems, which may cause you grief in the future:
Drew's function is recreating the glyph width arrays ($char_wx) which
are already provided by the framework for every font ($font->
widthsForGlyphs($glyphArray)), both for the built-in 14 PDF fonts as
well as any custom TrueType or OpenType fonts you may be using. This
isn't necessarily a problem, but it's a redundancy that you don't
need to worry about.
Both functions assume a 1000 unit-per-em glyph space. This is true
for the built-in 14 PDF fonts, and remains true for many popular
third-party fonts, but is not guaranteed. In fact, while writing the
font classes I encountered many fonts that use a 2048 unit-per-em
glyph space (notice that this is a power-of-2, which speeds many
calculations at rasterization time). The framework provides a
function which returns the units-per-em used by the font: $font-
>getUnitsPerEm()
Finally, glyph indexes are not the same as character codes. The
conversion from character code to glyph index ($glyph_array[] = ord
($character)) only coincidentally works for the built-in 14 PDF
fonts, and then only for the basic ASCII character set (0-127). If
you try to use any of the extended Latin-1 characters (é, å, ö,
etc.), or use this function with many third-party TrueType fonts, you
will receive incorrect widths.
Character-to-glyph mapping is one of the more difficult topics
related to fonts. In a nutshell, fonts do not contain characters,
they contain glyphs (shapes). Two fonts may render the character A in
completely different ways: a serif font using three simple straight
lines, but a calligraphic font could use dozens of curves. In
addition, a font may not contain a glyph for an e acute (é)
character, and may choose instead to draw it as a plain e.
Every font contains one or more character-to-glyph maps (called
cmaps) which are responsible for translating characters into the
specific glyphs that should be drawn. The Zend_Pdf_Cmap classes
provide the mapping between character codes and glyph indexes for the
framework. Every font has its own Zend_Pdf_Cmap object which should
be used for this conversion: $font->cmap->glyphNumbersForCharacters
($characters)
The function I provided yesterday takes the above items into
consideration. It will work reliably for any font, and properly
returns the width of the "missing character glyph" (which is
sometimes rendered as an empty box) if your string contains
characters which have no glyph representations in the font. I
extracted it from my in-progress layout classes which will be coming
to the framework Real Soon Now. I would recommend using that function
until the new layout classes are available.
--
Willie Alberty, Owner
Spenlen Media
[EMAIL PROTECTED]
http://www.spenlen.com/
