texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Texmacs-dev] More information to export filters (was: Multiple column


From: david
Subject: [Texmacs-dev] More information to export filters (was: Multiple column support)
Date: Wed, 23 Apr 2003 14:48:15 +0200
User-agent: Mutt/1.5.3i

First of all, I want to make clear that I am not *arguing*. I am just
asking for clarifications so we can better understand each other idea
of how things should evolve.


On Wed, Apr 23, 2003 at 12:51:53PM +0200, Joris van der Hoeven wrote:
> > I think that is another case where it would be useful to have an
> > actual texmacs typesetter (maybe just passed as the "current buffer")
> > used as input to export filters.
> >
> > This would make it possible to ask texmacs the displayed width of an image.
> >
> > What is the opinion of the Benevolent Dictator on that issue? I am
> > just wasting my (digital) breath, is such a change planned, or would
> > it be accepted if submitted?
> 
> I think that we might ask the current typesetter to create
> auxiliary data which may be reused during conversions.
>
> This is indeed a bit dirty;

If I understand well, you think that _before running the converter_
the typesetter should produce auxilliary data which would be passed to
the converter as decoration to the stm tree. Either in the form of
companion trees (e.g. under a root !file node) or in the form of SXML
auxilliary nodes.

I think that would introduce a dangerous coupling because the
pre-converter which introduce this auxilliary data would have to know
about every kind of auxilliary data which may be needed by the
converter. So extending one converter to use more aux data would
require adding specific code to the pre-converter.

Also, it might become expensive if a lot of such auxilliary data is
added.

In the approach I propose, when a converter needs some kind of
auxilliary data, we just add an (generic, reusable) observer to the
server glue. So things stay clean, decoupled and generic.


> a clean solution would be to use rewriters with multiple branches,
> which may simultaneously produce a TeXmacs box *and* the converted
> document.
>
> But this is too far away, so let us forget about that that for now.

I think that using rewriters as export filters is abusing them.

Rewriters are meant to allow editing of foreign structures. Only
foreign->tm rewriters would need to be designed; and since rewriters
are going to be complicated and expensive (both in programmer time and
computer resources) that is a good thing that they stay limited to
this.

If one uses rewriters for exporting, we get something like:

   edited texmacs
   +--> boxes
   `--> converted html
        `--> displayed texmacs
             `--> boxes

Why not simply use this?

   edited html
   `--> displayed texmacs
        `--> boxes

--
                                                            -- DDAA




reply via email to

[Prev in Thread] Current Thread [Next in Thread]