Community
Participate
Working Groups
The print option is greyed out on the File menu, on the toolbar, and Ctl-P doesn't work to print. I was running 2.0.1, but upgraded to 2.1 to see if that made a difference. I am using SuSE 8.0
Printing is not implemented yet on GTK. Not sure GTK even provides an API. Felipe to investigate and advise.
As far as I know gnome applications can use gnome-print or gimp-print. There are other options like CUPS, anyway I don't know if any of these options can be integrated with our SWT/GTK port. I'll look at this issue in the future.
Felipe Heidrich: Can the existing (AFAIK Xprint-based) printing code be reused for the GTK+ port ?
We've thought about it, but it's not going to work. It would be a option if we could access some of the X resources that Gtk is using underneath. I'm afraid is not possible.
What about the option to use an external program? At least for me would be great just to have a print button that calls: enscript -Ejava <filename>
Ricardo, this solution does work for SWT at all, but maybe you could suggest this for the UI team (I don't think they will accept it though). If I were you I would write my own printing pluging using this idea.
Can see this also on linux-motif with 20021218304 (M4).
Adding Nick to this bug report. Nick, There is no GTK API for printing. The proposal here is to use another application for printing. This is not something SWT would provide access to, however, is it possible that the workbench could use this mechanism?
Since there appears to be no native means of printing on GTK that can be provided by SWT, I'm moving this PR to Platform UI as an enhancement request. The Workbench currently only provide the File / Print retargetable action, and no concrete implementations. The only concrete implementation is in the text editor, provided by Platform-Text, so I'm adding Kai to the cc list. If the Workbench were to adopt a printing story which allows external programs, then we could provide the preference page for configuring it, but clients like the Text Editor would now have to handle two different ways of printing (SWT vs. external program). Note that with the External Tools support, it would be straightforward to have an external program to print the selected file.
Could someone point me to the SWT printing APIs that are unimplemented on GTK. I'd like to take a look at this problem a bit before we punt and say it can't be done. Also, could Felipe explain what he found wrong with either the gimp-print or gnome-print APIs (both built on top of GTK) such that these were not usable. Having this context would really help me get started faster so I don't duplicate effort that Felipe already did. Thanks, Dave Orme
Felipe, can you address Dave's last comment?
Moving back to SWT since David is interested in pursuing an SWT-based printing solution on GTK.
Printer is a subclass of Device and must be able to be used as a Device. In order for SWT to support printing, you need to be able to create a GC on the printer device and support all the GC calls. I do not think this is what gimp- print or gnome-print provide. To see the unimplemented behaviour, start with org.eclipse.swt.printing.Printer.
Dave, when I locked into gimp-print and gnome-print I could not figure out how I could use this libraries to render GdkGC calls to a print device. Anyhow, take a look in org.eclipse.swt.printing.Printer, specially the method internal_new_GC. I don't know much about gimp-print and gnome-print, you won't be duplicating any effort looking at this problem.
Preliminary results: There are two approaches that are both probably feasable: - Gnome-print - Write a Printer device that passes Postscript to the platform printing system (on Unix, normally via lpr or equivalent) Advantages of Gnome-print: - Handles basic alpha channels (transparencey) automatically. I don't know if we care about this. - Can output Postscript, the standard for Unix printing. - Supports generating printer bitmaps directly, the way Windows printer drivers work. - Supports generating PDF files as printer output. - More likely to work across all desktop platforms supported by GTK including non-Unix-based ones. Disadvantages of Gnome-print: - Introduces quite a few dependencies: for libgnomeprint: Pango/Glib/libart/libxml for libgnomeprintui: above plus: gtk+/libgnomecanvas (We can probably get away without using libgnomeprintui since we provide our own print dialogs, etc.) - Introduces another layer between SWT and the actual printing. owen@redhat.com writes (on IRC): <owen> djo: gnome-print is not a bad idea, though you'll have to cover the difference between that and GdkDrawable (they are entirely different) yourself. Advantages of writing a Printer-to-Postscript filter: - Architecturally, the simplest solution - Matches the native Unix way of doing things - Does not require additional libraries - Many examples (in C, C++, and Java) of how to do this are available. Disadvantages of writing a Printer-to-Postscript filter: - It's potentially another layer to code and maintain. - Would not support native printing on Windows unless the Windows user had a Postscript printer. Otherwise, it would require filtering through Ghostscript on Windows. As Scott Stanchfield would say, "EEEeeeeewwwww." Conclusions: Right now I'm leaning toward the printer to Postscript solution. Gnome-print depends on a bunch of libraries that may not be on a lot of people's computers who have GTK+. Just making people install all these other libraries (in correct versions) gives me headaches thinking about all the mailing list and newsgroup traffic it would generate. Going with outputing a printer language file such as Postscript is the standard for printing in the Unix world, the main people who will use SWT with GTK+ (Windows users should use the Windows version of SWT. On the other hand, if they want to use a Unixy library, they should be prepared to deal with the Unixy way that it does things.) Although I haven't evaluated the code yet, there appears to be a few decent open source libraries for generating Postscript output using graphics calls. These have all been written to AWT-style calls, but that should provide a decent starting place for an SWT rewrite. Postscript: If we provide a Postscript printer meta-language output, we also can probably provide PDF output relatively easily (assuming appropriate abstractions are introduced to support the SWT-to-AWT drawing conversions) as there are PDF output open source libraries available. What does everyone here think so far?
One more observation about the above proposal: Providing a PostscriptPrinter object or a PDFPrinter object benefits all platforms, not just SWT/GTK. It just so happens that the standard way to print on Unixen is to pipe Postscript to the lpr program, which is why I am proposing this as a likely solution to printing using SWT on GTK.
Dave, SWT team has already consider the idea of generating postscript, which is a very generic solution and would work, but we prefer to have a GTK solution for printing. If GTK doesn't not have support for printing we are afraid that there will be no print support for SWT-GTK port. How does a GTK app print ? Do they need to use different libraries/packages ? Please see Bug#15146
>>If GTK doesn't not have support for printing we are afraid that there will be no print support for SWT-GTK port. How does a GTK app print ? Do they need to use different libraries/packages?<< Well, this has been the subject of quite a bit of debate in the Unix community for some time. Although I have never heard it explained this way, here is the reason I believe that Postscript output has been and remains the de facto standard way to print on Unixes (no matter what UI toolkit is being used): The whole Unix mindset is that everything, even network protocols and the whole graphical system, is just a file: preferably an ASCII file that is straightforward to parse. Once you make that design choice, a whole bunch of other things fall out of it naturally: - Most coding problems ultimately boil down to one of three things: a) How to generate some language (that will be stored in a file) b) How to parse some language (from a file). c) How to translate some file from language C to language D and store it in another file. - The algorithms required to code all of this corresponds really nicely with the categories of things you might want to do from theoretical computer science: a) Parse/generate/translate regular languages (regular expressions/finite state automata). b) Parse/generate/translate/interpret context-free languages (context-free grammars/push-down automata). c) Parse/generate/translate/interpret Turing-complete languages (Turing machines) These are all well-understood problems with stable solutions that we can reason about in a rigorous mathematical way if we want/need to. So these are very attractive features to have in an operating system for those who understand theoretical computer science--most of the people who created and still use Unix and Linux. Consequently, you see that a huge number of the common Unix command-line tools and scripting languages are really optimized for generating or parsing files: ls, ps, grep, sed, awk, perl, lex, yacc, CGI scripting is really just a way to reduce dynamic web scripting down to the well-understood problem of how to dynamically generate a file. - This explains why Postscript has been widely accepted as the "Unix"-way to print: it fits neatly into the above view of the world. Just generate an ASCII file in some simple standardized page description language (ie: postscript), then provide filter programs that can translate that language into any printer's native language and copy the result to the printer's file descriptor. It's a known, well-studied problem and because it corresponds nicely to the underlying theory, we can potentially reason about our solutions more rigorously and accurately. On the other hand, the other side of the argument contends that it's easier intuitively to print if you just use your UI toolkit's normal drawing commands to draw graphics on some drawable that conceptually corresponds to the printed page. This matches the Windows way of printing that appears to be where SWT got much of its base design. Personally, I think the whole argument is a wash from the application programmer's point of view. Really, generating something like: /Times-Roman findfont 12 scalefont setfont 72 72 moveto (Hello world!) show showpage or manipulating objects to do the equivalent of the above is going to require code of similar length and complexity in either case. Conceptually, it's just a different representation for exactly the same commands. In this case, I think that both beauty and ugliness are in the eye of the beholder. However, while researching this problem, I read additional arguments for generating Postscript beyond the theoretical ones explained above: In a number of mailing list threads, people argued that if *applications* rasterize their own page images, that you have two huge drawbacks: 1) Since the printed data stream is encoded in some opaque format, there is no way to write print spooler software that allows IT to automatically account for printer/paper usage. However, when you generate Postscript, the print spooler can interpret the Postscript just enough to count number of pages in print jobs, etc., to bill printing costs back to departments automatically. Or just so that Jane knows that Joe started a 200 page job so she should take a coffee break before sending her 2 page print job (or send the job to a different printer). 2) Under certain circumstances you can saturate the network if the printer is connected remotely via some print server. This also results in sub-optimal printing speeds when the page size is huge (think fast HP inkjet plotters) or when the DPI is high (think pre-press typesetters). So that brings us to where we are today: 1) We have Gnome-canvas, a Windows-like printing API that is usable, but not widely adopted across Unix applications. As I noted yesterday, it also has a number of library dependencies that we might want to think twice about requiring. 2) The Gimp and gimp-print, by themselves, are a red herring. Gimp normally just outputs Postscript, but can also use gimp-print as a plug-in to generate nicely optimized output for a wide variety of consumer-level color inkjet printers. However, I found a number of mailing list messages indicating that the gimp-print drivers are being migrated into Ghostscript. The result is that gimp-print isn't viable long-term as a way to generate printed output from some standalone application. 3) Lastly, we have the majority of Unix applications--from WordPerfect, OpenOffice, and Netscape to `enscript` (a command-line utility to translate plain text files into Postscript) and everything in between--that just generates Postscript output to be interpreted either by Ghostscript or by a Postscript printer. This appears not only to be the de facto standard way to do things on Unix, but based on the mailing list traffic I described above, also appears to be the best way to handle enterprise-level scalability needs. All of that to explain two things: 1) That the answer to your questions ("How does a GTK app print? Do they need to use different libraries/packages?") isn't totally straightforward because people disagree within the Unix and Linux community about the correct answer. 2) However, the majority of Unix shops still prefer just to generate, translate, and/or interpret Postscript from all of their Unix applications, GTK or not. In conclusion, I believe that SWT-driven GTK apps ideally should print just like any other well-behaved Unix citizen: by generating Postscript output. Yes, this probably means that the SWT for GTK port by itself may not provide printing services. However, as I pointed out yesterday, from the SWT point of view this doesn't matter. We can adapt any of the freely-available open source Java printing solutions that generate Postscript using an API similar to SWT. Or we could implement the SWT printing API on top of any of the C or C++ Postscript-generating libraries just like the rest of SWT is implemented. If this means that the GTK port doesn't have its own printing support, I don't have a problem with that as long as a Postscript output driver for SWT is provided instead and the Postscript output driver is selected by default on SWT/GTK.
>>We have Gnome-canvas, a Windows-like printing API that is usable, but not widely adopted across Unix applications. As I noted yesterday, it also has a number of library dependencies that we might want to think twice about requiring.<< I meant to say, "We have Gnome-print..."
One last thought: One design goal of SWT is to provide a native platform experience as much as possible. With regard to printing, this means that there needs to be a preference page somewhere or a place on the SWT print dialog on GTK where the print command (usually "lpr") is configured. Looking at other Unix-based apps may be useful here: Netscape: Put the print command on the print dialog itself. WordPerfect: Configure the print command as a part of the printer. Alternatively, we may just want to provide a property on an object where the print command is set and leave it to platform/UI and the standalone developers to set this value properly from a preference page.
Some Java drawing to Postscript/PDF libraries links: http://www.geocities.com/morris_hirsch/java/how_to_print.html http://www.geocities.com/marcoschmidt.geo/java-document-libraries.html I haven't evaluated these yet; I'm just sticking them here so everyone knows what I've found so far.
FH to track this.
*** Bug 43284 has been marked as a duplicate of this bug. ***
I just started working in earnest with Eclipse on Linux, using the GTK version, since I use GNOME. I also just discovered that you cannot print! Having tracked this down, to this enchancment request, I see that nothing appears to have been done since April of this year. Is there anyone still working on this issue?
Unfortunately, I have had seen no activity outside this watchlist. I would love to help, but I would cause more trouble than I could fix.
Unfortunately, printing on GTK is not in the Eclipse 3.0 plan. Further, we still don't have a solution for this problem, none of available technologies that I looked at (gimp-print, gnome-print, cups, etc) address the problem that need to be solved by SWT, which is: given a gdkgc render all the drawing to a printer instead of a window/display.
Can you be more specific about what you mean please? If I understand correctly, what you need is something that doesn't require SWT to render the print job into a printer language (i.e. postscript) - you want the printing system to do that. Am I correct? If so, what would you expect to send to the printing system?
Yes, you are correct. What is send to the printing system is up to the toolkit underneath swt, on X swt uses exactly the same X calls to draw either on a window or to a printer. Internally, XP (X printing extension) will translate the X calls to the appropriate language to be send to the printing system. The same on windows, but we use windows/GDI calls instead. I hope I answered your question.
Couldn't you just save the file the user is trying to print into /tmp and then call an external printing program? In the most rudementary example, I created a simple text file in vi and then did the following command from the console lpr <textfile.java> It printed just fine. Since one could expect that eclipse users would only be printing standard text, wouldn't this work? I'm sure with a little effort, you could extend this to work with any print system (kprinter in my particular case) David
Sure you could lpr text files. But for those of us who are using UML tools such as Borland's Togethersoft Plugin for Eclipse, there isn't any good way to do this.
That is not what printing on SWT does. Still, one could easily write a eclipse plugin to print out files using external programs, but that is not a solution for SWT.
And more generally, any plugin using GEF would have some problem to print. (e.g. EclipseUML) However, I miss the printing feature on GTK. It is IMHO undelievable that such a feature is missing on a "supported" platform.
It's not a real solution, but if anyone's interested I should point out that you can use the External Tools support in Eclipse to print files using external programs. Just create a new Program launch config from the External Tools dialog (Run->External Tools->External Tools...) that launches your favorite printing utility and you can pass the selected resource as a parameter.
OK, just so that I understand properly, SWT wants to "paint" it's printed canvas the same way it draws it on the screen. Is that right? Putting aside religious wars about widgets, would it be possible to use Qt/KDE to implement a proper print solution for SWT? Take a look at: http://printing.kde.org/developer/tutorial/basic.php KPrinter inherits from QPaintDevice, such that you can draw on it as on a normal QWidget. The drawing primitives are then converted to PS code instead of shown on the screen. You should thus consider the KPrinter object as a usual drawing area. That would seem to behave in a manner consistant with what SWT expects. I'm not advocating a switch to Qt (although I would really love to have a Qt version of SWT) but I am curious if that widget set would solve this particular problem. David
"OK, just so that I understand properly, SWT wants to "paint" it's printed canvas the same way it draws it on the screen. Is that right? " Right. The solution you pointed out would be perfect for a Qt port, what doesn't exist. We would need to have a GTK equivalent to that. We can't use Qt in the middle of our GTK port, there is technical reason for that as well as a legal one (I believe so). thanks for information.
All of these comments are correct about what is needed. There are links above to example Java code that does exactly what you want (output Postscript based on graphics commands on a canvas), but for AWT. Using that code as a reference it should be straightforward, if a bit tedious, to create a similar implementation for a SWT GC. I have no time right now or I'd do it. So I did the next best thing and documented it so someone else can do it. Good luck.
David, thank you for the documentation. But just like you we don't have time to implement it in time for Eclipse 3.0.
It is no longer a big issue since printing using external tools works perfectly. (most people under linux can install a2ps to print java code, or text files). It would be great to add a note about it on the GTK release notes. Printing diagrams with GEF related plugins remains a problem.
Believe me, Felipe, I can appreciate not having enough time to do it yet. :-) Actually, I was hoping someone else in the open source community would step forward and do it. Like I said, I don't think it would be that hard.... ;-)
The original problem with generating postscript was that we decided that SWT was not in the business of writing yet another postscript-generation package. We have some "generate-postscript-from-SWT-drawing-calls" code that was written a long time ago by a student. I can probably find it somewhere. At the time, it looked like XPrint was the correct way for SWT to go, however time has shown that XPrint is not well supported. So clearly, we either have to help support XPrint, or generate postscript. Or find a correctly-licensed postscript generating package that we can include in eclipse. None of which we have time for in the 3.0 time frame. Thank-you to Jared for his external tools suggestion. I will make sure that it gets into the SWT FAQ and the GTK release notes.
I'm confused and frustrated. Are you saying that the opinion of the SWT team is *still* that you're not in the business of maintaining a SWT to Postscript library--even though this is the platform-native way to print on Unixes? If that is the case, can you *at least* reply to the lengthy comments that I posted above about why I believe that this is the best choice for SWT? If this is not the case, and you have been convinced that generating Postscript is probably the best way to go on Unixes, please make this clear. I just spent an hour locating PSGr (the most widely-used AWT-to-Postscript library for Java) since it's no longer available at Sandia National Labs where it was written and then looking at the code to see what it would take to do a rewrite for SWT. If the SWT team isn't going to support this effort then I'm wasting my time. <frustrated>Please at least be clear about what you will support!</frustrated> :-}
Sorry, I thought I was clear. The answer is that we haven't decided yet. Someone needs to take the time to do the research, and there just hasn't been time for that in this round. Your arguments are very convincing, and my guess is that we will find that there are simply too many XPrint issues. If that is indeed the case, we will look at using a postscript-generation package. But the license will be very key. We would have to (a) like the package and believe that it will work for us, and (b) get a lawyer to read their license and allow its use in our code. Obviously an AWT package won't work unless it's rewritten. But even rewriting code is considered to be "using" it, and it is imperative that we do not introduce any "viral" licensing issues/problems into SWT (and hence, into all of eclipse). This is very very very important, and I urge you to read the PSGr license very very carefully before continuing along that path. (I haven't read it - it might be ok. The bottom line is that anyone who uses the source must not be forced to provide their source to their customers, and they must not be forced to give their product away free). If you are certain that the license will not be a problem, then I encourage you to submit a trail implementation of the SWT printing API on a PSGr rewrite. You can submit it to this bug report, or to the SWT newsgroup, or to the SWT mailing list. Your time so far has not been wasted - you have our attention <g>. I cannot promise more than that at this time, and I am very sorry for that. I *can* promise that if you submit a sample implementation, we will take it seriously. (And if you submit a complete implementation, we will take it very seriously <g>). Please see the FAQ section of this link for more info on the licensing issues: http://www.eclipse.org/legal/main.html I can't stress that enough.
Okay; thanks for the clarification.
The mistake of using a own home grown postscript generator should be avoided. Take a look at OO and esp. Mozilla. Lots of problems, many bugs, poor print quality and a huge amount of code will make it a painfull full time job to get such a code working and maintained. Just think about font handling (TTF/OTF fonts, CID subsetting), Postscript level versions (not all printers support Type42 fonts and Unix/VMS systems do not have ghostscript installed by default), incompatibilites and printer firmware bugs. And you would have to support at least CUPS. And then LPRng (because CUPS-haters will demand on it). And then all the seperate platform specific spoolers on AIX, HPUX, Solaris, VMS etc. There are no APIs available which will handle the details for you, except gnome-print and XPrint (I am thinking here about the version from http://xprint.mozdev.org/ or those available on Solaris/HPUX). gnome-print may be an option if you do not want to care about memory/resource usage, an extra API layer to wrap all GdkGC calls (and seperate refcounts/objects), a dependicy on lots of gnome libraries and incompatibilities to non-CUPS spooler systems. The remaining option would be XPrint. The version from xprint.mozdev.org solves the problems listed above in a quite simple and clean manner. What about trying to consult the mailinglist [http://xprint.mozdev.org/list.html] and ask for help?
Carolyn MacLeod: > and my guess > is that we will find that there are simply too many XPrint issues Can you summarize the issues you are thinking about, please?
David, although you think using Xprint is a simple and clean solution I can not see how it could be implement. Actually, we consider the possibility long ago (see comments #3 adn #4). The print implementation on motif open a Display and create a Drawable window on it. With this elemtents we can create a XGC anytime. But to create a GdkGC we need a GdkDrawable and I don't know how to come from a Display and a Drawable (X elements) to a GdkDrawable.
(changed summary to make searching for "linux print" turn up this report)
*** Bug 48107 has been marked as a duplicate of this bug. ***
> Thank-you to Jared for his external tools suggestion. > I will make sure that it gets into the SWT FAQ and the GTK release notes. Could someone maybe post here how the "external tool" or plugin workaround works ? There is no single word about printing in the GTK readme file, and its realy annoying to be unable to print under linux. I think its very sad that eclipse under windows can print but not under linux. An open source, freeware project like eclipse should not have better M$ support then linux support imo. Thanks though and sorry for posting here.
Sorry - I added the following link to the SWT FAQ but forgot to mention it in this bug report. http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt- home/faq.html#printOnX I asked the owner of the GTk readme to update it, but I guess it wasn't done. I will try to find the master copy and paste the link there.
OK. I looked for a GTk "readme" or "release notes" among the files owned by the SWT team, and I didn't find any. (This is undoubtably why the Gtk implementation owner couldn't update it for me). The only thing I can find that is even close is a file called "about.html" containing License, Binding, and Contribution info. This is not the place to put the "how to print" info. So I looked at the bigger picture - eclipse itself - and I see that there is an eclipse/readme/readme_eclipse.html that contains release notes. My best guess is that this is what you mean. At the top of this file is a notice that reads: "Last revised May 22, 2003 [These release notes have yet to be updated for the 3.0 development stream. What follows are the 2.1.0 release notes.]" So I suspect that even if I could figure out who owns this file, it is probably "frozen" until the 3.0 release. I realize that that is not a very helpful thing for me to say. I hope that for now, the SWT FAQ is helpful for you.
*** Bug 53367 has been marked as a duplicate of this bug. ***
One can find my (humble) overall feeling about the "Is un*x/gtk a supported platform ?" issue in a message I just post to the eclipse.platform.swt newsgroup. This comment is only about proposing a technical solution for the this topic. I understand the SWT developers (according to Veronika Irvine) who stand : we want a solution that supports the nice pattern we choose, that is printing must be addressed the same way graphic windows are, by drawing to a graphic context (GC) object representing a device. [supplementary support, page handling for example, being the responsability of the Printer object, but everyone agree this is not the tricky part] But I disagree with the assertion which stands that this pattern implementation for the GTK port MUST directly relies upon a corresponding GTK native object. Comment #17 From Felipe Heidrich : but we prefer to have a GTK solution for printing. If GTK doesn't not have support for printing we are afraid that there will be no print support for SWT-GTK port. This oriented this thread to look strictly at the native side, including solutions that involve gnome-print and/or gimp-print. Less or more direct postscript generation has also been introduced. Several times David J. Orme post very constructive comments and ideas. But it seems now the situation is frozen to the (ridiculous regarding a "supported platform") external-tool/plugin workarounds. I would like to propose a solution that could get some consensus. And actually contribute a usable implementation for it. As details bellow will show, this would obviously involve some support from the SWT team. What do we want ? A complete port of the SWT printing API for the GTK platform. For a user point of view, this means : - be able to print source code from the editor view in the Eclipse workbench. - be able to print diagrams from some GEF based plugins (for exemple UML tools) - in one word : be able to print on gtk whenever the print command is available on windows Constraints : - Respect the paradigm : "we print by drawing to the SWT graphic context" - Do not include neither an internal postscript generation package to SWT, nor add another supplementary dependency (gnome/gimp-print library, an external postscript generation package) to SWT Given : + The JAVA Grahics2D object implements all the drawXXX we find in the SWT GC class + The JAVA Printing API (and JPS) reference implementation on the un*x platforms provides streaming (to a file or a printer) a postscript representation of a Graphics2D + As dealing with postscript is the natural way of printing on the un*x platforms, we can assume even a non postscript printer will flawlessly work on any un*x box (this worked just fine on my linux box) AFAIK, the SWT printing API usage may be described as : // init (swt) printer and gc printer= new Printer(..); GC gc= new GC(printer,...); // print an N pages doc : iter N times printer.startPage(); gc.drawXXX(...); printer.endPage(); // release printer gc.release(); printer.release(); so there are two jobs : - patch the GC implementation to draw on an embedded Graphics2D when initialized with a printer SWT device as in "new GC(printer)" - patch the Printer implementation to use JPS to print/stream the previous Graphics2D object This solution involves no external library (just uses some new features of the JRE 1.3 and 1.4), and is intended to pass the assumed constraints. What we would prefer to know _before_ we start code, and that may need some help/support from the SWT core developers, relates to the GC/Printer objects we introduce having no native GTK peer. Though this peer is not involved in the printing process itself, this may lead to SWT encountering some inconsistent situations I can't figure out. For example, I do not know how to deal with the int handle property of the Printer device. I'm in doubt about returning a value that may confuse some SWT internal registry. Other calls that cause me troubles, for the same reason, are : int internal_new_GC(GCData data) void internal_dispose_GC(int handle, GCData data) Please, Veronika, Felipe, 1) don't say us that an implementation of the "print via drawing to a GC" pattern that does not rely upon any GTK native peer will hurt you _per_se_ 2) don't object we didn't plan on how to integrate the page/printer setup windows ; JAVA printing API should again provide a good start for this (still having no GTK peer for them I admit), though I didn't investigate deeper on this point ; but imho being able to print on the default printer using default paper size is better that not being able to print at all. 3) say us you may accept to give some help/support in dealing with this internal/handle issues that trouble me, and that certainly require a deeper knowledge of SWT than I have (and that may take me a lot of time to learn just by reading the source code) Finally, though testing the implementation via an autonomous SWT application like the snippet above is the way to go, it would be rewarding to be able to test the consequences on the Eclipse IDE behavior. For this I need to know how to (globally?) enable the print feature for the gtk port, which I didn't find yet. For example, is anyone aware of the place (in the code or properties files) where the print command is disabled for the gtk port of the Eclipse IDE workbench ? I hope this post will help in solving an issue for which the current status may not please un*x users, who aren't so few I want to believe. I'm sure if we demonstrate a solution that works, while not offensing the overall design, the GTK port of SWT will one day support printing. Best regards, duf.
I can answer one of your questions. Printing is enabled or disabled in the IDE right in the SWT printing implementation itself. Look at the implementation of Printer.getPrinterList(). If this returns null, or an empty array of PrinterData, then the IDE disables the Print... menu item.
Regarding comment #53, I would fully support this solution.
Created attachment 9621 [details] Postscript output produced by a SWT Print snippet (GTK port)
My original Comment #53 post was a bit more rude than the intent ; and I sincerely apologize to anyone who felt it offending. But since this, I did some coding as a proof of concept step, and found this very encouraging, though I agree we'd have to deal with a few not so obvious issues. Here's the feedback. As this proposition relies upon the JAVA2 Printing API (and may be upon JPS), I'll start with a few words on its overall usage pattern, for those who don't have it in mind. This API sounded me a candidate for our topic as it also involves a "print (postscript) via drawing to some graphic context (GC)" paradigm. I will abbreviate package names, actual ones being under (all available with JAVA SDK 1.3/1.4) : - java.awt.print - javax.print [note: though the API is obviously designed to support any MIME types and/or formatting, using postscript is by far the safest way on any un*x platform] Basically, you print via setting up an awt.Printable, that is overriding a print method as : public void print(java.awt.Graphics g, PageFormat pageFormat, int pageIndex) { // all the g.setXXX() and g.drawXXX() here } This is called by the print api when the job is sent to the selected print service. This means it's this api reference implementation that will "prepare" a graphic context (actually a Graphics2D object) that represent the target print device. This is the root for the main constraint : after a swt.GC gc= new GC(new swt.Printer()) call, all subsequent requests to the swt GC must be delegated to an abstract GC that stack them (as we dont't have any real gtk device for this), in order to be able to replay (the awt equivalent for) these requests against the awt.Graphics, when it will come to actually print. For this I investigate three ways : A) setting up an awt.Component comp_to_print and perform the job via 1) comp.to_print.getGraphics().drawXXX() while stacking 2) comp.to_print.paint(gc) for the actual print job this implies having an _active_ AWT/Swing container to get a non null comp.to_print.getGraphics(), which imho we can't stand with : constraining a SWT application to instantiate AWT/Swing windows when it comes to print will immediately/soon be a mess. I'm not sure it's even possible. B) using an AWT BufferedImage img via : 1) img.getGraphics().drawXXX() while stacking 2) gc.drawImage(img) for the actual print job this sounds better as it seems to represent less work to get the feature done, but introduces significant issues: - I found both through personal experience and through web resources (forums and bug databases) that (1.3 and 1.4) SUN reference implementations had a few bugs and issues regarding streaming to postscript the results of some gc.drawImage() calls. - you loose all features of producing vectorial postscript, and get all drawbacks of using rasters; particulary, text scaling produces awful output. C) using the command pattern - commands.add(new GCCommand()) when stacking, GCCommand having DrawText, DrawLine, DrawRectangle, and so on, subclasses - iter on commands.elementAt(k).process(gc) for actual print this involves more work but sounds cleaner I think (and experienced) options A and B are unusable. The options C) gave me interesting results. This way I get the SWT Print API snippet [http://dev.eclipse.org/viewcvs/index.cgi/platform-swt-home/snippits/snippet132.html] to work fine on my linux/gtk port ; I created an attachment with generated postscript file, so you can compare with windoz output (which I can't do). I also extend the snippet (as to my 2nd attachment) to check the behavior with a multi pages print job. and that's fine to. [note: I finally choose to print to postscript files, and to stream one A4 page per (numbered) file, for easier testing reasons, but targeting a real non postscript printer works exactly the same, and this is not only possible on a un*x box] Though I had implemented less that 1/4 of the gc.drawXXX (and gc.getXXX) calls in my abstract GC facade (and the corresponding commands), I wanted to get an idea about the consequences upon the eclipse IDE. Thus, I recompile the required stuff to use these modified (and new) classes, and tried to print a (text) file from the workbench text editor (thanx to Carolyn who said me it was just so straightforward) ... well, eclipse does not crash, but the output files, though correct postscript files, appear just as blank pages ;-( from what I see in the log, this is due to most of the drawXXX calls to the SWT gc doesn't appear within a start/end page sequence (I use this sequence to sync the commands stack). as I didn't do much testing with this, and haven't yet dive into the SWT StyledText stuff, I have no precise clue about what really happens, even not enough ideas to request precise help on this. I think we thus have a few area : - the facade + command related design pattern : it's the most usable I get, but if anyone is aware of an easier way, welcome ;-) - scaling/clipping/coordinate/fonts/color/metrics issues : I intent to use the actual awt print device properties to provide all these swt.GC.getXXX() calls based upon their awt.Graphics2D printer device equivalent. so far, I think it's not obvious, but doable - internal GTK (gdk) handles : the way I use (and not use) them does not currently crash the soft, neither throw any exception, but I'm sure there are (currently) hidden consequences(*). I would greatly appreciate any pointer to technical notes introducing to the swt/gtk mapping (notably about the context, data, and handle concepts). (*) this is also somewhat involved with failing to correctly print the text editor content, but as I said, I don't know much about this now - investigating about swt StyledText stuff, in order to get working the integration with the eclipse IDE workbench. we have source code and documented API. I hope I'll soon have more details about this. - as it should be easy to get this working on any platform (for example using a ghostscript driver as the printer), may we design it in order to integrate other ports of SWT ? My plans are to polish a bit my (very starting-point) code, to a somewhat clean and easy-to-read-design form, and make it available here as an attachment. This would make possible for interested peoples to help me debug/fix/extend/refactor to quickly see if it may be a viable solution or not. Particulary I hope this will help the eclipse/swt guys to point out how we should deal with internal handles (for example, they may tell us an unused range, but that's surely not a cents of what we need to know). There are certainly many points I miss, due to my low level knowledge regarding both SWT and GTK, and any comment or suggestion may improve my understanding of the overall. Best regards, duf.
Created attachment 9622 [details] SWT snippet patched to involve printing multi page documents
Christophe, unfortunately I won't be able to look at your code right now. Printing support for GTK is not in the Eclipse 3.0 plan and we (eclipse- developers) have only two weeks for code freeze and I'm very busy with other stuff. I'm sorry but I will only be able to look at your code after Eclipse 3.0. Car, would you have some time available (note: IMO, implementing GTK printing would take at least two weeks (working fast))?
Created attachment 9687 [details] Archive that contains source files and ps exemples for SWT/GTK Print Files that relate to Comment #57. Obsoletes attachments #56 and #58. examples: * ./out.ps (output produced by Snippet1.java) * ./single-snipper.ps and /multi-snipper.ps (output produced by Snippet2.java) java source files: * org/eclipse/swt/graphics and org/eclipse/swt/printing
I didn't have so much time to spend on this topic these last times, but here are the changes (regarding Comment #60) : 1) better page geometry handling : seems near good 2 better font metrics handling : seems near good, but vertical measure appears bugy when running the word wrap snippet 3) source code is now very easy to read and understand (imho), and the Printer API documentation is updated to point out GTK port specific behaviors when needed 4) i can confirm that printing via a StyleText widget works as well as the snippets, that is less or more well depending on the exact content. But it's still impossible to print from an Eclipse IDE workbench text editor : does it actualy rely upon a StyledText widget ?-) To encourage feedback (ideas about Workbench/StyledText or geometry issues) and contributions (features as drawXXX), without overloading this thread, i invite volunteers or interested peoples to visit the (temporary) URL : http://perso.wanadoo.fr/openborges/opensource.html#GTKPrinting There you will find latest status about this try, and the related sources and binary downloads. Felipe (and others), I know you're still working hard on the 3.0 final release, and won't bore you more. but if you can have a read ;-) best regards, duf.
this week-end I had some time for a more serious debug session, and found that my tests were actualy based upon a simple text widget and _not_ a StyledText, which confused me. to be short, I didn't get that pango layout work was done directly _inside_ the StyledText (and related) objects, and did not rely "only" upon the GC implementation. so I have re-implemented the handling of layout, styles (colors, fonts) and tab expantion for the case of printing (ie. when there is no gtk device to do the equivalent pango on) in the StyledText stuff. given this, and bug fixes regarding styles and geometry, integration with workbench editors now works fine (you can print styled cleanly formatted source code from Eclipse). I'm now running Eclipse dayly with this patched swt.jar, to see if my stuff may reveal side effects (it surely will, since the GC class is somewhat largely modified). I particulary worry about memory leaks. I will try to make the source code (as a patch against the current CVS stream) and detailed status available this week (see URL in #Comment 61). interested end-users/testers may also feel free to request me for a binary build (a patched swt.jar). I hope blocking issues are now behind us, and that remaining work to a public usable implementation is just adding the (numerous) missing drawXXX calls. best regards, duf.
The work was stalling for now a couple of month, and no material was available. I just put a release online. you can check current status (and download sources and binaries, if you want to have a deeper look) at : http://www.openborges.org/dev/swt-gtk-printing (this URL updates and replaces the one in #comment 61) regards, duf.
i've been reported the url does not show on some releases of IE. this should now be fixed for any xhtml enabled browser. i apologize for any disappointment. regards, duf.
Gtk 2.8 plan includes printing: http://www.gtk.org/plan/2.8/ Does anyone know anything about it ?
Yes, one thing. It's an eternity away... :-( "The timeframe for the 2.8 release is mid 2005." (which really means 2.8 will be available in the widespread Linux distributions in the late 2005)
*** Bug 77695 has been marked as a duplicate of this bug. ***
*** Bug 80683 has been marked as a duplicate of this bug. ***
*** Bug 95995 has been marked as a duplicate of this bug. ***
GTK 2.8.0 has been released: http://mail.gnome.org/archives/gnome-announce-list/2005-August/msg00054.html Can this issue finally be solved ?
Printing was dropped from the GTK+ 2.8 plan a while back due to the cairo work. It's on Owen's list for 2.10 though, see yesterday's development meeting notes: http://www.gtk.org/plan/meetings/20050816.txt We might be able to do something using the cairo code done for the advanced graphics API: maybe there's a half-way solution since the GTK+ solution will involve cairo.
i can't really understand why nobody cares to implement at least a temporary solution to enable linux/gtk users to print! it's nearly 3 years now the issue initially was posted and all we get is "still not in gtk" because of the gtk-guys having completely different priorities than users of eclipse (boy, i wish somebody ports eclipse to qt -- it would look far better than ugly gtk ;-). chosing the gtk-filechoser was definitively no good choice and gtk-printing may be even worse -- so please somebody implement a temporary solution (no, external tools are no solution)
I agree 100% with the latest comment: - It's incredible that a product today can reach version 3.1 without (even a simple) printing solution - A QT-based eclipse would rock so much more than the current GTK version - The GTK file chooser is horrible, if doesn't even let you step into dot-directories...
I don't know why they want to do printing via the GUI interface at all. Personally, I find a print out of the representation of a file in a GUI editor to be fairly awful. What I would like the print function to do is just sent the text file that's in the editor buffer off to cups to be printed like any other text file.
I probably misworded my last comment. I meant that I don't see why GTK should be involved in printing the file.
I fully agree with the lates comments. It is bad for us (developers) that eclipse misses printing support on linux. But it is more worse for application vendors building their applications on top of eclipse without that standard feature. The only reason why printing still isn't supported can be that to less people use eclipse on different systems than windows. Just think about how long this bug report exists and it's status is still NEW. The root of all evil is this damn SWT !!! Swing has much more features, it is almost platform independent and has at least a clear design. It is absurd that you must cope with platform problems in your platform indipendent (Java) application.
I agree that we should not be so focus on having printing linked to GTK. There is also a Motif version of Eclispe that runs very well and that too is NOT printing. So what gives? There is no support for printing in Linux (period) So... can we have some kind of simple hook to CUPS?? It would be simple JFace Dialog that would have as it model some object(s) representing the CUPS system hooks. Now... I can figure out the GUI part and if someone wants to figure out the CUPS hook part then I am more than willing to pair up and do it. We can provide this solution as a separate plugin until whatever happens here happens but at least we can print.
(In reply to comment #77) > I agree that we should not be so focus on having printing linked to GTK. There > is also a Motif version of Eclispe that runs very well and that too is NOT > printing. So what gives? There is no support for printing in Linux (period) > > So... can we have some kind of simple hook to CUPS?? > > It would be simple JFace Dialog that would have as it model some object(s) > representing the CUPS system hooks. Now... I can figure out the GUI part and if > someone wants to figure out the CUPS hook part then I am more than willing to > pair up and do it. We can provide this solution as a separate plugin until > whatever happens here happens but at least we can print. We could probrably use the JavaTM Print Service.
This missing feature should be mentioned in the README.
*** Bug 107715 has been marked as a duplicate of this bug. ***
>There is also a Motif version of Eclispe that runs very well and that >too is NOT printing. Printing is implemented for Motif using XPrint.
Really, if GTK does not support printing, neither does SWT. I realize that this is a big problem, but you'll need to take it up with the GTK folks. GTK C programs can't print either. I'm very sorry about this but there's not much I can do.
well, it's a couple of years now gtk does not provide printing capabilities. so waiting for gtk to implement a crucial feature like printing was a bad bet. i think we have to accept that the gtk guys do not care for others using their toolkit -- and to have an other solution than gtk may provide in a far, far future (mr spock? any informations about gtk implementing printing in your time?). eclipse definitively _needs_ a solution to print on it's own. it's in no way acceptable that (as someone said before) eclipse reached version 3.1 without ability to print for a major platform. as a conversion to better equipped toolkits is no option (despite of heavely improving the look of eclipse compared to ugly gtk ...) there has to be a printing solution independent of gtk. btw (and very important to me): does "if GTK does not support printing, neither does SWT" mean, _no_ (literally _no_) gtlk-based swt-application will print? i consider switching a project to swt -- but if printing is impossible, it's completely meaningless and makes swt rather a joke than a useful tollkit ...
GTK was originally designed for THE GIMP, which is cross platform application with perfect printing support. I know a lot of applications using GTK which are able to print. If I want print something with Eclipse (I use GNU/Linux with GNOME and Eclipse GTK Port) I have to copy and paste it first into an editor (if you want have something to lough about: yes, it is a GTK editor). Thats not good and this is really a bug, not a missing feature only. It should be resolved by yesterday! Thats what I have to say. Marcus
Arne, there is no need to be negative and insulting. If printing on Linux is a critical feature for your application, then you'll need to use a graphics library that supports it. For example, since you are a Java programmer, you could use SWT for Motif or Swing/Java2D. If you were a C programmer, you would not choose GTK (unless you were willing to wait for GTK to implement printing). Here is our mandate: "SWT is a widget toolkit for Java designed to provide efficient, portable access to the user-interface facilities of the operating systems on which it is implemented." Marcus, this is just TTY printing, right?
I haven't said anything since originally posting this bug. I can sense some frustration building in the emails and will admit I feel a bit of it myself. I don't know anything about GTK or SWT (I build webapps for Tomcat with Eclipse), but I just did a quick google and found some things. First, a search for "gtk printing" (http://www.google.com/search?hl=en&q=gtk+printing) shows this bug at about the 4th hit. Boy, we're popular ;) Second, there seems to be a package for printing on gtk (http://gtklp.sourceforge.net/). I don't know if anyone has looked into it. Third, just to do a comparison for java GUI toolkits. I googled "java swing printing" and got this (http://java.sun.com/developer/technicalArticles/Printing/SwingPrinting/). It says Swing has facilities for printing since 1999. I have to ask why SWT hasn't done the same? Finally, I appreciate the very large effort IBM (and other developers) have put into Eclipse and I understand that priorties have to be made. I want to thank them for the work they have done. I hope that the folks working on Eclipse won't drop this issue. Rather, I would hope that Steve's comment (posted earlier today): "Really, if GTK does not support printing, neither does SWT. I realize that this is a big problem, but you'll need to take it up with the GTK folks. GTK C programs can't print either. I'm very sorry about this but there's not much I can do." isn't the last word. Printing in Eclipse on Linux is a big issue to many folks, and could be a PR nightmare in more ways than just for Eclipse.
there was not intention to be "negative and insulting"! i'm still shocked by the fact, that printing has so low priority -- and as the whole thread shows i'm not the only one. there is still no serious proposal how to solve this -- but only shrugging and refering to a years old problem of gtk. if you interpret that as "negative and insulting", well, i can't help.
(In reply to comment #85) > Marcus, this is just TTY printing, right? I don't know, but I think so that my GTK editor does it this way. But take a look at GIMP -- it is based on GTK and has perfect print capabilities (on Windows _and_ on Linux). But since I'm not a C programmer and use GIMP only for my digital photos I don't know how they realized that. Marcus
A word on printing in Gimp. My understanding is that printing in Gimp is provided by a third-party plugin (Gimp-Print). Gimp itself doesn't have printing support (because GTK doesn't have it?). The Gimp-Print Sourceforge page describes the project as "A very high quality package of printer drivers for Ghostscript and CUPS. This project also maintains the Print plug-in for the Gimp from the same code base" http://gimp-print.sourceforge.net/
There is a fair bit of confusion in the last batch of comments. Some brief clarifications: - If you just want to print the file in the Eclipse editor, use Run > External Tools, add a Print program set to /usr/bin/lpr, and in the arguments use ${container_loc}/${resource_name}. You can then use the External Tools run icon in the toolbar to print in Eclipse. This bug report is about printing complex documents (editors with syntax colouring, graphical editors, etc) which requires a full drawing API. - gimp-print is a gimp plug-in for printing images in gimp. It does not print text or 2D shapes required by SWT. - CUPS is a backend for finding printers and printing files. This would be useful for creating a print dialog, but does not provide a drawing API. - XPrint keeps coming up, but it is not compatible with GTK+, especially for printing text (which is rather important): http://www.redhat.com/archives/fedora-devel-list/2004-September/msg01132.html I think there are three options: 1. libgnomeprint, discussed in comment #15. This is used by many GNOME applications, but does not match the GDK drawing API, and so the implementation is not straightforward. This will also be deprecated when GTK+ implements printing. 2. Write a PostScript output backend for GC and use the print dialog from libgnomeprint. 3. Wait for GTK+ to provide a print dialog and use cairo for drawing. Option 1 is painful, but may be worth it until GTK+ has a replacement. libgnomeprint was not always stable, but is unlikely to break now. It is unfortunate that this does not match the long-term goal for GTK+ apps. http://mail.gnome.org/archives/desktop-devel-list/2004-November/msg00716.html Option 2 is painful: SWT would end up duplicating the code in libgnomeprint or cairo, and dealing with printing pango fonts is difficult. See comment #44 for more reasons. Option 3 is obviously best. SWT has the cairo code, and only needs cairo to finish the PostScript backend and GTK+ to include a standard print dialog. This is on the GTK+ schedule, and is intended to replace libgnomeprint.
Billy, your comment seems to make a lot of sense, but leaves one question (at least for me): Why isn't Swing printing a 4th option? While I appreciate the desire to reimplement every Swing bit in SWT, Swing is already bundled with every JDK, so utilizing it for printing might be an easy short-term solution. Or am I completely missing something?
What rubbish. Lot's of GTK programs can print. They just don't do it via GTK. As I said before printing through the graphics interface is not the only way to do it and for text files is probably not the best way to do it. What's wrong with the tried and true method of sending the text file to the printing system and letting the priniting system take care of the details?
Peter -- see the first point in my last post. You can print just fine using lpr in Eclipse, and I describe how. If that's all you want it already works fine. If you want Eclipse to use lpr for the print button, please file a new enhancement request against Platform > UI. This bug is tracking the SWT Printer implementation under GTK+.
(In reply to comment #90) > - If you just want to print the file in the Eclipse editor, use > Run > External Tools, add a Print program set to /usr/bin/lpr, and in the > arguments use ${container_loc}/${resource_name}. You can then use > the External Tools run icon in the toolbar to print in Eclipse. Good morning! Thanks a lot for this tip - I used gtklp instead of lpr. gtklp displays a graphical print dialog where a lot of things can be donce (numbers of copies, sorting, 2 and more pages on one, selecting the printer etc). I'm happy now with this solution! Have a nice day Marcus
it's annoying and appalling to see how ignorant these crucial issue is handled! still the same old, stupid idea of "external tools" -- probably posed by people using eclipse under windows and thus never proving the stupidity of that proposal! of all supported platforms windows is the only one with a proprietary solution for printing -- platforms providing an open printing startegy are disdainful ignored. stop the meaningless waiting for a solution provided by the gtk-guys -- as long as the spend more time to produce unusable file-dialogs i wont exoect them to spend time to work on things not really necessary for gnome. all platforms except windows provide support for postscript natively, and all platforms except windows print postscript natively. a lot of applications utilize a printing strategy consisting of a) recieving postscript and b) sen ding the postscript to a printer/program/whatsoever specified by the user. mozilla does, firefox does, opera does, openoffice does -- a solution not patronizing the user works well for a world of software -- but is inacceptable to eclipse? as swt needs platform-dependent libraries already and printing is implemented only for a few supported platforms there should be no hinder to implement for platforms other than windows (and macos maybe) a solution creating postscript on print request and send it to a printer/ program specified by the user in certain preferences page. it's a solution platform and toolkit agnostic and used widely in a notably part of the world -- and thus working well. eclipse does not need to reinvent the wheel!
Cairo 1.0.2 has been released a month ago. "Currently supported output targets include the X Window System, win32, and image buffers. Experimental backends include OpenGL (through glitz), Quartz, XCB, PostScript and PDF file output." The PostScript output seems to be usable. What are the cairo (or updated gtk libraries) integration plans for eclipse?
SWT's GC has a back-end for cairo in 3.1. It is updated to the cairo 1.0 API in SWT 3.2, and the GTK+ team is working on the print dialog for GTK+ 2.10. See comment #90.
I'm shocked to find that Eclipse won't print under Linux. "If you want Eclipse to use lpr for the print button, please file a new enhancement request against Platform > UI." Did this ever happen ? "This bug is tracking the SWT Printer implementation under GTK+." Why is the focus of this discussion limited to such a narrow solution ? Other GTK apps didn't wait. I vote for a CUPS system. What are the downsides to that ? Doesn't kwrite use a CUPS implementation and doesn't it work OK ?
Created attachment 30663 [details] Image of how I set up kwrite to do printing My work around for this issue is to set kwrite up as an external tool print engine. See attachment. It works well.
well, even kwrite will print formatted text only. this is achieved by that stupid "external tools"-solution too. but it's simply unbearable to be unable to prinbt other things than plain text. i would like f ex to print uml-diagrams, "screenshots" fr4om the ve and much more. hopefully, now cairo exists, the guys will fix this grave bug (but i'm still very sceptically -- they did not care to fix it all the years, why should they now)
I have a create deal of respect for the work that christophe has put into his solution. (see comment 63 and several previous) However, I'd like to point out for the record that SWT peering to Swing for printing is simply out of the question for a long term solution in the main SWT trunk. I'm not saying that Christophe doesn't have a great hack to fix for individual applications, or even a patched SWT that can be used in Eclipse. What I am saying is that the actual SWT implementation can't peer to Swing. It would break every application that uses gcj for native compilation and uses SWT only because the native libs can be redistributed. A lot of people are depending on SWT's independance from Swing. Once you start tying the two together, you open the door to a world of pain (not to mention a PR nightmare from *both* the Swing bashers and the SWT bashers). I realize this is a rather important issue which has been somewhat put off by the SWT team (with good reason). I think that they've made it fairly clear as to how they want to procede (wait for GTK printing support). If you guys really want this to make it into the SWT main jar, start jumping on the GTK team and flood their bugzilla. I'm fairly certain that as soon as GTK starts offering printing support, it will be included in the next release of Eclipse GTK.
Does an enhancement request in gnome's bugzilla exist? I can't find an entry for the missing printing dialog / printing opportunity in gtk.
I did not find one either, so I created one: http://bugzilla.gnome.org/show_bug.cgi?id=327605 I hope this helps communication. (And BTW: Please stop being demanding, try to help gtk if you care)
I can only note that the Plans for SWT 3.2 does not list "Printing on Linux" as an item. Is it at all on the radar? Windows XP skinning and other eye-candy seems more important. I am not an Eclipse fan in general (but now in need of the very interesting projects EMF/GEF/GMF), and this issue makes me laugh. A two-dollar company that doesn't provide printing in the most silly applications can be waved away, but this is possibly one of the largest accumulated Java efforts in the world. And all depending on a SWT flaw of massive scale. well, well... GTK is listing printing to "possibly" be included in the 2.10 release, targeted for May 2006. Does that mean I can have it for Christmas? Which year?
One more comment; Shouldn't the obvious solution be to generate PDF or PS output instead?? How it gets to the printer is less of a concern, isn't it.
Niclas, please make the necessary modifications to both GTK and/or SWT and submit the patches.
Niclas - read the comments above to see why this issue, though very annoying and a blocker for many people, can't really be fixed by SWT. In other words, the fix is basically postponed until the GTK team adds printing support. Vote on the bug there (I don't have a URL handy) to give them a kick in the pants. That's about all we can do (other than write the GTK support as a patch and submit it).
It seems there is some active development for GTK in th recent weeks. http://www.0xdeadbeef.com/?p=161 http://blogs.gnome.org/view/alexl/2006/01/27/0 http://blogs.gnome.org/view/alexl/2006/02/03/0 It's funny to see that this happen after Mathis filed the gnome bug report. Maybe just a coincidence, maybe not.
More good news. Printing support has landed in GTK's CVS HEAD. http://blogs.gnome.org/view/alexl/2006/04/21/0
That's great news! Can we expect this to be integrated into SWT in 4.0?
We'll work to get it on the plan for the next release.
(In reply to comment #111) > We'll work to get it on the plan for the next release. > Does that mean 3.2;-)?
Taking ownership. No, it will not be in 3.2... ;) Here's what I have done so far this afternoon to get eclipse up and running on the latest gtk (note: NOT from CVS... I just took the latest snapshots): # as root... cd /usr/local/src/ wget http://ftp.acc.umu.se/pub/gnome/sources/glib/2.11/glib-2.11.1.tar.gz wget http://cairographics.org/snapshots/cairo-1.1.6.tar.gz wget http://ftp.acc.umu.se/pub/gnome/sources/pango/1.13/pango-1.13.1.tar.gz wget http://ftp.acc.umu.se/pub/gnome/sources/atk/1.11/atk-1.11.4.tar.gz wget http://ftp.gnome.org/pub/gnome/sources/gtk+/2.9/gtk+-2.9.0.tar.gz tar xvfz glib-2.11.1.tar.gz tar xvfz cairo-1.1.6.tar.gz tar xvfz pango-1.13.1.tar.gz tar xvfz atk-1.11.4.tar.gz tar xvfz gtk+-2.9.0.tar.gz cd glib-2.11.1 ./configure --prefix=/usr/local/gtk-2.9.0/ --enable-debug=yes make make install export PKG_CONFIG_PATH=/usr/local/gtk-2.9.0/lib/pkgconfig/ export LD_LIBRARY_PATH=/usr/local/gtk-2.9.0/lib/ cd ../cairo-1.1.6 ./configure --prefix=/usr/local/gtk-2.9.0/ --enable-debug=yes --enable-pdf=yes --enable-ps=yes make make install cd ../pango-1.13.1 ./configure --prefix=/usr/local/gtk-2.9.0/ --enable-debug=yes make make install cd ../atk-1.11.4 ./configure --prefix=/usr/local/gtk-2.9.0/ --enable-debug=yes make make install cd ../gtk+-2.9.0 ./configure --prefix=/usr/local/gtk-2.9.0/ --enable-debug=yes make make install ------------------------ Before starting eclipse, export the following: setenv LD_LIBRARY_PATH /usr/local/gtk-2.9.0/lib/ setenv GTK_PATH /usr/lib/gtk-2.0/2.4.0/ setenv GTK_DATA_PREFIX /usr/ setenv PKG_CONFIG_PATH /usr/local/gtk-2.9.0/lib/pkgconfig/ ------------------------ Now I am just starting to look at the API in file:///usr/local/gtk-2.9.0/share/gtk-doc/html/gtk/Printing.html Any examples of the intended use of the API are welcome, or if anyone spots any potential problems in the snapshot versions I downloaded, please let me know before I hit them! Thanks. :)
There will be a talk at GUADEC in June re: the GTK printing API... http://guadec.org/node/219
(In reply to comment #114) > There will be a talk at GUADEC in June re: the GTK printing API... > http://guadec.org/node/219 I'll be at GUADEC FWIW. I'm sure we could get Alex to comment on an API, though.
(In reply to comment #113) > or if anyone spots any > potential problems in the snapshot versions I downloaded, please let me know > before I hit them! Thanks. :) Just a FIY, I quote from the gtk+ weekly meeting that took place today: "mclasen - regarding printing, I hope we can land the last big missing pieces this week, or early next week"
Created attachment 41817 [details] Screen snap of print dialog I have a print dialog. I had to get the gtk+-2.9.1 snapshot that just went up today... guess I'm at the bleeding edge <g>. 2.9.1 is nice because it has a Printing demo in bin/gtk-demo. Thanks for the warning in comment 116, Ismael - I will keep it in mind.
Fixed > 20060717, and it will be in tomorrow's integration build. You need GTK+ 2.10 to run it. There are still a few problems, for which the following bugs have been opened: http://bugzilla.gnome.org/show_bug.cgi?id=339323 http://bugzilla.gnome.org/show_bug.cgi?id=344519 http://bugzilla.gnome.org/show_bug.cgi?id=345590 http://bugzilla.gnome.org/show_bug.cgi?id=346245 http://bugzilla.gnome.org/show_bug.cgi?id=346252 http://bugzilla.gnome.org/show_bug.cgi?id=346903 https://bugs.eclipse.org/bugs/show_bug.cgi?id=150870 https://bugs.eclipse.org/bugs/show_bug.cgi?id=150873 It was a pleasure to work with Matthias Clasen at RedHat, who owns the GTK+ printing code - he was very responsive. Thanks!
That's great to hear! Is there any Api I can use to check wether printing is supported? E.g. a method that tells me wether the user is on GTK+ 2.10 or an older GTK? Ben
(In reply to comment #119) There is not, the workbench uses Printer#getPrinterList() to determine if the printer button is enable or not, something like: printerButton.setEnable(Printer#getPrinterList() > 0);
Thanks for the info, that should do it for me as well :) Ben
*** Bug 154101 has been marked as a duplicate of this bug. ***
