🚀 go-pugleaf

Every now and then I come across PostScript bugs and/or limitations. 
You Netlanders out there may be able to help me with the following two 
problems, both of which are probably PostScript design limitation 
problems. The first problem is this: on a black and white pixel output device
I would like to, in general, draw one diagram over the top of another diagram
and where the second diagram's blackened pixels intersect the blackened pixels
of the first diagram I would like to do an exclusive or of the pixels 
(to produce a whitened pixel). As an example of this, consider the 
following lines of PostScript which solve the problem for two simple diagrams:
/inch{72 mul}def
/inchsquare{newpath 0 0 moveto 0 1 inch rlineto 1 inch 0 rlineto
            0 -1 inch rlineto closepath}def
1 inch 1 inch translate
/diagram {inchsquare 30 setlinewidth}def
/diagram1 {45 rotate inchsquare 2 setlinewidth}def
gsave diagram stroke grestore
gsave
  diagram1 strokepath clip
  gsave diagram 1 setgray stroke grestore
grestore
gsave diagram1 stroke grestore
gsave
  diagram strokepath clip
  gsave diagram1 1 setgray stroke grestore
grestore
showpage
What I would really like to be able to do, to generalize this PostScript,
is use part of the frame buffer assembled so far as input to the imagemask
operator, but I don't know of any way in PostScript to do this (yet). I realize
that to be able to do this is going to make PostScript less device independent,
and a colour output device would provide an easier solution to the problem.

The second problem is this: what I would like to be able to do is a proper
"solid shadowing" of a font with cross-connecting lines between the front of the
character and its shadow to create a proper 3-dimensional effect of a really
solid character sitting out from the page. This problem may also need the
removal of hidden lines. Another thing I would like to do with a font is draw a
proper outline of a character around an original black filled version of the
character (with white inbetween). Simple scaling won't solve this problem
where parts of a character curve back on themselves (I don't want a shadowing
effect there, I want a proper outline tracing of the font). In all my attempts
at an automated solution of these problems I come across the problem that Adobe
disables the pathforall operator when the charpath operator is in the current
path. I think I understand why Adobe does this (to protect the proprietriness
of fonts), but does anyone have a solution to these problems (preferrably not
involving designing a new font)? Solutions to these problems may have some
interesting consequences. Whilst on this topic, I have always regarded the
omission of a dotless j from the Adobe fonts a serious omission. Has anybody
ever properly overcome this omission? One solution which has crossed my mind
is to take a good guess at the CharStrings entry for j using suitable output
from the strokepath operator and then suitably incorporate this (minus the dot)
into a new version of the original Adobe font. This solution isn't a very
elegant solution.

Bill Alford, SCU RSPhySc, ANU, GPO Box 4, Canberra ACT 2601, Australia
or bill@phys0.anu.oz