On Tue, 23 Mar 1999, Asger Alstrup Nielsen wrote:
> > I'd like to see a solution that doesn't require the Writers to maintain a
> > running tally of which fonts are open and what order they were generated
> > in.
>
> I think I need to argue once more why having the font attributes for every
> single character in the document will not cause problems for the writers. Or
> in other words, why having special InsetFonts or a hierarchy of font changes is
> a bad idea.
Okay, these arguements make sense and I'll forget about InsetFonts now...
One small clarification though: is LyXFont then a member of the
InsetParbox (from "An inset is..." thread) or of the InsetText or both?
In the InsetParbox case it would probably be in the ParaParams if
anywhere. It would seem to me that both cases would be needed.
[...]
> Now, what remains to argue is that having the font attributes locally will not
> make life difficult for the Writers. All we need is a font writing module:
>
> class LaTeXFontWriter {
> public:
> LaTeXFontWriter(ostream str, LyXFont const & def_font) :
> stream(str), default_font(def_font), running_font(def_font)
> { }
>
> ~LaTeXFontWriter() {
> use_font(default_font);
> }
>
> void use_font(LyXFont const & font) {
> if (font == running_font) {
> return;
> }
> // Here, we have logic to determine
> // which font attributes to close and
> // open to get the requested font
> ...
> stream << "<bold>";
> ...
> stream << "<\bold\";
> }
> private:
> ostream stream;
> LyXFont default_font;
> LyXFont running_font;
> map<LyXFontAttribute, bool> open_attributes;
> }
>
> Now, the use_font method can use any appropriate algorithm to determine how to
> implement a given font change sequence.
> Obviously, it can only use the information about the previously seen font
> changes as it is defined here (i.e. only font history, not font future).
> I'm not sure whether this is enough to ensure optimal font changes or not, but
> if it turns out that we need more information, it's simply a question about
> changing the interface to use iterators instead.
It would seem that a stack is needed in this situation. I'm not sure why
you have a map of LyXFontAttributes here except to speed up the lookup of
which attributes are currently in use. But that then tells you nothing
about what you have to do to either close that attribute or set it if its
not already enabled. Searching a stack of attributes tells you if its
there or not and how many other environments you need to close on the way.
I suppose if you were clever (which of course you are -- too clever by
half ;-) you could implement a stack using a map and get both rapid
searching and simple iteration to close attributes.
Just so long as its simpler than the current scheme. At least this is
separating out the font handling.
Allan. (ARRae)
P.S. I think this scheme would also work with InsetFonts but that would
only be successful for forward iteration (like file output) as opposed to
random access by the user on a gui frontend. Oops, I said I'd forget
about InsetFonts didn't I :-)
