mailing-list for TeXmacs Users

[M Singh <address@hidden>]

On Tuesday 19 October 2004 17:01, Joris van der Hoeven wrote:

> >     This is why I had submitted native support of latex class files (or at
> > least a well supported tool to translate those class files into a form
> > that texmacs uses) as an urgent wishlist feature many months ago. I was
> > told then that it would be next to impossible to implement.
>
> It is impossible to natively support LaTeX class files, although we have

Fine.

> started to port the most frequently used ones (Springer, Elsevier, AMS,

This is a cumbersome process, as it would have to be done for each class file 
that is used. Since there are thousands of them out there (if not hundreds of 
thousands - just check ctan.tug.org), this process will inevitably have 
problems when new versions of class files come out. Versioning could easily 
become a nightmare.

> IEEE, etc.). However, you cannot assume C++ to compile Fortran programs...

Setting aside the observation that f2003 is supposed to include C interop 
directly, I would like to pose a few questions.

Is a texmacs class file pure text ? If so, as I suspect it is, what is the 
exact problem in writing a program that parses a latex class file and o/p's a 
texmacs class file ? Like \topmargin etc. could be mapped into some texmacs 
equivalent, or emph, bold face, \vspace, etc. could be similarly mapped.
 

>
> >      Unless a large number of people suddenly start using texmacs and
> > pressure various journal offices to start supplying texmacs templates (or
> > whatever they are called), the chances of new developments at editors
> > desks are remote. As it stands, that best bet for a texmacs user is to
> > hope that the conference / journal accepts PDF as a valid format (most
> > journals do not) and generate PDF from texmacs.
>
> Yes, that is what I suggested in my previous email. Even if the TeXmacs
> format is not accepted, it should be possible to send high quality Pdf
> files, as TeXmacs can generate very well now. We can make an additional
> effort to implement a few basic types of styles and give ways to customize
> them. With that it should become rather straightforward to obtain a result
> which matches the layout policy of specific journals. This definely does
> not require a lot of work from the editors; why not try!?

You do not understand an editor's point of view there. They (especially in 
case of larger journals) do not have the resources or the time (or even the 
inclination - for fear of messing up their manuscript processing systems) to 
deal with typesetting systems for which there is little / no well tested 
markup environment, and the number of people who are insistent enough (and 
few prospective authors are - they are trying to get published first, not 
teach the editors new things) and simply refuse to use Word / LaTeX, is 
miniscule.

texmacs is the new kid on the block. The basic idea is sound, but there are a 
few gaping holes which will ultimately make professional users balk at using 
it when their latex skills would help them get published instead. I think 
that texmacs has a few things right, and it can possibly go two ways from 
here :

1. Ease of use gradually draws in users, many of whom leave because 
professional publishing houses / journals etc. do not accept the .tm format. 
This would probably lead to texmacs becoming another groff or lout or even an 
elaborate abiword of sorts. Not a good prospect for an application otherwise 
so well thought out.

2. Development of two things - a good importing system that reads in .cls 
and .sty files and o/p's texmacs style files , and as the OP wanted, a 
sensible, non macro based latex export system. This could really light the 
fire under texmacs. Many people would still prefer to use LaTeX directly, but 
the new users would naturally gravitate towards texmacs.

Of course you might say that it is not your job to make sure that texmacs 
becomes widely used or even the de facto standard. However, from an open 
source viewpoint, the larger the user base you have, the larger the number of 
possible bugs discovered, and nicer the final product.