Re: [Fresco-devel] Text styles/cloning graphics

Tobias Hunger wrote:

> Basically I want there to be a TextInput, a TextView and a TextBuffer with 
> some associated table of StyleItems.  I do not want to have a special 
> TextViewer for HTML, another one for a TextEditor, one for a Single-line text 
> edit filed, etc. I think that's not very economic and  -- more important -- 
> not very consistent.

I'm not sure I agree. And the 'not very economic' is certainly wrong, as
can be seen in our code. We have a simple text viewer demo that displays
text without doing any text processing such as line breaking.
Of course, you could argue that we may throw that away as soon as we
have a better viewer, but then, what *is* a text viewer ? What's it
supposed to do ? (and what not ?)

For example: a simple text viewer such as mine takes a (unicode) string
and displays it, possibly applying some layout strategy a la TeX.

But as soon as you want to embedd formatting (styling) markup into the
string, it gets slippery. What makes the difference between a style 
change and an embedded raster graphic ?

Or may be that's just the meat of this whole discussion: Is it right
to treat all such tokens equal ? Is it really useful to represent
styling decorators, glyphs, images, and figures by the same concept ?

If the answer is yes, then there is no such thing as a text viewer (or
only one without any markup support other than what is embedded into
unicode such as bidi). Every 'text viewer' would have to support 
something equivalent to a html browser.


>>>You see the problem: We need to duplicate the 'bold' decorator!
>>
>>right. But I think it's a bit early to jump to the conclusion that we
>>need a clone method. I don't yet fully understand the context in which
>>that could happen. Just 'clone' won't be enough, anyway. How do you
>>specify whether you want a shallow or a deep clone (or any specific
>>depth) ?
> 
> 
> It needs to be a deep copy, doesen't it? You cannot use a shallow copied 
> object in some place of the scenegraph and the 'original' in another, can 
> you?

sorry, I don't understand what you mean.


>>naively, which results in undefined behavior if the style precedence
>>isn't well defined.
> 
> 
> It is well defined: You specify the sequence of decoraters to apply together 
> with the range to apply it to. How can those be not well defined.

because of the decorator semantics: if I present you a scene graph
that is a color decorator holding a line of text, the line is displayed
in the color set by that decorator. If you wrap that into a new 'red'
decorator, the outer decorator must have precedence (i.e. should not
be overridden by the inner one) in order for you to see red text. That
in itself is already strange (and probably wrong). But worse: you don't 
know whether another color wrapper is wrapping *you*, in which case your
inserted style would have no effect at all (if those rules are to be 
applied).

>>But the real problem is that you don't have any
>>control over the 'style' nodes in the graph, i.e. you can't normalize
>>it, i.e. remove dead nodes (such as a 'blue' decorator wrapping a 'red'
>>decorator...).
> 
> 
> Yes... but you cannot do so all over Fresco right now. So why do you allways 
> bring this up wrt. text?

Because of the way style changes are used, and because of the (typical)
semantics of text style attributes such as color or size. If you insert
a margin, you'll see it. If you insert two margins, you'll see them 
both. But if you set a color, the 'real' color isn't cumulative.

> Of course you can specify a arbitrary long sequence 
> of red/blue decorators, as you can do apply to any graphic. A text is 
> somewhat more user-editable (and thus abusable) then the static graphics in 
> the demo, but a interactive graphic editor has exactly the same problems, 
> doesen't it?

indeed. The problem is far more general. But styling is just a context 
in which the problem materializes nicely.

As to line breaking: this is typically done dynamically, meaning that
it shouldn't imply any scene graph changes. From looking at the scene 
graph (and not making the actual layout) there is no way to figure out
where the lines break, so style decorators wouldn't need to care about
them either. It's a different matter if you want to apply two styles to
overlapping regions. For this we'd need some clever algorithms - using 
clones if styles are to be represented by decorators, and some other 
means else.

Stefan