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:
It baffles me that anyone would consider using a printer language like HPL-6 as a generalized output. My 2 cents.
ZB Maybe it could be seen as "obsolete" - but I proposed this still with business applications in mind. Printing an invoice in the text mode, using HPCL (or Esc/P) is done instantly. And sometimes there's a need to print a long series of invoices (or other "pure text" documents); it's not always about printing canvas or images. As for PDF I totally agree, and because of this I've been suggesting separate "native" exports for PS and PDF: while PS format is something "native" for all the unix-like systems, perhaps the entire "rest of the world" prefers PDF rather. And for that latter ones the "conversion-oriented" solutions seems to be rather not convenient.
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.
SRIV After re-reading #5, I better understand what your interest is. PCL is very simple, and making a dialog to select font and line drawing options and map them to text tags could be easily done in pure tcl. I used to use WordPerfect 5.1 for DOS, and it could generate stunning output from a UI that was not much fancier than a text widget. For this type of output, I can see where PCL, PS, PDF, ASCII & Esc/P would be a fairly complete output driver list. Pagination and word wrap calculations are fairly straight forward, as 1 point = 1/72 in. For canvas output, I'd still stick with PS and convert that to other high-level page description languages.
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 like 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 postscript 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.
ferrieux - I second that idea. Perhaps a way of factoring efforts would be to center printing support on the canvas, and separately to provide a text->canvas conversion utility ?
ctasada - Somekind of Canvas integration will provide much more flexibility. And I'm not talking about the PostScript export. We really need some to control pagination, printing format, printer, ... I think that ferrieux approach is a good one :)
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 is 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 in which 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 closedsource format. Tcl/Tk, on the otherhand, is opensource and relies upon the idea of collective and open development. Just because code is opensource doesn't mean that its rubbish. But, there is also an expectation out there amongst the opensource community that 'up to date' languages have bindings which reflect the general state of progress. I don't see the portability of Tk as 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.
ZB I believe, it shouldn't be made in a way: "partially cross-platform, partially not". Cross-platform ability is a bit like pregnancy: a woman cannot be "a little bit pregnant" ;) - and similarly either the toolkit is really cross-platform, or it isn't. I'm aware about platform-related differences - but (at least currently) it isn't big problem, and it should be made to "no problem at all" rather than to fundamental differences of the sort: "you can print from within Linux, but not while working under OSX".
As for bindings: yes, I'm aware, you're comparing Tk with Gnocl, but while Gnocl just requires GTK ("no GTK" means "no Gnocl at all") - Tk is "standalone toolkit", expanded with its own packages set rather than with "foreign" libraries (if I properly understood its principles).
WJG I think you've made the point for me there, rather than undermined it. It is all about resource connectivity. Like it or not, our workstations are crammed full or resources just waiting to be used. Keeping Tcl/Tk insular, away from other 'foreign libraries' are its opensource weakness. The successful survival of any opensource project is based on successful communities: new users, new opportunities, new vistas, new software technologies, making projects interesting, exciting and engaging. Not more of the old stuff reworked and repacked. Take a look at the SPAM video on the Youtube linked above and you'll see what I mean. Implementing printing support for Tk is a great SOC project and adding Tk native printing will fill a big hole in the features list and I wish the students and mentors well with this potentially interesting project.
ZB It's not about open source, when - for example - Windows are not OS software. And the solution - as I wrote - should be portable for all supported architectures, not just for Linux. And if to print text widget's contents - when running a 10 KB TCL/Tk script - one will have to install GS/GTK/Cairo/Pango first (yes, that "open source resources" - all together around 100 MB(?)), such a solution will be of limited use.
WJG You've missed the point, totally. The idea is extensibility - using Tcl to communicate with new and powerful resources, resources which are usually in place. In fact the whole issue over printing is bigger than getting printout of an ascii text file and the issue of extensibility bigger that simple utilities programming using pipes. If we didn't have progress then, hell fire, we'd all still be running GEM! [L2 ] But wow, Tcl/Tk under GEM, that would be impressive. Well, on seconds thoughts, maybe not.
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).
SRIV I look forward to benchmarking PS->PDF conversion using Ghostscript versus canvas->PDF. As far as Ghostscript "taking too long", compared to what? PDF may be larger at times, but its also more portable, hence has a value. For me, the conversion from PS->PDF is so quick I never even give it a thought. ZB Without any comparison, conversion PS->PDF takes round 10 seconds on Pentium III 700 - and now you can easily count, how long it'll take to convert - say - 500 invoices... or should I calculate it for you? SRIV That may or may not be slow, depending on what you have to compare it with. For that PIII 700, what would you consider acceptable? 5 seconds or .5 seconds? ZB IMHO if we have to see such conversion routine as useful, it shouldn't take longer than 1-2 second on such "a bit lower end" hardware, like PIII-700 (it's not that slow, anyway). Of course, if you're printing just one page, that present 10 seconds doesn't hurt; but if we're going to use TCL/Tk to design - for example - business applications, conversion shouldn't be that time-consuming. Consider, please, case of an ISP, who's billing his customers each month, sending PDFs with invoices via e-mail; 500-1000 invoices aren't any exaggeration (it can be 10x-20x more as well). As for my other proposals: the "student" himself asked for proposals, so I proposed the ones, which I can see as useful. We'll see, what finally he'll choose to implement.
The two patents implemented in GhostScript are licensed under the GPL. Not an issue for me, 95% of the software I use is GPL. ZB So? Are you alone here? SRIV I can only speak for myself, but im interested in knowing what the patent concern is regarding a GPL patent.
Img is sized appropriately for its functionality. I often use a subset of Img if I don't plan on using all image formats that are supported. Its not buggy for me. Have you submitted a bug report? There are other png and jpeg extensions available if you prefer. ZB It's oversized, the bugs have been reported by others - even patches sent, that haven't been applied until today.
I can't find a reference on the Internet for the "GIF is enough" statement, same goes for most your statements. ZB Don't give up. ;) SRIV :)
Supporting 1 or 3 formats, ps, pcl & pdf, is of little difference to me when I still need to use CUPS to output the result to one of 1143 printer drivers. I'm not following the idea that a hand full more formats will buy you any more capability. I like the idea of adding capabilities, but not when the net gain is small with a maintenance cost that is high. ZB ...so you won't have to use it; I think, it won't be obligatory. SRIV I would use it, where applicable, assuming the result is faster and/or allows the my app to have fewer dependencies. Unfortunately, most programmers do not have knowledge or control over what model printers the end user will want to print to.
FM Suggest :
Interface :
pack [[text .t] insert 0.0 hello] puts [chan open [tk_choosePrinter] w] [.t print 0.0 end]
Format : Maybe dvi format should give a lot of coding sample and could open on various format conversions in tiny tools dvi2ps, dvi2pdfm, dvipng, dvigif, TkDVI, look at [L3 ] [L4 ] [L5 ] and also info about a to translate in PCL format with dvi2pcl [L6 ]
TLu 2009.05.24 For my small applications I use pdfLaTeX for generate reports. I've prepared minimalized TeXlive distribution with 6 fonts and minimum class. TeXLive 2005mini (for Win32 and Linux-i386) with sample here http://team-tl.livenet.pl/tomek/mikrotex/
MG Personally, I'd like to see printing support for all widgets in Tk, but would say that the text widget (followed by canvas) was most important. While the ability to export into pdf would be nice, I think it's a totally separate issue from printing. Yes, most platforms have an easy way to print pdfs - but making pdfs from Tcl then having something else print them isn't really printing support in Tcl/Tk. IMHO, the only printing support needed (and certainly the most desirable) is native printing directly from Tcl - launching the native dialogues for managing the page/print setup, and then directly interfacing with the printer in whatever way the particular OS supports, and printing the contents of the widgets. (And yes, I think this needs to be available like this, or at least as closely as this applies (I'm not familiar with how printing under Linux/OS X works), for all the platforms Tcl/Tk is supported on.)
SRIV 2009.06.04 http://msdn.microsoft.com/en-us/library/ms742418.aspx covers the API for printing from a Windows app. Microsoft changed how printing is done between XP and Vista. Their new XPS document format is also patented. If I had to print cross platform, I'd just take my generated PDF and deploy a modified Xpdf to act as a print preview/print dialog. Every print stack is based around the idea of generating an intermediate page description file. On Windows its EMF, WPF and XPS, on Linux/OSX its PDF & PostScript. I'll be sticking with PDF.
HJG 2015-06-18: as I already told on Things holding Tcl back, native print support in Tcl/Tk is still missing:
E.g. print an 'simple' invoice-form, with several fonts, using some foreign characters, and some graphics, like a company-logo.
There is Invoice-Demo, that mimics a commercial app thats wants to print some stuff.
It just needs print-support now...
See also the see-also -section there, for some links about printing.
Tcl/Tk 9 [L7 ] supports native printing.
See also: