On Tue, 23 Mar 1999, Allan Rae wrote:
> > Who said an inset can't do it? In fact the workarea inset would fit your
> > description. It would be given a box of the View's size where it would
> > drop its contents. Its contents are of course paragraphs.
>
> I got the impression from your first email that you were saying that all
> insets were restricted to their rectangular box and making a paragraph
> inset would mean we couldn't flow its text.
The inset's role is to manage the geometry, it doesn't matter if it's
fixed or flexible in some direction. The paragraph holds the data.
> We've been discussing making everything an Inset so the term "inset" has
> changed its meaning slightly. I wouldn't describe a table or a figure as
> a glyph but they are both Inset types now. There is already the InsetText
> and InsetFootnote and so on that aren't really glyphs either. So "inset"
> has moved beyond just quotation marks and unusual characters. Then again
> maybe I have a different idea of what a "glyph" is. :-)
both footnote and insettext *are* glyphs. I'm using the definition used by
Erich Gamma in his example of the document processor (see reference in the
devs site), that is similar to Knuth's defition of box in TeX.
> Except a font change isn't a glyph but it still needs to be an Inset.
> The table of fonts and positions in the existing code seems to me to be
> more restrictive than having InsetFonts.
yes and no. The current code is restrictive but you really don't need to
have all the font info in an inset to, par example, emphazise a phrase. I
like more the logical style approach. having the font info either in a, so
miscalled, inset or in a table are almost the same thing. I would prefer
that inside the paragraph data we can allow logical style codes
corresponding to <emph> or <strong> or whatever. Then our font manager
would be enough smart to know at low level which font to use.
> > No, as you told before, several paragraphs can have the same layout. IMO
> > the text inset would be the base for all insets that can have editable
> > text. It should be able to hold several paragraphs inside, as a list of
> > data containers.
>
> But InsetText as in the code is something different although it could be
> expanded to meet your description.
yes, of course. We all agree in that current code must be redesigned.
> As I stated above "insets ain't insets." InsetFont was mentioned early
> last week (or the week before) as a holder of font info that would affect
> everything that came between it and the next InsetFont. This could
> therefore apply across multiple paragraphs or across individual letters.
> Each InsetFont would therefore contain only the changes from the current
> running font.
Well, I said already my opinion about this point (logical style codes
instead of low level font info) and insist in that the word is being
misused, but if there's no better option for you I can live with this, by
now.
> Without an InsetFont we end up with the same sort of font table stuff we
> have now except if we don't change a font we still have a table and its
> extra baggage. Putting each element into its own self-contained Inset
> will lead to easier maintenance and more clearly defined interfaces.
> Of course, it's arguable that we might be breaking things up to far then
> but our existing code has to have a very smart Paragraph instead of
> several smaller not-so-smart fragments.
I'd go further, not only drop out the font table but also the font inset!
;)
It's time to do things better. If the internal document structure is in
some way reflecting latex structure, it's not smart going at lower level
than latex.
Alejandro
