This is one of the GSoC 2009 Projects.
KBlicharski This site is considered to be a wish list for the text widget printing support. I hope features most needed to be implemented could be chosen by the middle of June and I would be grateful if you leave your opinion on that as well as - if there are any - express your preferences on how it is required to be implemented.
At this time I know that text widget is widely used to create reports or text editors, so options which I find useful are:
I'm open to any suggestions to what more should be added to this list.
Reference to 5: ZB I mean here the file prepared especially for HP-compatible printer, ready to be printed using single command; printing in such case will be much faster than processing *.ps file. LV Or maybe exporting the text in some (non-PostScript) text markup that could then be converted into various printer-specific formats? That would seem more flexible. ZB You can consider HPCL-6 as such "markup language", that can be further converted into any other, in case of need. The advantage would be, that one would have formatted file, ready for print-out on HPCL compatible printers without the need for any additional conversion.JSB I don't think you want to use PCL-6 as a standard (if any pcl) PCL-5 or less would be safer and have more coverage. ZB It's not about coverage; it's about possibility to transfer text window's contents with as few changes as possible. If PCL-5 will be enough - it's OK. But if not - never mind the "coverage", if PCL-6 will give better results
Reference to 6 & 7: Yes, there are some suggested solutions for the latter two at the wiki already, but all of them relying either on additional packages, or even on external utilities (like enscript and so on), and therefore aren't portable. Better would be - if possible - to have direct export possibility. Both file formats are important: "ps" because it can be further processed by other printing tools (like gs), and "pdf" because it's de facto standard in the documents exchange. JSB I think postscript would be the best bet overall and then the user can use other tools lie ghostscript to convert/print. Portable printing is tricky, hell printing to different printers on the same platform is bad enough sometimes. ZB Of course at least postcript would be very good - although having PDF and HPCL "natively" would be even better. And I think, when one export option will be done, the other ones will be easier to introduce, for the same person.
jdp - Actually, it would be nice to have printing support separate from the text widget - possibly some way of printing data directly, from a text widget, and from a canvas widget? That way it would be possible to add printing support to custom widgets, and possibly from tclsh as well.
My name is Krzysztof (Cris) Blicharski
Contact with me:
* via mail: [email protected]
* I also will be reachable via IRC (my nick will be blicharski)
WJG (17/05/09) I've been a keen user of Tcl/Tk for over a decade now and this problem has never been adequately addressed, nor has the issue of PDF support. Why? It the programming overhead. What we have are various lightweight Tcl/Tk only solutions with limited use. Tcl has always been described as an extensible language, one suited to binding to other resources. This however is an undervalued and underpromoted feature of the language. The way inwhich Tcl/Tk is used reminds me of SPAM, [L1 ] -it can be used thousand different ways, most of which are not very useful. So, having made a complaint I need to offer a solution. Create bindings to other opensource resources as suggested above. The Tk3d widget is the model for Tk developers to follow. There are resources out there to do these jobs, create the wrappers to use them! At the moment the development version of Gnocl already has native GTK printing support and pdf preview via Poppler bindings. No magic on my part, the resources are already there its a matter of making them available.
ZB The first problem is, that the solution should be portable (Windows, Linux, OSX, other unices...). The second one: what about the possibility to create standalone, executable packages, using tools like TDK? Pay attention, that not everything written in TCL/Tk is open-sourced.
WJG I've no doubt that much out there written in Tcl in not openSource and, who knows, perhaps some of those features much requested by the community are out there in close source format. Tcl/Tk, on the otherhand, is opensource, and there relies upon the idea of collective and open development. Just because code is opensource doesn't mean that its rubbish. But, there is an expectation out there amongst opensource community that 'up to date' languages have up to date bindings which ,lets face it are out there. Well, for some opensource development environments anyway. Portability is not really that much of an issue. What Graphics kit worth its salt isn't cross platform? If it is that critical then why not switch over to wxWidgets? Cross platform, mult-language bindings, much better widget set than Tk. The multi-platform sales pitch is old hat.
SRIV 17/05/09 I write business apps that need fonts & graphics for reports, so I use a canvas, send the postscript directly to the printer via a socket (if its Postscript capable) or pipe it through lpr/Ghostscript if its not Postscript capable. Ghostscript can create PDFs too. Ghostscript is available for windows and I believe its the core of CUPS on OSX (need backup for that). GS can be used as a print preview app as well, although the canvas works well enough for me.
For a text widget, I wrote a simple network printer driver that sends my text editor output to my laserjet in 80/132/160 cpi. I could get fancier if I chose to use Ghostscript to process the text.
I fail to see the need for any more capability that that. Sure, It could be packaged into a more user friendly add-on, but, the core tools for accomplishing cross platform printing do exist, without bindings or version dependencies. Just stuff it in your pipe and print it.
ZB All that current GS/Enscript-based "patents" barely are "workarounds for today". We need a real solution, and it's very good, that someone decided to work on it.
IMHO the less it'll be depending on the external utilities (like GS) - the better. And yes, GS is capable to convert the *.ps files into *.pdf - but it takes long time (when you're writing business software: think, how long it'll take to generate several hundreds of invoices in *.pdf format; besides: probably resulting *.pdf file is much larger). So having at least output into *.ps file would be very good - but having, at the same time, *.ps *.pdf *.pcl to choose from - would be much better. Of course, if it can be possible to implement during gsoc.
All that considerations "ps is enough" are looking like "GIF is enough" statement, and in effect only lately support for *.png has been added - but JPEG (and some other popular formats) we haven't got until today (Img is oversized and buggy).