On Tue, 23 Mar 1999, Alejandro Aguilar Sierra wrote:
> On Tue, 23 Mar 1999, Asger Alstrup Nielsen wrote:
[...words, words and more words...]>
> Currently in 1.1 the text inset (InsetText) is the base class for all
> insets that have inside editable text and that can be adapted to a
> given box. I'd like to keep this terminology (not the model): the
> most basic text inset to be the InsetText and use other names for
> more complex text insets.
[...Paragraph doesn't need to be an Inset...]
> > Besides the InsetFlow and the Paragraph, we have the ordinary glyph
> > Insets: References, label, math insets, and others. Take the footnote
> > inset. This is an inset that contains a FlowInset. Next to these
> > "ordinary" insets, we also have the InsetText. This insets contains the
> > text of the document, in the form of an LString. It also contains a
> > pointer to a CharParams structure, that is similar to the
> > ParagraphParams structure, and contains the information about the text
> > in the inset. This includes Font, Logical Font, language and other
> > character level information.
>
> So you suggest the InsetText to be a very basic text inset without no
> information about font changes nor other insets allowed in its
> contents. Some sort of atomic text inset with an LString as basic
> container. And are the other text inset derived from this one or are
> they independent?
>
> At first sight I see this model impractical and unnecessarily
> complex. Imagine you have a very large phrase without font changes
> that have to be broken in several lines to fit on the screen.
> Immediately becomes impractical to have it all inside a rectangular
> inset. I guess your answer would be: let's break it in three insets,
> as your example of the three boxes for a footnote inset. Or better,
> never allow a basic text inset to have more than one line. If it goes
> beyond the box boundaries, break it!
I really don't understand how you come to the conclusion that a really
long string containing up to an entire paragraph would have to be broken
up into lots of line sized insets under Asger's model.
Anyway, I'll again suggest a mix-in class for flow handling. See my
other email in "An Inset is..." for a bit more info.
> > Notice that this implies that we will have no more Inset-codes, no more
> > font tables, and no more inset tables.
>
> We all agree in that it's necessary to get ride of that stuff, what
> is not clear is how to do it. Your model doesn't automatically
> eliminates the need of the inset codes. You have to check how and
If the InsetParbox asks the Insets in its container how much space they
need given a particular screen width then it would effectively oversee the
flow of each inset and where necessary allow certain insets a bit more
space on a line. Asger described this a stretching of the insets glue.
The InsetParbox is thus more of a flow manager overseeing the flow of
different insets and making the decisions where necessary of which inset
should be stretched. There are no inset codes involved in this as far as
I can see since they would all have the same sizing methods in their
interface (and different implementations as appropriate).
> where are they used. It does with font and inset tables, but still is
> not IMO a very ellegant solution (the low levet font info
> structures).
>
> I'll discuss this later (see below).
>
> > This design is the result I have come to from the discussions we have
> > had so far. There are more details about this in my head, and this is
> > what I'll try to write down in a proposal kernel document when I get the
> > time. However, if you feel that this overall approach is flawed, please
> > tell me.
>
> At least it is not complete. How are InsetText and InsetFlow related in
> your model and can an insetflow be contained inside an insettext (I guess
> the insets that are contained in a paragraph are insettexts).
>
> IMO a simpler solution would be much better:
>
> 1- A paragraph would have only the ParagraphParams and a container with
> the text data. It would not be an inset.
>
> 2- A text insets would contain paragraphs and would manage the
> geometry: that is, to break paragraphs in lines on the screen (or
> in a box) making it to "flow". Maybe a very basic inset would not
> allow more than one line (and of course no more that one
> paragraph.) This kind of basic text inset would be used as "text"
> mode inside a math inset.
>
> In the most basic cases we could have only a text inset, the
> workarea inset. In case of having other text insets (footnotes or
> whatever) they would use the same mechanism to edit and draw that
> the work area in a recursive way.
>
> The current InsetText (the real one in 1.1) is repeating several
> things already used to manage normal text on screen. This kind of
> redundance is not good because editing is rather a very complex task.
>
> The solution is to adopt a recursive way. Please give me some
> credit, this is the way the nested math insets are designed! An equation
> on the screen is as inset as the most deeper sqrt inset inside it. I
> don't see why this model can't be applied to the more general text case.
Recursion such as this requires nesting of Insets inside each other does
it not? If so, we've already decided against this and want to continue to
use a flat document structure. The only nesting the flat structure would
effectively allow is an InsetParbox inside another InsetParbox and this
would cover the footnote in a paragraph case (assuming everyone agreed
with me that a footnote is really a special instance of an InsetParbox,
just like marginpars and minipages, rather than being derivatives of it).
But then you seem to me to be describing scheme almost identical to the
InsetParbox scheme except you don't actually have a Parbox to hold all the
insets in the paragraph. Confused? You appear to be happy to leave each
inset manage its own flow without an overseer (at least not in the form of
an InsetParbox). This still leaves some of the difficulties we have now
with getting the end of paragraph markers correct (although only in those
paragraphs that aren't solely made up of text. Maybe i'm the one that's
confused in which case you just described the InsetParbox scheme.
> 3- About the font info stuff. In LyX the font of each paragraph is
> defined by its layout in a paragraph basis and there are font info
> structures that changes locally this info. IMO we don't need to
> have a font info for each... (let me call it) phrase. We have already
> the font info corresponding to the layout of the paragraph. Local
> changes can be setted by simple high level logical style codes.
> This can be done with a smarter font class. And we ellimintate
> both font tables and font info structures inside a paragraph.
I got the impression this is what Asger described also, or at least
appeared in discussion around that time.
> 4- With all this in mind, the remaining structure to discuss is the
> "atom" container (which btw has never been an LString and it
> doesn't have to be it). Imagine it as a vector<inset*>. Even a single
> character would be an inset. How to save from the memory bloating?
> See the Flyweight pattern (pag. 195, Design Patterns, Gamma et al
> 1994, complete reference in the devs homepage).
If it's an LString or something simple without extra ornaments or coded
markers we can read it or write it in one go only stopping for line
breaks. Whatever it is it shouldn't require character by character
processing except for encoding translations.
> Other solution would be vector<wchar>. Some values beyond the
> boundary of useful values for char codes would be special codes
> like style codes and inset indices from a global inset container
> (gic). From the vector<wchar> we could get an inset index and
> we would get the real inset* from the gic. Yes it is something
> like the old inset table but it is not carried inside each
> paragraph, it is global like a memory manager.
But then we have to do extra processing to figure out if a character is
really a character or an inset. Just like we do now with the META_ codes.
That's something we're [I'm] trying to get rid of.
> In both approaches we would take full advantage of STL iterators
> and basic operations like copy, cut, paste, search, replace, etc
> would be made almost as easy as applying directly STL algorithms!
We're all after that goal.
> However this solution is not yet perfect. Your turn! :)
We're getting there. Just another day or two...
Allan. (ARRae)
