Native Windows printing support, using the infrastructure I put in
authorsimon <simon@cda61777-01e9-0310-a592-d414129be87e>
Sat, 20 Aug 2005 15:48:55 +0000 (15:48 +0000)
committersimon <simon@cda61777-01e9-0310-a592-d414129be87e>
Sat, 20 Aug 2005 15:48:55 +0000 (15:48 +0000)
commit821ab2c68e12d85d6bb2ed8b0d48c846a65d06a0
tree54c723372808766c93b7d41a9607c68eb54d4e91
parentf487468f67fa996caab7de5b08a5da2c25ebd551
Native Windows printing support, using the infrastructure I put in
place in r6190. I'm quite pleased that I didn't have to modify the
printing infrastructure _at all_ to make this work; the only source
change required outside windows.c was the addition of a trivial
utility function midend_get_params(), and that was for the benefit
of bulk puzzle generation rather than anything to do with actual
printing.

As far as I can tell, all printable puzzles now print almost
indistinguishably from the way they print under Unix. If you look
closely the font is slightly different, and the Windows standard
hatching doesn't seem to be quite as nice as the kind I did by hand
in ps.c (and, particularly annoyingly, hatched areas don't show up
at all for me when I print to a file and use gv, though they come
out fine on the printer itself); but it's all there, and it all
works.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@6193 cda61777-01e9-0310-a592-d414129be87e
Recipe
devel.but
midend.c
puzzles.h
windows.c