Re: questions for a page layout program

[Lauris Kaplinski <lauris ariman ee>]

First I want to say, I very much hope you layout program will take off
soon. It would certainly be a very pleasant piece of code ;)

On Fri, 2 Jun 2000, Liam Quin wrote:

> Some of you already know I've been considering writing a high-end
> page layout program using/for gnome.
> 
> Such a program will need far more than the X Window font system can
> provide, so I'd have to write a font toolkit.  That's not too
> bad since I've done it before, but others are already looking
> at doing the same.

Some thoughts

1. Document structure
Have you looked at sodipodi internal document structure (sorry - it is not
well documented outside source). The basic idea behind it is 2-level
DOM-like model + different view/controller types. Model clearly separates
data storage from object model, while preserving possibility to update
both, if needed.
Level 1 - completely type agnostic tree. It does not know anything about
document semantics, simply breaks file into nodes with attributes and
implements callbacks for changes
Level 2 - typed tree. Here Tree 1 attributes and nodes are semantically
interpreted and corresponding objects created (Rectangle for <rect>,
Ellipse for <ellipse>)
Now such structure makes implementing editing/output much easier.
- for every different file type or data source you have only to write
type-agnostic Level1 loader.
- all file exporting/printing/displaying etc. can be done with class
funtions of typed Level 2 tree
Controls are divided between levels 1 & 2: General, one-shot editing is
done purely to level 1. Interactive editing to level2, and when operation
stopped, only the final state copied to level 1.
Undo/redo/copy/paste are implemented with level 1 - i.e. in type agnostic
way.

2. Layout engine
Have you tried, to more exactly describe the process, getting
visible/printed output from unicode stream in you imagination. It could be
extremely useful for both Pango and gnome-font people for:
- addressing real users needs
- constraining functionality to areas, where it is really needed, not
  doing things, people would do in user programs anyway

3. Font metrics
Even on >1 bit displays you cannot use font antialiasing for exact
positioning, without heavy visual stress on glyph readability. So the best
I can imagine is to have 2 displaying modes:
SPW (best picture for editing text)
PPbit (real WYSIWYG, also editable)
Both possibly implemented via GnomeCanvas (Gdk and AA modes)

> So I could either
> (1) write a canvas item to display text and let me select it,
>     and hope that I won't have to throw too much away
> 
> (2) use pango in some way (?)
> 
> (3) wait and see what emerges, maybe contributing to a new font
>     infrastructure.

Maybe the Right Way for future is:
- Use GnomeFont as universal abstract font object, binding together
  Pango/X/printer/canvas/whatever fonts
- Use (possibly derived) Pango layout engine, to generate glyph layout and
  to translate input back to text level
- Use (possibly derived) canvas text item, to display positioned glyphs
- Use gnome-print to print positioned glyphs
One of the problem is, that for SPW display you positioned layout has to
include both screen and printer positions.

> You can see a few design ideas at http://www.holoet/~liam/glayout/
> if you're interested.  I am tending towards choice (3) here.
> Option (2) would probably be taking the pango text editing code and
> making a version that rendered text in a shaped outline in a 
> non-rectangular canvas item, with support for the line-breaking,
> hyphenation and ligature features I need.
> 
> Lauris' ideas sound very promising, although I am concerned about
> copyright protection for fonts.  But maybe that's somewhere I
> can help too.
> 
> So the question is, am I sensible in waiting?

Question: Have you thought, how should good font selecting / finding look
like?
I am very unimpressed with standard fontname->bold/italic->size thing.
Instead I would like to have font database, knowing something about
relevant importance of different attributes.

Something like:
I choose font class (latin renaissance, latin modern, latin decorative,
arabic ???...)
>From class I choose family by name
Family gives my primary attribute split (usually antique?/italic)
Constraining goes on, until exact typeface is selected

I am not sure - maybe this is overkill for average users. On the other
hand - it implicitly suggest, how fonts are meant to be used by designer.
(for example - using bold + italic in roman text needs more steps by user,
than using either attribute. Removing italic from BI word removes bold
too.)

Lauris