texmacs-dev
[Top][All Lists]
Advanced

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

Re: [Texmacs-dev] problems with TeXmacs versioning scheme


From: Nix N. Nix
Subject: Re: [Texmacs-dev] problems with TeXmacs versioning scheme
Date: 06 Apr 2003 13:22:03 -0600

On Sun, 2003-04-06 at 09:47, Leo wrote: 
[...]
> version. As a result, I recently learned that among my students
> TeXmacs got a reputation of a rather unstable system. Of course, I

Unstable O_o ?!  In what way ?  I use TeXmacs 1.0.1.8 and have not found
/any/ stability issues whatsoever.  Could you please be more specific ?

> explained the best I can that it is TeXmacs-1.0.1 which is stable and
> that TeXmacs-1.0.1.X is a developing branch leading towards 1.0.2.

That is true, however, many new features get added /and/ stabilized
between 1.0.n and 1.0.(n+1).  I'm still flabbergasted by the fact that
your students found TeXmacs-1.0.1.8 to be unstable.

> But to be honest, I tend to agree with my students that the versioning
> scheme chosen for TeXmacs is quite unconventional and may cause
> certain degree of misunderstanding and frustration.  For instance,
> within the current scheme there is no natural way to label debug
> releases for 1.0.1.

I agree that TeXmacs versioning is unusual, since, for instance,
differences between 1.0.1.n and 1.0.1.(n+1) can very often be
substantial, especially now that major efforts to restructure the Scheme
back end are under way.  However, I have not found this to have profound
effects on TeXmacs stability.

> Would it be possible to adopt a more conventional versioning scheme
> for TeXmacs development?? Linux kernel versioning scheme works just
> fine and will cause little misunderstanding, for many people are
> familiar with it.

Perhaps the main developers can better explain, and make decisions about
the TeXmacs versioning scheme than me.  I'm certain there is "method to
their madness".

> Any suggestions??
> 
> --Leo--
> 
[...]
> several faculty memebers. Major problem is TeXmacs insistence on using
> bitmap fonts even in Postscript output. As a result, PDF files
> generated from such PS files look quite ugly. In the scientific

I believe the fault with this lies in the 'ps2pdf' utility.  I tried
converting both TeXmacs-generated PostScript files and ones generated by
other programs, and ps2pdf makes them all look ugly.

Either way, output to PDF is currently being worked on.

In the meantime, you may want to export simpler documents to LaTeX and
then use pdflatex to convert them directly to PDF.  This produces
beautiful PDF.  Be advised, however, that the TeXmacs LaTeX converter is
not a major focus of the project, because TeXmacs does not strive to be
a LaTeX front end. Consequently, the LaTeX converter has several
limitations:

- Two column format is not passed on
- Margins are not passed on
- Table borders pertaining to single cells are not passed on (but 
  borders pertaining to entire rows or entire columns, as well as the 
  entire table are)
- Fonts such as Ralph Smith's Calligraphic Font are not passed on (but 
  there is a patch at

https://savannah.gnu.org/patch/?func=detailpatch&patch_id=1256&group_id=156

  which may get applied to future versions of TeXmacs that will convey
  these fonts to the LaTeX output.  This patch can be applied to a 
  binary installation of TeXmacs, because it only modifies the Scheme 
  macros TeXmacs uses, and not the TeXmacs source code itself)
- Structures such as title, author, etc. are passed on without 
  translation, causing the LaTeX compiler to not be able to interpret 
  them

In general, I have found this converter to be adequate, however, getting
flawless LaTeX does sometimes require touching up the LaTeX source
produced by TeXmacs.  This is not as difficult as one might expect
reading generated code to be, because TeXmacs does take care to make the
LaTeX source human-readable.  It does, however, require familiarity with
LaTeX.
[...]





reply via email to

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