On Nov 10, 2007, at 3:47 PM, Rick Gigger wrote:
A few questions:
1. Are you going to be using xsl-fo for your layout model?
No. XSL-FO does not provide enough fidelity for my needs. The text
model I am working on is based on the OpenStep (Cocoa) frameworks,
and has an attributed string class at its core. Attributes such as
font, color, size, kerning, line height, tab stops, etc. may be
applied to arbitrary ranges of characters within such strings.
These strings are then fed to a layout manager, which draws the
strings in some arbitrarily-sized rectangular region. The layout
manager uses a typesetter class to convert characters to glyphs, and
calculates line fragments (line breaks) as needed. I don't know if
I'll have time in this first revision, but ultimately, a typesetter
class will be available which fully supports ligatures and kerning
hints which may be present in a font program, as well as right-to-
left and top-to-bottom writing systems.
Each attributed string is essentially an independent RTF document, so
any formatting you can accomplish with WordPad on Windows or TextEdit
on OS X should then be possible within Zend_Pdf.
These classes will be very powerful, but will still be relatively low-
level. The building blocks for creating pages, tables, etc. will be
in place, but will require a fair amount code to manage the actual
text blocks in the userland code.
XSL-FO has great strength in creating document flows (tables, multi-
page runs, headers, footers, etc.). Alexander is working on the
design for an FO interpreter for Zend_Pdf (http://framework.zend.com/
wiki/x/nI0), which will ultimately become a client of these lower-
level classes.
In the end, Zend_Pdf will have three useful layers for document
layout: an FO interpreter for multi-page document flows, the lower-
level layout classes for drawing attributed strings with finer-
grained control, and the existing drawing primitives already in
Zend_Pdf for precise glyph-by-glyph placement.
2. Does your revised font code involve support for unicode and/or
non Latin-1 fonts?
The font code in Zend_Pdf can already handle Unicode character sets.
All fonts used by the framework, whether the standard 14 PDF fonts,
or custom OpenType fonts, extract and use a Unicode character-to-
glyph map for drawing.
The reason that Zend_Pdf cannot currently draw non-Latin-1 strings
lies in the text encoding method used when drawing the glyphs on the
page. Right now, we've hard-coded using the WinAnsiEncoding method
when drawing text (see Zend_Pdf_Resource_Font::encodeString()),
primarily because it's a built-in encoding and doesn't require a lot
of code to support.
Drawing characters outside the Latin-1 range requires several changes
to the font program's resource dictionary. At best, a /Differences
array must be added, and at worst -- especially for CJK fonts -- a
CID font would need to be created. Neither approach is very easy at
this point because of how Zend_Pdf_Resource objects create and manage
their resource dictionary.
I began the work necessary for full Unicode support in the framework
last year with the introduction of TrueType fonts. I now have a
paying project which will allow me to return to this code and
complete it. I will have more to report in this area in the coming
weeks.
Just curious, if that function works correctly why has such a basic
function as text measuring not been included in Zend_Pdf if the
work has already been done.
All of the primitives exist in the framework, and you'll notice that
ZF-313 is over a year old. Anyone who requires this support for their
particular project can easily do the calculations themselves. The
question comes up every two or three months and we generally direct
those people to that function.
The primary reason such a function does not exist in the framework
right now is support. The function I wrote for ZF-313 works, but does
not do the calculation in the most efficient way possible,
particularly if you're trying to use it to determine where to break a
line (it's a Shlemiel the painter's algorithm -- http://
www.joelonsoftware.com/articles/fog0000000319.html). Furthermore,
once a function appears in the framework, there are backwards-
compatibility issues that must be considered.
Since 95% of the people who ask the question, "How do I measure a
line of text?" are really asking, "How do I wrap the long lines of a
paragraph?" or "How do I center this title?", creating and supporting
a string measurement function is the wrong problem for the framework
to solve.
Instead, the framework should provide layout classes that make it
drop-dead simple to wrap long lines of text and center titles on a
page. This is what I've been focusing on. My goal is to not have to
create a text measurement function for the framework because the
layout classes provided make it unnecessary.
--
Willie Alberty, Owner
Spenlen Media
[EMAIL PROTECTED]
http://www.spenlen.com/
