Re: Device independent string output

[Lauris Kaplinski <lauris kaplinski com>]

On 22 Jun 2000, Owen Taylor wrote:

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

I do not think, Pango should rely solely on this intermediate. AFAIK
it (pango) is quite modular and there can be simply special rendering
engine, rendering to (and to certain extent from) such positioning
language. There is little need for such intermediate for Gdk/Gtk+ renderer
IMHO. At the same time, that can speed things up (depending on
context) for final display, as the language engine has not to be fired up,
if there is no user interactivity.

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

No. I am concerned with possible gnome-font library and respective pango
renderers and fonts only - so only these will be locked. There can well be
other renderers and font abstractions for other puropses, but I think some
standardization for WYSIWYG gnome apps would do good.
On the other hand - glyph strings eliminate ALL font information from
output - OpenType, GX and whatever. My proposal can keep some
information, but in extreme case it can well drop back to simple
positioned string.
If we allow little overhead, it is even quite possible to force additional
global position to every glyph, so if absolute maximum from modest display
is not needed, additional information may be excluded.

> 
>    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 agree. It is my main concern, that it has to be strictly
declarative and serialized.
Currently I think it should deal only with inter-glyph positions and
well-defined font metrics There are some interesting other applications
too - such as choosing display optimized expansion for Kashida glyph, but
I am afraid that would make it too complicated.

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

Currently experimenting with gnome-font, I hopefully can write down a kind
of testbed language + parser for canvas items.

Regards,
Lauris