On Dec 18, 2005, at 11:40, Taco Hoekwater wrote:
Hans van der Meer wrote:
Therefore I suspect it has something to do with the output routine where \s is taken as the next macro. A simpe experiment (\def\s{something}) shows that indeed a macro \s is executed. Is someone here messing up the catcode's of the letters?
Yes, the \startJAVA command :-)
The problem is that context is loading the pdfr-ec resource file (Glyph -> Unicode mapping) while the prettytype catcodes are in effect, and it does not properly switch back to "non-verbatim" catcodes.
I am not quite sure what the best way is to fix this, but I've redefined that loading macro in my preamble, like so, and it seems to work as a temporary workaround:
\def\dododoincludepdffontresource#1% encoding {\bgroup \def\currentencoding{#1}% \doifvaluesomething\pdffontfileresource {\uncatcodeallcharacters % new \catcode`\[=12 % new* \catcode`\]=12 % new* \setnaturalcatcodes % new \startreadingfile \readsysfile{pdfr-\getvalue\pdffontfileresource} \donothing\donothing \stopreadingfile \letgvalue\pdffontfileresource\empty}% \egroup}
OK, this macro stops the break into sourcecode. However, backgrounding is not failsafe yet. Still now and then the background wraps back on the previous page when the start falls at the beginning of a page. But this helps, so thanks. yours sincerely, dr. H. van der Meer