Re: Device independent string output

[Owen Taylor <otaylor redhat com>]

My main concerns with such a system would be:

 - There is quite a bit of code in Pango that manipulates glyphstrings.
   The most specific examples would be the routines that map from
   screen position <=> character position.

   These routines needs positioned glyphs, not a description as you propose

   So, what you are proposing is adding another stage to the pipeline,
   in essence:

    text => positioning description => glyph string

   This will slow things down and complicate them. It may not be a major 
   slowdown, or a major complication especially if shapers can avoid having 
   to do metric lookups by relying on your "language", but it won't make
   things faster.

   (My concern about speed is all about initial speed and total throughput.
   Initial layout has to be fast, and making incremental changes fast
   at the expense of initial speed is not a good tradeoff in my book.)

 - Your language will lock Pango to a specific font technology. There
   is no way such a language could support both, say, OpenType and
   Quickdraw GX fonts. 

   Standardizing on OpenType (or font systems that can be emulated as
   subsets of OpenType) may not be a bad thing - it's about as
   complete as you would ever need, and seems to have the backing of
   the necessary people to get wide acceptance. 

 - The result does need to be a "glyph string" even if it is
   a highly annotated one. Hit testing, etc, require that the 
   mapping from glyphs to characters can be determined. Any language
   should be purely declarative. (I don't see anyfintention on 
   your part to do anything else, but I thought I would mention that
   need.)

I certainly wouldn't rule out such a method, though I'm a bit worried
about overhead and complexity. I'd probably have to see a bit more
details before forming a solid opinion on the matter.

Regards,
                                        Owen

Lauris Kaplinski <lauris@kaplinski.com> writes:

> Hello
> 
> I have thought about formatting device-independent output strings to be
> fed to gnome-print/gnome-canvas recently.
> 
> Problem: We have laid out text (possibly for certain printer), which we
> want to output with maximum possible quality on given device (other
> printer, print preview, editable canvas, etc.), at the same time keeping
> all relevant layout. So how should the (logic of) layout look like?

[...]

> I propose following solution:
> 
> Develop ultra-light glyph positioning language, capable of
> - specifying font, size and master resolution
> - specifying certain set of font subtypes, such as horisontal/versus
>   vertical metric sets
> - specifying currentpoint positioning both absolute and relative terms
> - extracting certain set of portable metric information from font
> - trivial set of standard operators
> Such language is encoded together with glyph and font pointers into
> glyphlist like structures, which are sent to output.
> 
> Little example - rendered string "A.T", using kerning, can look out
> something like (language syntax is arbitrary)
> 
> (Helvetica 12 300 300) setfont
> uselrdirection
> usehmetrics
> 100 100 moveto
> (A) show
> stdadvance_rmoveto
> currentpoint_push
> (A.) kerning_adjust
> (.) show
> stdadvance_rmoveto
> max_horizontal_position
> (T) show
> ...