[tex-live] mysterious mpost problem

h h extern pragma at wxs.nl
Tue Jan 18 17:42:04 CET 2005

Taco Hoekwater wrote:
> Hi,
> This sounds very familiar. I think I remember Hans Hagen mentioning
> (privately?) this as well, but I can't seem to find any e-mail
> regarding this any more. I hope Hans remembers.
> Greetings, Taco
> Werner LEMBERG wrote:
>> [MetaPost 0.641 (Web2C 7.5.3)
>>  kpathsea version 3.5.3]
>> Please do the following, using the attached files:
>>   . Create mf2pt1.mem with `mpost --ini', using mf2pt1.mp.
>>   . Run `mpost --mem=mf2pt1 nospecial.mf'.
>> Now compare `nospecial.0' with `nospecial.1': The files should be
>> identical, but they aren't on my GNU/Linux box.  `nospecial.0' doesn't
>> contain any lines produced by the `special' command.
>> On the other hand,
>>   mpost '&mf2pt1 \input nospecial.mf'
>> gives the expected result.
>> AFAIK, the results should be the same, so it looks like a bug in
>> mpost.  Am I missing something?

it's already long ago that we ran into this, and discussed it; it has to do with 
the fact that those specials are collected at the mem boundary and when that 
boundary changes (due to either a change in the cnf file or due to another 
progname environment) things gets lost [strings getting lost is one side effect, 
but i think mp can even bomb]; in tex, some mem arrays can be adapted after 
format generation, like the top/bot men things, probably because the boundary 
mem areas are not used, contrary to metapost, and the problem is that in mp this 
is not stored [normally the frozen mem allocations are stored and changes in the 
cnf file have no consequence];


                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl

More information about the tex-live mailing list