[Texmacs-dev] Re: Margins and export filters

[david]

On Wed, Mar 12, 2003 at 08:36:13AM -0700, Nix N. Nix wrote:
> On Wed, 2003-03-12 at 03:12, Joris van der Hoeven wrote:
> 
> [...]
>
> >   The problem here is that I have not decided yet how to handle
> >   the additional data for a document. Maybe we should send just
> >   one tree with all additional data in it, in a similar way as we
> >   do when saving files. Also, you should be careful *not* to
> >   export the default values of style parameters to LaTeX, because
> >   these defaults are not part of the structure.
> 
> That's a good idea - I'm thinking, if we sent the same tree we send
> to the TeXmacs -> Scheme converter to /all/ the converters, then all
> the converters would have all the information. We would then have to
> modify the converters to throw away most of that information (we
> won't be able to implement handling all the new information at the
> same time), and then, gradually, pick more and more of the tasty
> morsels out of the new, richer tree - yes, it's a dumb metaphor, but
> it's the picture that comes to mind :o) That would be cool, since we
> could use make_document () to create that tree, as it's done for
> Scheme.

That would indeed make sense, but...


> The only problem would be exporting selections, which do not include
> the "initial" subtree, IIRC. I suppose we /could/ pass an empty
> "initial" subtree, as well as empty ones for all the other trees
> (like "style"), and modify tmtex et. al. to handle that case.

Selections are a different matter. That extra information you want for
converting document is of no use when converting a selection.

The way I think of it is:

  -- document conversion works on a full document (including, maybe
     metadata) and produce a full document: with a preamble if it is
     LaTeX, as an HTML element node if it is html, etc.

  -- selection conversion works on a document fragment (that is,
     exactly the selected data) and produce a document fragment: a
     list of LaTeX commands or HTML elements, etc.


> Don't default style parameter values /become/ part of the structure
> as soon as the buffer comes into existence ? After all, if I open up
> TeXmacs and just start typing my, say, letter, then print it, won't
> I get default margins and a default document structure ?

I agree. And I think the best way to get out of the dilemma is to pass
the converter a typesetter loaded with the document to convert. Then
you can get whatever metadata you want.

Before the buffer/view/window architecture is reorganized that would
simply mean to set the current buffer to the document to be exported.

In addition, that will be required to allow document fragment
evaluation: evaluation of an abitrary tree in the environment of a
given point in the document. That is a planned future feature which
will allow "better than nothing" conversion of constructs which are
not explicitely supported by a converter.


> My interest is to make the LaTeX generated by TeXmacs have the
> /exact/ same layout and structure as the TeXmacs document itself.
> Furthermore, I would like the "look" of the document to be the same
> as well (hopefully, because the LaTeX structure mirrors the TeXmacs
> structure faithfully). IOW, the product of, say, "Preview with
> ghostview" should "look" the same as if I had opened TeXmacs, typed
> something, then performed Export -> LaTeX, followed by
> 
> pdflatex filename.tex && xpdf filename.pdf
> 
> It should "look" the same, because there are instructions in the LaTeX
> source covering the exact same document parameters as the TeXmacs
> source.

I do not believe it is really possible to achieve that, and if it is
possible I am not sure it is worth the trouble.

The problem, as usual, is that LaTeX is a document composition system,
not a graphic language. That means LaTeX has many degrees of freedom
to typeset the document as it pleases. That is by design.

Also, another problem is that TeXmacs and LaTeX have different feature
sets. You can _approximate_ one by another, but it would be very
difficult to _emulate_ one by anoter. For example, TeXmacs does line
shoving, has a better page breaking algorithm than TeX and allows
"visual composition" (with spaces and empty lines).

LaTeX export must stay "structural". During the design of the new
tmhtml export filter, I though of a number of subsets of the possible
texmacs document with various constraints.

The old draft (probably very out sync with what I currently think, but
I have no time to revise it now) is attached.

Roughly, there is a Structural subset which excludes all fancy
typesetting features useful to design stylesheets, and a Valid subset
which sets structural constraints on the document.

Most converters should be designed to work with the Structural data
model, because what we want to convey is the *meaning* of a document.
Of course, one may want to add some support for non-structural
features, but perfect emulation is not the aim of TeXmacs (at least,
not mine).

One exceptions would be the PDF converter, but it may be more
appropriately referred as the PDF printer, because it will rely on the
typesetter to place the boxes.

                                                            -- DDAA