bill@phys0.anu.oz (06/23/88)
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 understand why Adobe does this (to protect the proprietriness of the
font), but does anyone have a solution to these problems (preferrably not
involving designing a new font)?
Bill Alford, SCU RSPhySc, ANU, GPO Box 4, Canberra ACT 2601, Australia
or bill@phys0.anu.ozbill@phys0.anu.oz (06/24/88)
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.ozandwi@miraculix.liu.se (Andreas Wickberg) (07/01/88)
In article <5@phys0.anu.oz> bill@phys0.anu.oz writes: >The second problem is this: what I would like to be able to do is a proper >"solid shadowing" of a font ... This is not exactly what you asked for, but hopfully it helps a bit. It's a shading I come up with yesterday when I demonstrated why there might be a point in hacking postscript directly. It relies on the fact that 'stroke' uses the transformation matrix, a feature I don't think is documented in the red book. %!PS /shprint { gsave dup exec matrix currentmatrix 1 setlinewidth -30 rotate 10 4 scale gsave stroke grestore gsave .8 .6 scale 1 setgray stroke grestore .6 .025 scale stroke -.5 dup transform 3 -1 roll setmatrix itransform translate exec .7 setgray gsave fill grestore .1 setlinewidth stroke grestore } bind def 1 setlinejoin currentscreen 3 -1 roll pop 90 3 1 roll setscreen /Palatino-Bold findfont 50 scalefont setfont { 248 400 moveto (P) true charpath -5 0 rmoveto (ost) true charpath 220 370 moveto (S) true charpath -3 0 rmoveto (cript) true charpath flattenpath } shprint showpage
liam@cs.qmc.ac.uk (William Roberts) (07/05/88)
In article <5@phys0.anu.oz> bill@phys0.anu.oz writes: >both of which are probably PostScript design limitation problems A chisel can be used for opening tins of paint - are you using PostScript wrongly? >I would like to 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 ... >gsave > diagram1 strokepath clip > gsave diagram 1 setgray stroke grestore >grestore Correct, the way to do this kind of thing is buy use of clipping. There is a gap in Adobe PostScript however; you can't ask for an "imagepath" and so you can't clip in/out using an image rather than an outline. >What I would like is use part of the frame buffer assembled so far >as input to the imagemask operator Not all PostScript devices have framebuffers, e.g. the big Linotronic machines. >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. This does have severe hidden-line problems and clipping is going to be an awkward way of dealing with it, especially since you can't get at the path descriptions for characters. I would give up on this one... >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). I can do this! Use charpath to get outline of the character and then stroke it a) with a wide black line, then b) with a silghtly thinner white line, then draw the character itself. The stroke operator does exactly the "thick edging" you require, though unfortunately the results of "strokepath" isn't suitable for clipping. >I have always regarded the omission of a dotless j from the Adobe fonts >a serious omission. Has anybody ever properly overcome this omission? Clipping again. Experiment with big copies of ordinary j to find out a rough bounding rectangle for the j stem without the dot, then create a new character which first clips to that region and then draws an ordinary j. Hey presto, the clipping removes the unwanted dot. -- William Roberts ARPA: liam@cs.qmc.ac.uk (gw: cs.ucl.edu) Queen Mary College UUCP: liam@qmc-cs.UUCP LONDON, UK Tel: 01-975 5250
sg1q+@andrew.cmu.edu (Simon Peter Gatrall) (07/06/88)
>Whilst on this topic, I have always regarded the >omission of a dotless j from the Adobe fonts a serious omission. Permit me to ask what I hope is a stupid question. Why on earth would you want a dotless j? -Simon Gatrall sg1q+@andrew.cmu.edu
ken@cs.rochester.edu (Ken Yap) (07/06/88)
|Permit me to ask what I hope is a stupid question. |Why on earth would you want a dotless j? Because the j has to lose a dot before gaining a circumflex. My reference lists Esperanto as using \^j. Does anybody know any other languages that need a dotless j? Ken
ccs029@dino.ucdavis.edu (Val Luck) (03/28/91)
Hello: I am desperate to get some PS graphics output. Unix's PSRASTER sends a PS file that my postscript printer simple ignores, as if there were no showpage command, and PGMTOPS won't center my graphics file right! Half of it is off the page!! I am printing simple 2-color graphics (black & white) bitmaps. I am thinking of resorting to writing actual PS code myself if I can't get the two above programs to work. Does anyone have a simple file or a "shell" of a PS file that would set up the PS for accepting graphics code, and also tell what kind of code it is in? Is it rows across and then down or what? Please, anybody!! --Val -- ****************************************************************************** |------| _|___|_ Internet: ** Today is the tomorrow | | | | | | valuck@ucdavis.edu ** that you worried about |------| --------- ** yesterday.