Re: Features needed for high-end DTP apps

[Owen Taylor <otaylor redhat com>]

Patrick <pabos glypsube org> writes:

> 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.
> 
> 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...

I'm glad to hear that :-)
 
> - 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.

No. Pango 1.0 was primarily developed with GTK+ widgets as the
target, so those parts of Pango are best developed, but the
overall design of Pango is meant to be general.
 
> - The Pango line-breaking algorithm is currently simplistic 

I'm not sure _simplistic_ is the right term :-) It's a straightforward
greedy algorithm, yes, but not particular simple code or code
that was easy to get right.

> and doesn't  do hyphenation.
> 	- Line-breaking is language specific ... maybe Pango will
> 	eventually support modular line-breaking routines?

No hyphenation yet, yes.

It does support language specific line break location determination 
algorithms. If you go below PangoLayout you can do whatever line-break 
algorithm you want; we don't currently allow plugging new line-break
algorithms into PangoLayout; I think that would be an interesting
thing to investigate. It's not going to be a simple API setup.

> 	- The computational cost of some line breaking routines (TeX?)
> 	might make it unsuitable for inclusion in Pango?

Other than speed consideratons, TeX line breaking is unsuitable
for interactive apps because it is very disconcerting to the user
to have parts of the paragraph before the cursor changing as
you edit.
 
> - Kerning.
> 	- This may be done at some point (or already

Kerning based on font-information is a backend by backend thing.
Adding support for binomial kerning pairs to the Xft and FT2 backends
should be relatively straightforward.

> , but adding manual
> 	kerning to this may be unrealistic.

Manual kerning would be perfectly reasonable addition, and in fact,
you might already be able to do it it using pango_attr_shape_new() and
a logical rect with negative width.
 
> - Vertical text orientation is not done.
> 	- I think this is planned for some point in time, since it is
> 	necessary/useful for some languages.

It's definitely planned.
 
> - Full justification and other justification options are not done (w/
> capabilities for extending glyphs rather than the spacing as needed for
> Arabic, etc...).
> 	- Planned.
> 
> - Arbitrarily shaped text containers. Pango always assumes a rectangular
> box for the text.
> 	- Beyond basic Pango's needs?

It's a lot simpler to handle then most of the stuff you are talking
about here (well, combining it with global line break algorithms
could be fun)

> - Subpixel positioning is not done.
> 	- ?

Pango itself is completely "subpixel positioning" clean. Backends
don't typically do it because it doesn't work very well with hinting
or glyh caching.
 
> 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.

PangoLayout is pretty darn non-opaque in some areas, I'm afraid!

My thought is that PangoLayout is a lot of hard code, and I'd
rather see support for plugging in new layout algorithms and
enhancing the capabilities of Pango than duplication of a lot
of the hard code.

But indeed PangoLayout is a layer over the guts of Pango and uses
only public interfaces... so it is possible to bypass.

> 	- 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 ...
> - 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 ...

I think consistency between versions of a desktop publishing program
is something you should worry about only after its working pretty
well on its own :-)
 
> MORE QUESTIONS
> --------------
> - Font support.
> 	- I'm not clear on OpenType support - is it available for both Freetype
> and Xft rendering systems or is it a separate rendering system from
> both?

The support in pango-ot.h is a generic OpenType interface that is
used by both FreeType and Xft backends; it can't be used by the Win32
backend currently.

> 	- The term rendering system is confusing as well: I think its just a
> consistent font system along with its rasterization method (ie. X: X
> fonts and old X font rendering, freetype: freetype and bitmap rendering,
> Xft: freetype and server-side Xrender rendering, Win32: Windows font
> system and Windows rendering ...).

Basically. It really refers most exactly to the font system; a single
font system could output to multiple targets; you could have a postscript
output target that used the PangoXft font system.

> - My understanding of the Pango shaping process is that it takes care of
> glyph construction involving things like diacritics, ligatures,
> contextual glyphs (ie. Arabic) and Complex Text Language (CTL)
> requirements.
> 
> - Rendering systems: Different rendering systems will give different
> results for shaping, font metrics, etc... what implications will this
> have for consistent layout?

If you want consistent layout, you need to use the _same_ rendering
system for printer and screen output.

Regards,
                                        Owen