tmprint and rendering Latex

  • Thomas Sturm
    Thomas Sturm

    I have noticed (on the Mac) that the Fox-based CSL-REDUCE GUI uses tmprint for its "on fancy" mode.

    I have got a few questions and remarks about this:

    1. Questions:

    * Is tmprint generally used on all platforms, in particular on Windows?

    * Redlog contains code like

    if rl_texmacsp() then
       put('impl,'fancy!-infix!-symbol,"\longrightarrow ")

    The else case once was relevant for the PSL Windows frontend. I would be interested if this still exists in that form.

    * What is the status of rprint/fmprint (from which tmprint had been derived). Who uses this, and for what?

    2. Remarks:

    * tmprint was designed for texmacs (hence the name). Above you see the procedure rl_texmacsp. It concludes from the fact that tmprint is loaded that there is a texmacs session running. Other software might do similar things as well, and on that basis they might decide to do things that are not compatible with the Fox-GUI. I have checked Redlog; there is no problem at present.

    * There are, however, some redering problems: If you go (in the Fox-GUI)

    load_package redlog;
    rlset reals;
    a=0 and b>0;

    you will find that the "=" is nicely spaced but all other operators are not; at least I find that. I have got the impression that there is some special treatment in redering for "=", "+", ... while other operators are simply typeset as characters. This is not the approach of Tex, which uses for that purpose \mathord, \mathop, \mathbin, \mathrel, ... I could work around that by going

    put('impl,'fancy!-infix!-symbol,"\,\longrightarrow\, ")

    but then I get problems in Texmacs, which would properly space \longrightarrow by itself and now put some extra space. In fact, it is one of the differences between tmprint and rprint/fmprint that rprint/fmprint automatically puts "\," when an infix operator is flagged 'spaced.


    I think it would be a good (intermediate) solution if we moved definitions like:

    put('not,'fancy!-infix!-symbol,"\neg ");
    put('leq,'fancy!-infix!-symbol,"\leq ");

    from tmprint somewhere else maintaining 2 (or 3?) versions of that "somewhere else" for Fox, Texmacs (and PSL Windows?). In these extra files we could also add a mechanism for determining at runtime which interface is actually used.


    I hope to get a discussion going here. There are actually more interesting questions in this area: Besides the tmprint and rprint/fmprint there is as well tri (the Tex REDUCE interface) and I think even another package for Tex output in REDUCE. Sounds like this could all be unified somehow?


    • Arthur Norman
      Arthur Norman

      I am REALLY far from certain that moving all the "put" statements relating to fancy printing to one place is a good idea and I am quite certain that I dislike the idea of having one version for use with texmacs and a different one for use with the CSL front-end, so I would not view major changes to many files done over the coming weekend something I would appreciate. In particular I feel that I want to hear from the authors of packages other than redlog before rushing to this, and I want some time when I feel less under pressure so that the fmprint/PSL side can be integrated into this discussion.

      I think that those who are very fussy about layout can use texmacs for now and ignore the CSL front-end if the issue is merely aesthetics. I still hope that somebody with time and energy and who is sensitive wrt typesetting will join in one day.

      Wrt re-use of code from texmacs, firstly I would not expect to find their render engine compact and easy to remove and re-used. As best I am aware texmacs is GPL which means that its license is too restritive for use in a BSD project. And I continue to believe that if the only problem is in effect inserting some extra space that altering my code so that ordinaryily fussy people could be supported shound not be too hard - but I also believe that those who are REALLY critical will want to export stuff as reguilar tex files  for processing by the real system.

      I too have other duties besides Reduce and a raft of other support objectives of my own as well as this one. My time may start to become more flexible in a couple of weeks, but please do not make widescale changes until enough other developers like it, or if you feel you really want to use subversion to make a private copy in branches rather than trunk to explore the global rather than merely local changes.


    • Thomas Sturm
      Thomas Sturm

      OK, let us wait. After all, the procedure of extracting things and gathering at one place is highly irreversible.

      Please let me make a few more remarks:

      1. At some point we will have to make major changes to the sources in general. Otherwise I cannot see how there could be any progress or improvement.

      Consider as one example the starting point for this thread: rprint/fmprint is mostly a copy of tmprint without necessary bugfixes, possibly not used by anybody. And furthermore, I think, particularly fmprint is even included into the core system(?)

      I think we have to arrive at a stage, where there is a developer's community with several additional new people who have got an idea of the overall system. We should tidy up before inviting our guests!

      2. It is hard for me to understand your worries about two alternative submodules for tmprint, which would exclusively contain some put('fancy!-...) calls while you are more relaxed than I am about the several printing modules already in the system, of which I cannot even precisely figure out where they are used and if they are used at all.

      3. As for the layout: I am myself using redfront anyway, so I am not really affected by the layout. I am just quite afraid that possible new users (and we need new users - young users!) will judge the book by its cover.