Frank Millman wrote:
> After much investigation into the question of printing, I have come to
the
> conclusion that wxPostScriptDC is just not suitable for printing
text-based
> reports to non-PostScript printers.
Chris Barker wrote:
You may be right, but I think some of your problems can be solved.
However, I have really only done a little bit with this.
Thanks for the reply, Chris - I really appreciate your input.
>I cannot comment on PostScript printers, as I do not have one to test
with.
I doubt that would make much difference, ghostscript is very robust.
> Here is my test page -
If you put this is a complete sample app, I(and probably some others)
will give it a test, and see what we can do.
Complete app attached.
> Performance - if I click 'Print' from the Print Preview dialog, it takes
> about 5 seconds before the light on the HP comes on to indicate that it
has
> received the page.
What if you save it as postscript and print that directly with "lpr
test.ps"
Interesting - it takes less than 1 second to create the file, and less than
1 second to print it with lpr.
However, if I print directly from the PrintDialog, the progress dialog with
the cancel button stays on the screen for about 4 seconds, and the printer
only receives the job after it has closed. I have no idea what is happening
here.
> Version - if I print to a file, wxPostScriptDC produces a file with
> 'PS-Adobe-2.0' at the top, with a length of 29937 bytes. If I print the
> equivalent OpenOffice Writer page to a file, it produces a file with
> 'PS-Adobe-3.0' at the top, with a length of 449114 bytes. I do not know
if
> this is significant, but see my next point.
off the top of my head, and order of magnitude smaller looks good, not
bad!
I tend to agree, but I thought I would mention it in case it was
significant.
> Raw text - I tried both ps2ascii and pstotext to extract the text from
the
> above files, for sending to a dot-matrix printer.
This is probably not the way to go anyway. You're just asking for
problems. If you need to print to a text printer, you might as well just
create the text as text.
I will explain what I am trying to achieve - perhaps someone can suggest an
alternative approach.
I am writing a generalised accounting package. If it is successful, I will
release it as open source and hopefully make money from support.
I need to make printing as generalised and flexible as possible. There will
be a report writer, allowing users to define their own reports, document
formats, etc. There will be some mechanism (haven't thought this through
yet) to allow them to specify which reports go to which printer, or to
specify a runtime selection.
I have done this kind of thing before, but there are two aspects of the wx
printing framework that give me capabilities I have lacked in the past - a
print preview, and the ability to embed images - for example a barchart to
represent data over a 12-month period, a picture of a product item, etc.
I am still at the 'concept-proving' stage, but it looks as if MSW handles
this requirement very smoothly. If I use wxPrinterDC to format a page, and
send it to the HP LaserJet, it prints beautifully. If I send it to a generic
text printer, it prints the text in the normal way, without any formatting.
Presumably it will hiccup if you try to send images to a text printer (I
haven't tried), but that is up to the user to control which reports go to
which printer.
This approach suits me, as I do not have to distinguish between text-based
reports and other reports - all are handled through the same framework. I am
trying to achieve the same with wxPostScriptDC, but so far without success.
> Scaling - in preview mode, the default point size of 10 is acceptable.
If not in preview mode, I have to set the point size to 80 to get a
reasonable output. It took me a while to realise this, but it explains why
previously my text appeared as a tiny row of dots.
check what you get for :
wxPrintout.GetPPIPrinter()or maybe DC.GetPPI()
GetPPIPrinter gives me (72,72), GetPPIScreen gives me (91,92).
dc.GetPPI() gives me (72,72) in printing mode, (92,92) in preview mode.
> My workaround is to loop through
> each point size from 1 to 99, set the font, get the TextExtent of a
single
> character, and extract the height. I continue the loop until I reach an
> acceptable height.You certainly shouldn't have to do that!
This is all a little fuzzy for me too, but I think you might need to do
something with DC.SetUserScale(). The issue is that Postscript uses
points as it's native unit, but wxDCs require integer arguments (darn
that C++). If you were to work in Points, you couldn't get sub-point
resolution, so I think the default is to set it up to use 1/10 pt as the
standard unit (720 ppi). That may be what is messing things up for you.
Actually I don't think my workaround is too bad. Point size does not mean
too much to a user, but lines per page does. If I can get the height of the
font, I can divide it into the page size (adjusting for margins) and
calculate lines per page. I would not do this every time a report is run. I
would do it at the point of defining the printer, and then store the results
in a database and retrieve them at printing time.
I have read the docs on SetUserScale(), and also on SetMapMode(). They seem
to be relevant to my problem, but I do not really understand how to
manipulate them to get the results that I want.
> Any comments will be appreciated. First prize for me will be for someone
to
> say that I am doing it all wrong, and explain how I am supposed to use
> wxPostScriptDC correctly.Are you using the wxPrintout() class?
Yes - see attached sample program.
Also, there were some posts to this list recently by Jean-Michel Fauth
about some of the strang printing issues...I would look for them.
I printed these out at the time, and I have referred to them a lot in trying
to figure out what is happening. Many thanks for this, Jean-Michel. And
while I am about it, thanks also to Roger Binns - your comments forced me to
read up on Ghostscript, and I have a much better understanding of the
mechanism now.
Again, post a working sample app, and I'll take a look.
-Chris
I really appreciate your time, Chris. Many thanks.
Frank
print6.py (3.22 KB)