Re: beginner's questions

[Hans Hagen <pragma@wxs.nl>]

At 07:56 PM 11/12/00 +0100, Denis B. Roegel wrote:

>only the knowledge found in the metafun manual), but the main thing
>that annoyed me was the sometimes lack of clear diagnostic
>in case of errors (either in my installation or in what I typed,

Diagnostics are very hard to implement in a macro language like tex,
especially since error recovery is nearly impossible. However, when someone
finds a place where a status message can help, please let me know and I'll
add it. 

There are a few low level tracing options, but so far they have not yet be
documented. Tracing of key/value handling is very time and memory demanding
but can make it into future versions. 

>see the series of messages I sent recently). This of course is
>made more difficult by the fact that context is evolving,
>since one can make a mistake when updating his/her installation.

I must admit that bringing new features into the open is quite dangerous.
Although the basics of metapost inclusion are there for some time now, the
new features are new indeed, and therefore kind of beta. This is
complicated by the fact that support for mp in tex distributions is nearly
nil, so there texexec cum suis have to handle it all.  

>But I am confident many or all of these problems will vanish
>eventually.

With the help/input of users they will eventually vanish. Keep in mind that
it is not always easy to foresee what users do on their systems, and
although texmf tree's are more and more standardized, differences remain.
Fonts for instance will always be kind of messy.    

>It must also be said that the quality of context is quite
>stunning, given that it is used by a very small number of (free) people.
>But there may be many people who use it through pragma, and I guess
>they helped shape context into what it has become. And the fact
>that people are paid for it has certainly something to do with it.

A bit of history: 

- Pragma is currently two people; we hire hands when needed, and have an
association with an it-company.

- We originate in educational technology, and we may safely assume that
people working for us have no computer skils as demanded by tex. 

- When we started using tex, we looked into latex first [actually, we
bought it from aw] and since we wanted dutch labels and so we ended up in
kind of messy and not-understood patches. So we started writing a small
wrapper [not even knowning what macros actually were]

- Before we made the definitive decission, we looked into professional
publishing systems, but finally decided to go on with tex. 

- Since we had to pay for updates and even hyphenation patterns [indeed, we
were not on any internet] we looked into other tex macro packages, like
amstex, lamstex an inrstex. I think that we spend some thousands of
guilders on bying licences and manuals. 

- Lamstex looked very promissing, and I never understood why this more
configurable latex alternative never made it [i must have a few manuals
somewhere]. We used it a couple of month, after which we switched to
inrstex. This latter package had pretty good defaults, and was quite
configurable. Some of the context defaults stem from inrstex. 

- When writing educational material [which in many aspects can have quite
complicated typo] we wanted to have more control over structure and
automate as much as possible. 

- The basic idea is: no manual intervention, so 'no user supplied vskips'
and 'no manual page breaks'. A lot of effort went into spacing, and we're
still improving that bit. Another idea is abstraction, which is why right
from the start there were mechanisms for abbreviations and block reuse.

- This means that for using context to the full extend, you have to start
from scratch. Think of what you need [which will happen when you key in the
same thing for the tenth time] and look if there is an easy way. This is
how context evolved: people coming to me and asking for simple less time
consuming methods. The first users were those who never \def'ed a macro,
didn't know anything about fonts etc.  

- When context went public, and when this list was started, people started
asking for features. Given that we need context for rather complicated
documents, you may assume that there are more features than currently
covered in the manual. Many of them are still in development, so I can
choose: either say 'it can't be done' or just reveal the details. I've
chosen for the latter at teh cost of complaints about lack of documentation.  

- There is only a limited amount of functionality that can be hard coded.
This is why there are hooks. There are for instance some 10 table of
content configs, but one can implement his/her own. Experienced tex users
will do so, but at the same time will have the automatisms available deep
down. [Believe me, there are gory details no sound person wants to know, i
may describe them in more fundamental discussions about functionality.]  

- The multi lingual user interface is there for a good reason: non
technical users. We want to be be able to assign tasks with regards to
entering tex documents [and even changing layout specs] to virtually
everyone, but especially people with no math / tex / computer background.   

- Documentation is an ongoing process. When working on the ref manual [the
new one] i decided to split off metapost graphic in a separate manual. I
will do the same with interactive documents, which will be combined with
designing layouts, since thiose layouts are the most demanding. The ref
manual will then only cover the basics. The complete interface will be
covered in the interface documentation.  

- One problem that people will encounter when using context aside latex or
any tex, is that they need to forget things. As soon as you start looking
for similar things, you will not easilly find them. The reason is that
stucturing documents is the starting point and not so much designing them.
Here we use context for collections of [often large] educational documents,
and there we want for instance a 500 page document with 400 figures to be
processed without any manual intervention in often more than one
incarnation. Or, a collection of quality assurance manual, made up out of a
multitude of procedures, with flow charts and so, with extensive cross
referencing, tocs at every level, a high level of data abstraction [no
name, function, number or id is coded more than once]. Or, a recently
started project, a math school method to be developped by a team of
teachers, with a broad range of products, and therefore extensive reuse of
resources. Most of the context features deal with those issues and in
detail typo control [which for instance siep wants] is actually the second
agenda. This control also depends on the level of module documentation. For
instance, core-rul, is a good example of a finished and stable module,
which in my opinion is also documented in an acceptable way. On the other
hand, the otr, output routine and spacing engine, is still not fully
finished and documented. It will be since i;m working on it now. As an
example, i just implemented, willy egger may like that, multi column spread
control, with page imposition support for figures or whatever spanning a
page and so. Now this is no easy topic and will never be, even if i write
500 pages about it. -) 

- Whatever is implemented, using tex (context) as a dtp system is always
complicated. No matter how many hooks are provided.  

- So, don't consider context finished yet, but you may enjoy [or hate] it
nevertheless,  

Hans    
-------------------------------------------------------------------------
                                                  Hans Hagen | PRAGMA ADE
                      Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------