[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Printing - please test [was Re: [XaraXtreme-dev] 0.6 Release]
- From: Alex Bligh <alex@xxxxxxxxxxx>
- Date: Wed, 05 Jul 2006 17:50:10 +0100
- Subject: 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.
Alex