On Mon, 8 Feb 1999, Jean-Marc Lasgouttes wrote:
> >>>>> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
>
> Allan> The third option which I'm still inclined to prefer (for its
> Allan> simplicity) is to have each Inset provide writer specific
> Allan> methods. Such a scheme wouldn't make it any harder for the
> Allan> writer to keep a check of the output (to break lines at
> Allan> appropriate points or insert extra spaces etc.). It would also
> Allan> be possible to use an ostream syntax for the writers. Let's
> Allan> call this Option3.
>
> I tend to agree that this is the somplest solutions. If we want to
> have all the output methods in the same place, we can always do what
> mathed does: all the Write methods of the different insets are in the
> same file.
I'd prefer not to.
> Allan> Other comments: I like the iostream appearance of my scheme
> Allan> with the overloaded operator<<. Unfortunately, I doubt we
> Allan> could modify Lars' scheme to use overloaded operator<< unless
> Allan> we changed it to being overloaded on inset types. I think my
> Allan> scheme needs something better than the WriterStyles enum to
> Allan> configure the Writer stream. Maybe something similar to the
> Allan> ostream manipulators (setw() and the like).
>
> I'd say that << is merely syntactic sugar. Do we really need that?
No, but it's meant to make you think along the lines of an equivalent
abstraction to ostreams since all except PainterWriter are likely to be
outputting via an ostream anyway.
I thought a bit more about the manipulator idea and there are a few
possibilities for taking common code and making specific functions that
can do fancy handling. For example, begin and end manipulators
overloaded on Writer subclasses such that a LaTeX begin would take an
environment name and its list of compulsory and optional arguments and
produce the appropriate output:
begin("list{}{}", "", "\\setlength{\\rightmargin}{\\leftmargin}");
item("", "#");
// contents of item may include other insets eg. maths or quotes
end("list{}{}");
would produce:
\begin{list}{}{\setlength(\rightmargin}{\leftmargin}}
\item[#] an artificially long line with some math in it
that wraps around \(\sqrt[2]{3}{w}\)
\end{list}
ideally if these calls were (virtual) members of Writer we could setup in
them the knowledge of how to safely break lines for pretty-printed LaTeX
output including where '%' are needed.
The equivalent for SGML/XML/HTML would end up like:
begin("ul") --> <ul>
item("li", "shape=square") <li shape=square>
end("ul") --> </ul>
Note that the "ul" or "list{}{}" comes from the layout file for each of
these types. ASCIIWriter's handling of these statements gets more
difficult because it should ideally know how the item()s are labelled.
Perhaps some "traits" would be handy. Font handling might best be handled
by a specific Writer(LyXFont const &) and so forth. However I think that
items are probably best handled within a specific inset, say InsetItems,
which has specific knowledge of the formatting of each of its components
(or maybe there should be only one item per InsetItem?).
A separate method for supporting commands would also be needed. This is
all very nice but when we start saying we also want a PainterWriter we run
into a few difficulties. Mostly with those commands we represent on
screen as a button not to mention tables or graphics. This leads me to
wondering whether a PainterWriter belongs in the Writer hierarchy?
If it does it needs specific handling whereas all the ASCII, LaTeX and
SGML Writers could use the begin(), end(), command() and so on overloaded
methods (perhaps separate table(), graphics() and button() methods for
specific pretty printing of LyXTable structures, and so on...).
Then again we could just define
void PainterWriter::begin(LString const &,
LString const & = LString(),
LString const & = LString(),
LString const & = LString(),
LString const & = LString(),
LString const & = LString(),
LString const & = LString())
{};
and so on. There are 6 defaulted parameters because there are typically
up to 6 parameters to any arbitrary environment or command -- a
vector<LString> could be used instead. Note that the order of filling in
the parameters is compulary first to optionals last. So something like:
LaTeXWriter lwr("outfile.tex");
lwr.command("@startsection{}{}{}{}{}{}", ...);
lwr.begin("list{}{}", ...);
lwr.command("something{}[][][]{}{}", ...);
I saw "something" last night in LaTeX Companion but I can't remember what
it was.
Anyway, while it would be nice to have specific functions for
pretty-printing these common things there are so many exceptions/special
cases (tables, graphics, math and anything that appears onscreen in a
button) that we're probably better off with taking a closer look at the
Inset hierarchy and ensuring that specific insets have their own specific
output routines. This should mostly involve transforming some of the
paragraph characteristics into specific insets -- this has already been
done for footnotes and tables which leaves us with ITEM_ENVIRONMENT,
ENVIRONMENT, COMMAND(?) and TITLE.
Allan. (ARRae)
