textbackground > bug

textbackground > bug

[Hans van der Meer]

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

Re: textbackground > bug

[Taco Hoekwater]

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}

Re: textbackground > bug

[Hans van der Meer]

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

Re: textbackground > bug

[Hans Hagen]

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