[dev-context] how to \obeyMPlines?

Mojca Miklavec mojca.miklavec.lists at gmail.com
Thu Feb 15 16:55:15 CET 2007

On 2/15/07, Taco Hoekwater wrote:
> Mojca Miklavec wrote:
> > If I leave the \obeyMPlines there, I get spurious characters (probably
> > because TeX adds some character codes which correspond to \r or \n).
> Yes. The ^M in the file is \catcode 13, and gets turned into
> \obeyedline. \obeyedline, it seems, contains a carriage return with
> \catcode 12.
> > If I comment out the \obeyMPlines it works OK, but longer graphics
> > fail.
> \def\processMYfile[#1][#2]{%
>     \def\startMYgraphic
>        {\obeyMPlines % <- no longer a problem
>         \def\obeyedline{}% <- thanks to this
>         \dosingleargument\dostartMYgraphic}
>     \long\def\dostartMYgraphic[##1]##2\stopMYgraphic
>        {\startreusableMPgraphic{#1 ##1}##2\stopreusableMPgraphic}
>     \readlocfile{#2}{}{}}

Thanks a lot. I need to test it as soon as I come home ... I also
figured out yesterday (when I was combining multiple graphs with
\startcombination ... \stopcombination) that there is some spurious
blank space in front of the first plot (where there were those
spurious accents before). So it probably still means another hour or
more before I find that nasty bug ...

> > Also, sometimes it fails because of TeX memory limit exceeded. (If
> > gnuplot wants to draw a 100x100 grid, it needs 10.000 lines of code
> > times three - one for color, one for shape, one for actually
> > drawing/filling it, that makes it some 31.000 lines of code, and TeX
> > cannot handle that. Will there be any possibility for a solution to it
> > any time in the future except fixing gnuplot itself? It's not that
> > important, but I would just like to know if that issue is solvable at
> > all from within TeX or not.)
> Not right now. Hopefully the next metapost version (1.1, due out
> in late spring/summer) will allow you to 'store' a set of the grid
> boxes and call for it, so you could for example save a 10x10 square
> and execute it 100 times.

The problem is not in metapost.

I should probably try it before speaking, but I don't believe that
metapost would have problems processing the code. The problem is that
the content between
    ... lots of stuff ...
where TeX fails to store the contents between \startMPpage and
\stopMPpage. I doubt that fixing metapost in any respect could help
solving that.

Apart from that: the problem mostly lies in gnuplot itself. One
doesn't notice the problem when using bitmap images, and PostScript
code is also efficient enough. For properly fixing the problem, I
would need to modify the core gnuplot routines, so that they I could
optimize the behaviour for metapost. In this particular case it could
simply output a long list of colors and only the basic parameters for
drawing the grid instead of filling 10.000 rectangles explicitly. But
that's not the top priority right now.

The only two problems (or lack of features) I had with metapost so far are/were:

1.) drawing patterns (not really critical to solve - there are
workarounds; but would be nice to have it in a distant future):

- I have created an image (diagonal lines for example), say 1cm x 1cm.
Then I needed to fill some area, say 20cm x 20cm, which I did with a
nested for loop and redraw that image 400 times. I prepared
approximately 10 predefined images with different fill patterns, so
one chooses an index of the image to fill the area with (one could
also provide his own image), and a closed path which has to be filled.

That was the only case where I actually saw metapost running out of
memory (in most other cases it was TeX the one that complained).

2.) I need to figure out how to draw bitmap images. Either by
user-provided colors or ascii string, or even in the same way as
\sometxt works (where metapost doesn't even see the content).

Also, it would be great if I could draw a NxM bitmap image by providing
- a 2D function (like sin(x)*cos(y)) and
- a mapping from a value to color
to metapost.

This can all be done using "fill unitsquare shifted (i,j) withcolor
...", but the output is both ugly and inefficient.

A few days ago I figured out that "convert" from ImageMagick can draw
images like that (using some simple algebraic functions for specifying
a color channel value of a pixel), so I'm now using a hybrid of both
now (convert to create an image and metapost for enhancing it, but
it's a bit uncomfortable to mix the two).


More information about the dev-context mailing list