Re: Displaying Formatted Text

[Lauris Kaplinski <lauris helixcode com>]

Hello!

On 05 Dec 2000 22:13:10 -0500, Jay Bloodworth wrote:
> Well, after looking through .h files I have a couple questions:
> 
> 1) Assuming I want to write a canvas item to display the text according to my
> needs.  At what level of the interface would I start?  It looks like
> glyphlists, postioned glyphlists, and RFonts are interrelated.  Can you give a
> conceptual overview of how these parts of the API fit together?
> 
> 2) RFont stands for raster font, but I notice that it includes some method for
> return ArtSVPs and the like.  Or those simply in service to the raster
> methods, or there to compliment them in a vector-centric world (like the aa
> canvas)?

For doing WYSIWYG display you have to think in 2 separate (coordinate)
systems:

1. Abstract output coordinates (We use standards PostScript 72dpi, y upwards
   coordinates in gnome-print)
2. Real raster coordinates (printers have different resolutions, you may
   want to display your graphic on screen with different zoom).

GnomeFont is font scaled for abstract coordinates (OK - actually it is
designed to be a little more - to be adapted for certain output device
- but that does not make difference in normal situation)
GnomeRFont is font (derived from GnomeFont) scaled for real raster
coordinates - i.e. the one, which you use for rendering.

Glyphlists and PGLs (Positioned Glyphlists) are font-specific layout objects
- similar to strings, but using font-specific glyph codes instead of
language-specific character codes.

GnomeGlyphList is bound to specific GnomeFont(s) - i.e. it describes
text layout in abstract coordinates. Because font metrics differ
slightly for different output resolutions (they are always in integer
pixels), inter-glyph distances are described using logical font units
(glyph widths) not absolute distances. Depending on requirements it is
also possible to assign certain absolute anchors into glyphlist - like
fixing all word starts in absolute coordinates, and let other glyphs
(of word) to flow optimally from starting glyph.
GnomePGL is bound to GnomeRFont(s) - describing layout in exact raster
coordinates. Glyph positions are fixed.

It will be good idea to implement text object, using GnomeFonts and
abstract coordinate system (GlyphLists are not designed to be editable
themselves, so you probably want to create your own editable text
representation).
So your text is always laid out to abstract coordinates - but you can
easily generate different views of the text for specific rasters.

Actually one part of the whole picture is missing - library, that
generates glyphlists from ordinary (unicode) text. That place is reserved
for Pango - and for that reason the glyphlist methods are called "dumb"
- i.e. they do not usable for anything other than simple left-to-right
scripts.

So ideally the picture is:
1. Unicode-text + GnomeFonts -> [Pango] -> Glyphlists (GnomeFonts)
2. GlyphLists + raster description (affine) -> GnomePGLs (GnomeRFonts)
GnomePGLs are directly renderable to raster

You can think about (1) as model part and (2) as view part of model-view-
controller application. WYSIWYG needs that model implements laid out
text (you do not want line-breaking differences between printed and
displayed text).

SVP is (somewhat) raster-bound version of vector path - its components are
sorted, so you can only translate - not rotate it - and you can render
SVP directly to bitmap RGB buffer using libart methods.
It is good ide to cache SVP-s instead of rasterized glyphs for very big
fonts, because SVP size grows much more slowly with growing zoom factor
- and the speed differences between rendering SVP or prerasterized bitmap
are also smaller for bigger SVP-s.

You can also look into GnomeCanvasHacktext source (it is private
gnome-print object) - it uses both GlyphLists and PGLs to render
text on canvas - but it is not editable.

PS.
All those things are somewhat experimental. I think, that the general
picture will remain the same, and hopefully the existing API too - but
there will probably be much more convenience stuff in future. So if you
have good ideas about it, I would be interested to know.

Best wishes,
Lauris