Re: Features needed for high-end DTP apps

[Damon Chaplin <damon kendo fsnet co uk>]

On Sat, 2002-10-19 at 22:19, Patrick wrote:
> Hi Damon.
> I've been working on a design for a DTP-like application as well in
> recent weeks. I'd be interested in comments on the quality of the books
> you've read.

"Quark XPress 5: The Complete Reference" (McGraw-Hill/Osborne) was
pretty good for giving me a good all-round knowledge of XPress. It is
very long though, about 770 pages, and could have been more concise.

"Microsoft Publisher 2000 At a Glance" (Microsoft Press) was good for
getting an overview of Publisher, and seeing pictures of lots of the
major dialogs etc.

I also read "Design and Typography in easy steps" (Computer Step) and
"Teach Yourself Desktop Publishing" (Hodder Headling). I enjoyed both of
them (partly because they are quite small!). The latter book gives an
overview of the entire DTP process as well as covering typography. 

So all of them were fairly useful, though I haven't read enough books to
know which is the best DTP book. (Maybe someone else can recommend one.)
I'd like to see a book on InDesign 2 as well, since that seems to
include some more advanced features.


> I'll transcribe some notes I have taken in my own research below. It
> repeats some items on your list but may still add something to the
> discussion. My preliminary investigation of Pango is as follows (Pango
> people please correct where wrong):
> 
> NB: When I say planned I'm relaying what I've read not what is an
> official Pango maintainers decision...
> 
> - Pango is primarily intended for multi-language display in GTK+
> widgets. It could be used for other purposes but in speed/quality
> trade-offs speed wins because it has to be used for all text drawing
> everywhere.

The original goals for Pango also included high quality typography. But
yes, Pango needs to remain fast enough for GTK+. So advanced features
could be made optional if they are too slow for general use.


> - The Pango line-breaking algorithm is currently simplistic and doesn't
> do hyphenation.
> 	- Line-breaking is language specific ... maybe Pango will
> 	eventually support modular line-breaking routines?
> 	- The computational cost of some line breaking routines (TeX?)
> 	might make it unsuitable for inclusion in Pango?

Pango does follow Unicode for line-breaking, I believe. See
pango/break.c. It conforms to Unicode Technical Report #14, which seems
to cover all scripts.

Hyphenation would involve doing something like inserting additional soft
hyphens into the words before passing to the line breaking code.

I don't know about the computational cost issue. But we should be able
to manage whatever XPress/InDesign do. Caching/storing layout
information helps too.


> - Kerning.
> 	- This may be done at some point (or already), but adding manual
> 	kerning to this may be unrealistic.

It looks like the ft2 backend already does kerning.
I don't think manual kerning is very difficult - it is just a matter of
passing a custom kerning value in, in an attribute or something.
(Or storing a separate kerning table, for manually kerning fonts.)



> WHAT CAN BE USED?
> -----------------
> - My impression is that an alternate, 'typographic' PangoLayout must be
> created. It could potentially reuse some of the core steps of Pango such
> as itemization, boundary resolution and shaping (I'm listing these from
> the PS document at http://people.redhat.com/otaylor/ols2001/). It
> wouldn't be quite as opaque as PangoLayout current is either.
> 	- As many details about glyph construction, presentation, etc.
> 	and related facilities (cursor position, showing selections,
> 	etc.) should go here.
> 	- Font conversion/embedding/subsetting should be encapsulated
> 	*in this area* (I haven't thought it through yet).
> - It get the feeling that this will parallel Pango in many ways rather
> than extend it ...

Yes, I was thinking along the lines of a PangoLayoutAdvanced as well.
But if we can add features to PangoLayout without slowing it down I
think we should.


> - If the goal of a DTP is be able to provide consistent layout and
> presentation than each aspect of the layout process must be designed
> with versioning in mind. ie. if you change the line-breaking algorithm
> between versions, or the leading calculations, etc... you mess up the
> work that users have done in previous designs. this suggests that the
> layout features should be pluggable so that old layouts can be supported
> in new version of the application. another reason for this is that if
> files from another application with different assumptions about these
> layout parameters are imported, custom routines designed to emulate the
> layout of the other application could be used ...

That is an interesting point. I hadn't thought about that.

Damon