texmacs-dev
[Top][All Lists]
Advanced

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

Re: [Texmacs-dev] Re: Margins and export filters


From: Joris van der Hoeven
Subject: Re: [Texmacs-dev] Re: Margins and export filters
Date: Thu, 13 Mar 2003 11:16:27 +0100 (MET)

> Now, with TeXmacs and LaTeX, there is an added complication:  Not only
> do we have to make the document "look" very, very close, to keep the
> user happy, but we must also preserve it structurally as much as
> possible, to keep the user happy.

I claim that these two constraints cannot always be met together.
Clearly, *default* margins, contrary to *explicit* margins
are not part of the structure.

To convince you of this, consider the situation that you write
an article in article style. You convert it to LaTeX with
default margin and submit it to a journal. The journal changes
the article style to its own style and expects the margins to be
as specified by this style. Because of the extra layout commands
in the conversion, this will not be the case.

> Also, you have already made this compromise in the case of matching
> brackets:  You have added information the user hasn't explicitly
> specified in order to make the LaTeX document a more accurate replica of
> the TeXmacs document - well, in this case it was necessary for the
> correctness of the document, and not just a matter of philosophy, so
> it's a rather extreme example.

In this case, it is not a compromise: we *correct* the structure of
the document, rather than *adding* structure.

> Another idea (inspired by GIMP):  When exporting to a certain format,
> the GIMP always pops a dialog box with the various format features and,
> basically, what aspects of the document to save (given that the format
> supports them), and how to save it.  Now, I know your ideology is to
> have as few popups as possible, but this may be a time to ask the user
> whether she wants to export the margins and, I'm sure, other stuff that
> we could cram into such a dialog box.

This might be a better solution indeed. The user may explicitly request
the converter to conserve as much physical layout properties as possible.
Similarly, one may have an option to conserve more structure than usual;
for instance, export the multiplication as "\*" and not " ",
where \* is a macro which might be defined to be "\,".
The default options of the conversions should be modifiable
in the preferences.

> Background:  Some of these thoughts are not mine.  The people around me
> use TeXmacs and they want to write their papers in it.  They ask me,
> after having produced their LaTeX output, why it's not as seen on the
> screen, and I have to tell them that the converter is not yet perfected.

This is not the answer we provide in the FAQ list.
We have always clearly stated that TeXmacs is not a LaTeX frontend,
so the wysiwygness only holds when exporting to postscript (and later pdf).

> Consequently, I think the LaTeX converter should be taken to the point
> where LaTeX itself is the limiting factor in every situation.  This is
> not yet the case in every situation.  Until recently, table borders were
> handled really poorly by the converter.  Now, LaTeX is the limiting
> factor, in that it does not allow borders to be specified for each cell
> (AFAIK) - so, now "the ball is in LaTeX' court".  I think margins are a
> similar issue.  Another issue is 2-column format, which is very
> important for papers.  Formatting a chunk of text as 2 columns is not
> reflected in LaTeX.  Margins, IMHO, are another issue, as is
> "make-title", and the list goes on.  However, all these things can be
> mapped into LaTeX both visually /and/ structurally and, if not, well,
> "it's LaTeX' fault".

Yes, there is still a lot of work to be done...





reply via email to

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