On Thu, 2 Oct 2003, Angus Leeming wrote:
> Attached. The document describes the ideas behind the language and the
> rationale of the separation of Data from Transform. It does not (yet)
> describe how it all glues together. Instead I attach a small sample code
> illustrating how I think it should be done.
OK, thank you. A high-level summary:
LyX supports a fixed number of transformations, and a fixed number of
exporting formats for these. In the external material definition file, you
can define which transformations each template supports, and how to use
combine the exporters to produce the final output.
While this solves the problem, I feel that it is a strange mix of
hard-coding and not hard-coding.
The question is: Is the functionality of allowing the user to define
which exporters to use for each external material really useful? Of
course, it allows the advanced user to make it so that included
chess-boards can be rotated, resized and clipped. This is just grand, but
when the exporters are hard-coded, will he in fact be able to do that in
real life?
In other words, will it not be so that in practice, we will have to define
new exporters to allow this functionality to be used?
I'm not sure - it surely depends on how generally useful the exporters
are. Can they be reused for other templates?
In other words, will the ones you have now allow you to rotate, clip and
resize a chess-board?
If not, the options are
1) Keep the system as you propose - maybe the exporters are not so
reusable that we infact gain new functionality beyond extending the
graphics and xfig templates, but that in itself is great, and over time,
more exporters can be implemented, and we solve the problem that way. (It
is unlikely that a normal user will ever request a new exporter, because
they will not understand this.)
2) Extend the syntax to support defining exporters in the external
definition file. More general, but also much more complicated. Normal
users will not be able to use this, and it might scare them further away
from the external material insets all together.
3) Tie together the transform and export relation. In other words, only
keep the "transform X" lines. Then, each c++ transformer has a hardcoded
exporter, that knows how to extend the product of the template. I.e. rather
than introducing two concepts: Transformers and exporters for
transformers, instead collapse them into one concept "Transformers" by
doing the cartesian product.
So, we would have a RotateGraphicsStyle and RotateXFigStyle rather than
one Rotate and two exporters.
Implementation wise, these transformers would share the same dialog and
all that good stuff, but the user does not have to know about all this
export-business, substitutions of front-bits and back-bits. Instead, he
is told (this is from memory, so ignore syntax errors):
LyX supports a RotateGraphicsStyle transformer, which will change
\includegraphics{yadayada} into \includegraphics[rotation]{yadayada}
if you have produce \includegraphics{$$Filename} in your external template
file. It also does the right thing for other formats.
Also, LyX supports a RotateXFigStyle transformer, which will change
\foo{yadayada} into \bar[rotation]{\foo{yadayada}} if you have produce
\foo{yadayada} in your external material template file. It also does the
right thing for other formats.
That to me seems a lot simpler for the user, and it will probably also
simplify your C++ code.
Comments?
Best regards,
Asger
