[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Texmacs-dev] Re: Margins and export filters
|
From: |
david |
|
Subject: |
Re: [Texmacs-dev] Re: Margins and export filters |
|
Date: |
Thu, 13 Mar 2003 10:40:57 +0100 |
|
User-agent: |
Mutt/1.5.3i |
On Wed, Mar 12, 2003 at 08:50:19PM -0700, Nix N. Nix wrote:
>
> Keep the end user in mind during all this. As an end user, I tend to
> think of a converter as something that will /exactly/ reproduce what
> I see to a different format. I will, however, understand minor
> differences, due to non-overlapping feature sets of the various
> formats (e.g. PNG -> JPEG, i.e., lossy conversion). However, I /do/
> expect the two documents to be very, very close.
Yes. I think too that the default (and the current development
direction) should be:
A. try to translate the structure;
A-bis. if A is not possible, try to mimic the layout as a fallback;
B. try to mimic the layout as long as this does not conflict with A;
If one wants more strict a conversion, there is a need for (at least)
a specific document style so the markup used in TeXmacs better matches
the structures of the foreign format. But we do not have the manpower
for this kind of feature now.
> As far as margins are concerned, I'm afraid I must agree with David. A
> user expects a document to have margins, without explicitly having to
> specify them. The document was created in TeXmacs, therefore TeXmacs
> defaults will be reflected in it, whatever form it may take (LaTeX,
> HTML, Scheme, PS, PDF, whatever). If you take that together with the
> user attitude toward converters that I have described (perhaps
> improperly), you will find it inevitable to specify the margins
> immediately upon document creation.
I think you made a nice point: document exported by TeXmacs should try
to use the defaults of TeXmacs.
Additionally, that "TeXmacs defaults" part should be well identified
so it would be easy for a LaTeX user to remove it later.
> 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.
Yes.. that is a bit too extreme.
I can give another example taken from the old HTML export filter: the
default (still not overridable) is to export <body align=justify>.
That is a TeXmacs default, not a HTML default.
> I think we should assume that the end user knows nothing about LaTeX,
> except for
>
> % latex filename.tex
> % xdvi filename.dvi
Right, the default should fit the least user.
More advanced users (those thinking "I do not want that TeXmac cruft
in my exported LaTeX") are more likely to look for the way to turn off
the "use TeXmacs defaults" feature.
> 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.
Well... I do not believe that point is really settled now. The problem
is more that there is no easy way to define new dialog. The only
existing dialog (the file dialog) is written in C++. Eventually there
will be a way to design a dialog using Scheme, but that is not there
yet.
The specific issue of popups against other kind of user interaction is
more subtle than that. The problem is that in traditional application
software, popup are often misused. The usual exemple here is the
"Find" dialog occulting the occurence of the searched text.
But for setting export options, like "do structural cleanup" and "use
TeXmacs defaults", I think a popup dialog would be okay.
> 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.
That kind of user feedback is indeed interesting, but it is also
important to teach the users in what to expect and not to expect from
the tool they use.
TeXmacs is not a front-end to LaTeX, so we do not pretend to have
WYSIWYG LaTeX output.
Still there is a lot of things to improve: like graying out menu items
for thing wich cannot be exported to LaTeX when editing a .tex file,
doing document cleanup prior to export, supporting a "no visual
composition" (i.e. no empty lines or multiple spaces) editing mode,
etc.
> Consequently, I think the LaTeX converter should be taken to the point
> where LaTeX itself is the limiting factor in every situation.
I do not think the issue is as clear-cut as this.
> 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".
Do you know about \cline ?
> 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".
There are still some areas where TeXmacs is not really up to par with
LaTeX. Floats are broken, multicolumn text cannot have a separating
vertical rule, multipage table have no running head and foot, etc.
-- DDAA