I think I've identified the problem: in the PostScript prologue file for pstoedit you find the following bit of code (slightly simplified): /getorigfont { dup /OrigFont known { /OrigFont get getorigfont } if } def I guess anyone, even not familiar with PostScript, can spot the error here: getorigfont is called recursively ad infinitum! I have no idea why this is so, but this mistake is easy to correct, by simply commenting out the innermost “getorigfont”; and it indeed fixes the problem with Wolfgang's code. Why the error wouldn't happen with older versions of gs isn't clear to me and I haven't tested it (for debugging I used pstoedit 3.44 and gs 8.56 throughout); on the other hand, it's quite clear why the bug wouldn't show up on code that uses only outlines and no font, like in the last example of http://wiki.contextgarden.net/User-Defined_Enumerations as George pointed out: the spurious piece of code is only used for font redefinitions and is therefore not called in the case of the fuzzy itemize style, because the symbols are not taken from a font. For people wanting to compile an amended version of pstoedit, the attached patch should do the trick, although hand-editing the relevant file (src/pstoedit.ph) should be just as easy (this is really a 2-byte patch — and you can even turn it into a 2-bit patch ;-).

Since pstoedit mucks with ghostscript's SYSTEMDICT it isn't surprising that problems arise for newer gs versions.

That's what I thought too (even if the bug had nothing to do with that apparently). I wonder if all that is really needed and if it wouldn't be simpler and less error-prone to use a custom dictionary where all the overriding functions are defined. Instead the author of pstoedit does quite scary things with systemdict ...

Maybe it is time for ghostscript to get an mpost driver.

Sure, wouldn't harm either. Arthur