Something strange happens with textbackground (again, I am afraid). I defined: % Java typesetting with background. \definetyping[JAVA] \setuptyping[JAVA][option=JV, before={\bgroup\setupinterlinespace[line=2.2ex]% \testpage[1]\starttextbackground[code]}, after={\stoptextbackground\egroup}] Then I typeset some text: \startJAVA public void setUserManager( UserManager um ) { ...... \stopJava If this falls precisely at the start of a new page I get the following error: ! Undefined control sequence. l.17 \s tartpdffontresource[ec] Forcing the typesetting to run further the output contains the rest of the source of macro \startpdffontresource[ec] . I.e. the output then shows (the \s has disappeared): tartpdffontresource[ec] /CIDInit /ProcSet findresource begin ... --------- and goes on until (the last part of the macro "end end \stoppdffontresource" not appearing) ... CMapName currentdict /CMap defineresource pop Hereafter typesetting is resumed.
Introducing something that puts another line of text at the top of the page results in normal typesetting.<<<
Further experiment replacing "\startJava" by "\starttextbackground[somecolor]" leads to the same error. 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? It is of cource very annoying if one constantly has to shift textmaterial up and down to move it away from page breaks! yours sincerely, dr. H. van der Meer
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}
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
Hans van der Meer wrote:
Forcing the typesetting to run further the output contains the rest of the source of macro \startpdffontresource[ec] . I.e. the output then shows (the \s has disappeared):
tartpdffontresource[ec] /CIDInit /ProcSet findresource begin ... --------- and goes on until (the last part of the macro "end end \stoppdffontresource" not appearing) ... CMapName currentdict /CMap defineresource pop
Hereafter typesetting is resumed.
Introducing something that puts another line of text at the top of the page results in normal typesetting.<<<
Further experiment replacing "\startJava" by "\starttextbackground[somecolor]" leads to the same error.
i ran into that as well, a solution is (cont-new.tex): \let\normalstartreadingfile\startreadingfile \let\normalstopreadingfile \stopreadingfile \def\startreadingfile {\normalstartreadingfile \pushendofline \restoreendofline} \def\stopreadingfile {\popendofline \normalstopreadingfile} but i did patch something more fundamental (i forgot what/where, i leave that for taco to uncover when i update) Hans
participants (3)
-
Hans Hagen -
Hans van der Meer -
Taco Hoekwater