As part of my program I’m porting (rescuing, rather) to wxPython (http://jkltech.net/taxidi/) I need a cross-platform solution to generate name badges and push them to a label printer. In the original BASIC language, printing was a matter of creating a graphics canvas, drawing the output, and flushing the huge bitmap to the printer. In looking at the analogue for wx, I found HtmlEasyPrinting, and thought “cool, I can just use markup to format badges”.
I grabbed the printer class from the wonderful pythonlibrary.org blog (http://www.blog.pythonlibrary.org/2010/04/16/how-to-take-a-screenshot-of-your-wxpython-app-and-print-it/) and set to work. After getting an acceptable looking preview given the limits of pure HTML, I send it to cups for the postscript output and am somewhat disappointed. From the HtmlEasyPrinting preview (top left), to the print preview (bottom right), to the actual output (top right), to what the output should resemble (bottom left), there’s at least one thing terribly wrong. Granted, a bit of fiddling with margins and some further HTML table hacking I’m sure I could end up with a workable output, but I’d like to explore my options.
Does anyone have any suggestions as to taming printing methods? Should I use the full-throttle wx printing method, stick it out with HTML, or use something else entirely?
ReportLab might be an option, if you don't mind .pdf as an intermediate step. It allows near perfect control of the output without resorting to the low level of wx printing.
Michael
···
On 2012-03-15 1:12 PM, redxine wrote:
Does anyone have any suggestions as to taming printing methods? Should I use
the full-throttle wx printing method, stick it out with HTML, or use something
else entirely?
If you go that route (I recommend it) you'll also need to tame how to output to specific printers on the various operating systems. For that, the only acceptable solution I've found so far is gsprint, which is included in gsview, which requires ghostscript, which is GPL.
Dabo has a capable report writer which uses reportlab to make Crystal-Reports-like reports from tabular data.
Paul
···
On 3/15/12 11:21 AM, Michael Hipp wrote:
On 2012-03-15 1:12 PM, redxine wrote:
Does anyone have any suggestions as to taming printing methods? Should I use
the full-throttle wx printing method, stick it out with HTML, or use something
else entirely?
ReportLab might be an option, if you don't mind .pdf as an intermediate step. It
allows near perfect control of the output without resorting to the low level of wx
printing.
So taking that route would mean doing the nitty-gritty CUPS/Win32 interfacing for setting the default printer, margins, et cetera? Also I’m not sure that a formatted label like this would be easy to spell out for reporting languages, but I could be wrong.
···
On Thursday, 15 March 2012 19:27:59 UTC+1, Paul McNett wrote:
On 3/15/12 11:21 AM, Michael Hipp wrote:
On 2012-03-15 1:12 PM, redxine wrote:
Does anyone have any suggestions as to taming printing methods? Should I use
the full-throttle wx printing method, stick it out with HTML, or use something
else entirely?
ReportLab might be an option, if you don’t mind .pdf as an intermediate step. It
allows near perfect control of the output without resorting to the low level of wx
printing.
If you go that route (I recommend it) you’ll also need to tame how to output to
specific printers on the various operating systems. For that, the only acceptable
solution I’ve found so far is gsprint, which is included in gsview, which requires
ghostscript, which is GPL.
Dabo has a capable report writer which uses reportlab to make Crystal-Reports-like
reports from tabular data.
Paul
redxine wrote:
As part of my program I'm porting (rescuing, rather)
to wxPython (http://jkltech.net/taxidi/ )
I need a cross-platform solution to generate name badges and push
them to a label printer. In the original BASIC language, printing
was a matter of creating a graphics canvas, drawing the output,
and flushing the huge bitmap to the printer. In looking at the
analogue for wx, I found HtmlEasyPrinting, and thought * “cool,
I can just use markup to format badges”*.
If only it were that easy. Label printing usually requires very
precise control over object size and placement, and that’s something
that “easy” printing solutions do not provide. There are too many
resolution translations and font substitutions going on.
I use Python to drive the little 203-dpi thermal label printers
(like the Dymo LabelWriters). The only way I could achieve
happiness was to go as low-level as possible. I don’t remember now
whether I used the wx printing abstraction or straight to GDI –
I’ll have to look that up. In my case, the trickiest part was
configuring the printer driver to understand the label format and
get the portrait/landscape settings correctly. On Windows, at
least, all of that stuff is vendor-defined.
If your "screenshot" method is close, it's probably worth it for you
to do the margin twiddling to get things to work.
···
-- Tim Roberts, Providenza & Boekelheide, Inc.
timr@probo.com
That’s precisely what I need to do. I don’t have a printer to test with at the moment, but I originally developed with the Brother QL-500. The bitmap method was a matter of trial and error as to how large to make the bitmap, with everything else relying on defaults in Win32’s print raster. I had wished for doing this pro-grammatically to save some configuration, but I might have to resort to that.
···
On Thursday, 15 March 2012 19:46:31 UTC+1, Tim Roberts wrote:
redxine wrote:
As part of my program I'm porting (rescuing, rather)
to wxPython (http://jkltech.net/taxidi/ )
I need a cross-platform solution to generate name badges and push
them to a label printer. In the original BASIC language, printing
was a matter of creating a graphics canvas, drawing the output,
and flushing the huge bitmap to the printer. In looking at the
analogue for wx, I found HtmlEasyPrinting, and thought * “cool,
I can just use markup to format badges”*.
If only it were that easy. Label printing usually requires very
precise control over object size and placement, and that’s something
that “easy” printing solutions do not provide. There are too many
resolution translations and font substitutions going on.
I use Python to drive the little 203-dpi thermal label printers
(like the Dymo LabelWriters). The only way I could achieve
happiness was to go as low-level as possible. I don’t remember now
whether I used the wx printing abstraction or straight to GDI –
I’ll have to look that up. In my case, the trickiest part was
configuring the printer driver to understand the label format and
get the portrait/landscape settings correctly. On Windows, at
least, all of that stuff is vendor-defined.
If your "screenshot" method is close, it's probably worth it for you
to do the margin twiddling to get things to work.
-- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
So taking that route would mean doing the nitty-gritty CUPS/Win32
interfacing for setting the default printer, margins, et cetera?
or punting and jsut save a pdf -- then let teh user print it with
whatever tehy have to print pdfs (you could probably save a step by
calling "open" in a system call.
But I suspect with some margin twiddling, you can get what you want.
If not:
1) you can write to an off-screen bitmap with wxHtmlWindow -- then
throw that at the printer -- that way you'd have consistent layout.
2) you could just draw with a DC -- with layout as consistent as you
have, it would not be hard to do.
-Chris
Also I'm
···
On Thu, Mar 15, 2012 at 11:34 AM, redxine <jkltechinc@gmail.com> wrote:
not sure that a formatted label like this would be easy to spell out for
reporting languages, but I could be wrong.
On Thursday, 15 March 2012 19:27:59 UTC+1, Paul McNett wrote:
On 3/15/12 11:21 AM, Michael Hipp wrote:
> On 2012-03-15 1:12 PM, redxine wrote:
>> Does anyone have any suggestions as to taming printing methods? Should
>> I use
>> the full-throttle wx printing method, stick it out with HTML, or use
>> something
>> else entirely?
>
> ReportLab might be an option, if you don't mind .pdf as an intermediate
> step. It
> allows near perfect control of the output without resorting to the low
> level of wx
> printing.
If you go that route (I recommend it) you'll also need to tame how to
output to
specific printers on the various operating systems. For that, the only
acceptable
solution I've found so far is gsprint, which is included in gsview, which
requires
ghostscript, which is GPL.
Dabo has a capable report writer which uses reportlab to make
Crystal-Reports-like
reports from tabular data.
Paul
--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
or punting and jsut save a pdf – then let teh user print it with
whatever tehy have to print pdfs (you could probably save a step by
calling “open” in a system call.
The problem is printing needs to happen with technically no user interaction. The decision to print is made by a setting in the application, and a single name badge is generated instantly when the child is checked in. I’ve never done anything with DC… is there anything someone can point me to for getting started?
···
On Thursday, 15 March 2012 21:40:12 UTC+1, Chris Barker wrote:
On Thu, Mar 15, 2012 at 11:34 AM, redxine jkltechinc@gmail.com wrote:
So taking that route would mean doing the nitty-gritty CUPS/Win32
interfacing for setting the default printer, margins, et cetera?
or punting and jsut save a pdf – then let teh user print it with
whatever tehy have to print pdfs (you could probably save a step by
calling “open” in a system call.
But I suspect with some margin twiddling, you can get what you want.
If not:
- you can write to an off-screen bitmap with wxHtmlWindow – then
throw that at the printer – that way you’d have consistent layout.
- you could just draw with a DC – with layout as consistent as you
have, it would not be hard to do.
-Chris
Also I’m
not sure that a formatted label like this would be easy to spell out for
reporting languages, but I could be wrong.
On Thursday, 15 March 2012 19:27:59 UTC+1, Paul McNett wrote:
On 3/15/12 11:21 AM, Michael Hipp wrote:
On 2012-03-15 1:12 PM, redxine wrote:
Does anyone have any suggestions as to taming printing methods? Should
I use
the full-throttle wx printing method, stick it out with HTML, or use
something
else entirely?
ReportLab might be an option, if you don’t mind .pdf as an intermediate
step. It
allows near perfect control of the output without resorting to the low
level of wx
printing.
If you go that route (I recommend it) you’ll also need to tame how to
output to
specific printers on the various operating systems. For that, the only
acceptable
solution I’ve found so far is gsprint, which is included in gsview, which
requires
ghostscript, which is GPL.
Dabo has a capable report writer which uses reportlab to make
Crystal-Reports-like
reports from tabular data.
Paul
–
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en
–
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
When I did this once before I just used the built-in printer control language of the device. Mine happened to be a Zebra badge/label printer (something like a TLP 2824, IIRC). It was just a matter of sending strings to it. I then wrote some python classes and functions to abstract it a bit.
Michael
···
On 2012-03-15 4:01 PM, redxine wrote:
or punting and jsut save a pdf -- then let teh user print it with
whatever tehy have to print pdfs (you could probably save a step by
calling "open" in a system call.
The problem is printing needs to happen with technically no user interaction.
The decision to print is made by a setting in the application, and a single
name badge is generated instantly when the child is checked in. I've never done
anything with DC... is there anything someone can point me to for getting started?
Okay, I’ve had a bit more success with the HTML, and am pretty certain that setting the margins to 0 will solve my problems. My final problem is submitting the job without the dialogue. Is there a method in HtmlEasyPrinting that will allow this, with data supplied from wx.PrintDialogData(), or am I way off? I can have my program pickle the PrintDialogData() and retrieve it later to select the correct printer, or at the very least I need to be able to submit HTML to the default printer. Can wxPrinter be overloaded to parse HTML, or am I still looking at working with everything myself?