===================================================== ``styled_text--benja``: Formatted text as a primitive ===================================================== :Author: Benja Fallenstein :Date: $Date: 2002/10/30 22:59:12 $ :Revision: $Revision: 1.1 $ :Status: Incomplete :Date-Created: 2002-10-30 In a modern computer system, *formatted* text should be the primitive we normally deal with. Unfortunately, all-to-often, users are only allowed to format *some* text, not all (for example, text in a text document may be formatted, but the title as entered in a dialog box can't be). Many spreadsheet programs only seem to allow formatting a whole cell, not individual characters in it. This is stupid: It should be possible to apply e.g. emphasis in all text you enter. This probably stems from the fact that the primitive in the underlying programming language is the "string:" a *non-formatted* list of characters. For the same reason, xanalogical text is practically unthinkable. In Gzz, let's make the primitive *formatted*, xanalogical text. Like it should be possible to link to and transclude all text, it should be possible to emphasize and color all text, for example. The main issue: Formatting links or not? ======================================== Tuomas has said he'd like to try out the way the Xanadu project planned to do formatted text: through links. For example, to emphasize some text, you'd make a link to it saying, "Emphasize this!" This is indeed an interesting idea (I suppose Tuomas has it from Ted's Literary Machines book). The two main runners for how to implement styled text seem to be: - the Xu one: using external links; - the boring one: storing the markup in the enfilade. The Xu way of doing this would, for example, allow us to say "This should be emphasized!" in one transclusion, and have the emphasis appear in another transclusion as well. However, there are two major problems with this exciting idea. The first I discovered was: What if you have the same characters in two different contexts? This can happen even in the same document: the same text can appear in a header and somewhere in the body, possibly in a reference to the header or something. It would be impossible to decide whether the characters should be linked as "header" or not. Also, if we quote some text from another document, it is common practice to add an own emphasis-- we wouldn't want our own emphasis to appear in the original document, nor would we necessarily want it to appear in *our* document when we give the original quote a second time. We might want to give the quote first, then analyze it, emphasizing different parts of it each time. The second major problem is versioning. Formatting properties must be versioned; it must be easy, for example, to emphasize a piece of a document, then go back to the old, non-emphasized version, then view the two side-by-side; it would be absolutely unexpected to have the emphasis appear in the older version, too. It is possible that we have different versions of the same text (different in the formatting applied to them, too) in two different cells on the screen, for example in Ted's real cut-and-paste system. If we store formatting properties as xu links, in order for the formatting to work as expected in these cases, we'd need to specify *which* format links should apply to each instance of a piece of text. We'd have to list, "this link applies, and this one, and this." That way, we could avoid that applying a format to one version automatically re-formats another version which was not intended to be re-formatted. (I suppose the Xu project did this by simply only respecting formatting links stored in the same document; this works because in Xu, links are in a document context. Updated versions of a document would have updated formatting links. This, too, has the effects explained in the next paragraph.) However, this means the whole concept loses the property I really like about it: I can *not* apply emphasis in one copy and automatically have it appear in another copy, where I'd need it, too. It doesn't work because the computer cannot decide which copies the format should be applied to, and which not. Now, this is a revealing similarity to the *order* of characters-- the vstream. In many cases, when I have two copies of the same text, and I change something in one copy-- insert a character, swap two words-- I would like this change to appear in the other copy, too. However, in other cases-- especially when comparing different versions/possibilities, I do *not* want the other version to change. (In zzstructure, if I do want both versions to change, I represent the transclusion using a clone, not the xanalogical mechanism.) This is exactly the same as with the formatting properties: the computer can't decide the problem, so even though it might be convenient if it could do it right, we don't make an attempt that could only do it wrongly. I think this is a good argument for taking the "boring" way, above: Implementing formatting in the enfilade. Conceptually, an enfilade object is simply a list of spans (or, if you prefer, characters); a "formatted enfilade object" will conceptually be a list of spans each of which has zero or more "styles" applied to it (or, if you prefer, a list of characters each of which has zero or more "styles"). A style will simply be defined by a URI (which means: a cell). It is up to outside mechanisms to determine what the style means. (The point is that styles should when possible be semantic, for example "emphasis" or "author's address" etc., so that they can be interpreted in different ways for presentation.) In a true enfilade representation, this will be really efficient to implement as a "DSPative property" in enfilade speak. Basically this means that at the highest possible node in the tree, you store the information, "All text inside this node has style X applied to it." In this scheme, it is equally cheap to apply a style to a single word, to a section or to the whole document (for the same reason that both small- and large-scale rearrangements are efficient; the order of spans in the enfilade is also a "DSPative property;" in fact, it's the name-giving "DSP" (disposition) property itself.) Open Issues =========== How to implement this...