[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

Printing - please test [was Re: [XaraXtreme-dev] 0.6 Release]

Alex is completing the first version of printing support ready for this release. Once he’s ready we’ll be asking people on the list to test this for us.

This is in a state ready for testing in that the further changes I've
got to make aren't going to make it for 0.6.

Things I don't want to hear about because I already know about them.

* Printing to PDF is neither offered, nor works.

* The print dialog is the wxWidgets default. The dialog used by
  various gnome apps is nicer.

* The print setup dialog is referred to (confusingly) in one
  place by wxWidgets as "print options" (see above).

* The print system does not read any useful information from the
  printer driver. I know. Auto fit thus doesn't do anything useful.
  It also thinks the entire page is printable, so print borders
  don't appear.

* Print marks almost certainly don't work.

* Deficiencies in the print dialog mean various print functions
  cannot be accessed (e.g. print selection).

* The default print resolution is a bit cranky. As I can't read
  anything about the printer (it isn't reading PPD files yet) it
  assumes it's a 600dpi printer because that's what's in my house :-)

* Print as bitmap defaults to 100dpi not 200dpi (see above).

* Print as bitmap has horizontal striping artefacts especially
  at low print resolutions and when the page is rotated. I've
  tested this pretty extensively and concluded that it is neither
  worse nor better than Xtreme.

* When not printing as a bitmap, PS is always used. This is currently
  "the linux way", as GhostScript is used to print.

* When not printing as bitmap, graduated fills have too few steps
  when displayed on screen and possibly on the printer.
  I have narrowed this down to a postscript problem in our own code.
  Essentially we do not check for the halftone screen size in a
  sensible way, and we do not assume a halftone screen size equal to
  a device pixel on contone devices (we use the halftone screensize
  Ghostscript returns as a default - the GS devs say their behaviour
  is right and who am I to argue). This makes PS fills look terrible
  on screen, but they'll be OK when printed out. Volunteers to fix
  the PS routine (or better to fix grad fills so they use L2 PS
  grad fill primatives) very welcome.

Code to read PPD files and thus paper sizes will hopefully be in
the next release. Also some amendment to the print dialog.