Re: [Gimp-developer] Print plugin
Hi, On Mon, 2007-07-23 at 18:34 -0600, D. Stimits wrote: So I pose this question...if print via PDF is to be considered, why remove the existing PS system, which is pretty much the best quality PostScript among all of the apps (commercial and free)? We are not removing anything. So far GIMP didn't have a Print plug-in maintained in the GIMP source tree. We are now adding one based on GtkPrint as an option for the users who just want to get an image printed easily. You can still install the GIMP Print plug-in from the Gutenprint project if you need the features or the suberb print quality that it offers. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin
Hi, On Mon, Jul 23, 2007 at 07:35:17PM +0200, Sven Neumann wrote: If yes, a solution could be to not distinguish between a Postscript and a PDF target (i.e. to embed only opaque images into a PDF despite the fact that PDF can handle images with alpha values). Would this approach have any disadvantages? I think the current implementation of the print plugin is fine, i.e. generate the PDF with opaque images. If someone needs to have a PDF with images with alpha values, it would be possible to write a 'save-as-pdf plugin' similar to the print plugin that uses also gtk_print_* functionality. I think that even layers could be embedded into the PDF. I could (try to) write such a plugin. So, there the question remains whether someone would use this? Stefan ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin
Hi, On Tue, 2007-07-24 at 16:47 +0200, Stefan Roellin wrote: I think the current implementation of the print plugin is fine, i.e. generate the PDF with opaque images. If someone needs to have a PDF with images with alpha values, it would be possible to write a 'save-as-pdf plugin' similar to the print plugin that uses also gtk_print_* functionality. I think that even layers could be embedded into the PDF. I could (try to) write such a plugin. I wouldn't base this on GtkPrint but directly on Cairo. GtkPrint just adds funtionality to deal with printers, it wouldn't offer any advantage if you are just creating a PDF file. So, there the question remains whether someone would use this? Export to PDF has often been requested. It would be particularly interesting if it could contain text layers as PDF text elements. We are missing some additions to the PDB text API to make this possible. But the missing API could be added (after 2.4 of course). Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin
Hi, On Tue, Jul 24, 2007 at 07:29:20PM +0200, Sven Neumann wrote: I think the current implementation of the print plugin is fine, i.e. generate the PDF with opaque images. If someone needs to have a PDF with images with alpha values, it would be possible to write a 'save-as-pdf plugin' similar to the print plugin that uses also gtk_print_* functionality. I think that even layers could be embedded into the PDF. I could (try to) write such a plugin. I wouldn't base this on GtkPrint but directly on Cairo. GtkPrint just adds funtionality to deal with printers, it wouldn't offer any advantage if you are just creating a PDF file. Yes, this would of course also be possible and not too different from a GtkPrint approach. GtkPrint offers dialogs to choose the PageSize etc, which Cairo does not. Export to PDF has often been requested. It would be particularly interesting if it could contain text layers as PDF text elements. We are missing some additions to the PDB text API to make this possible. But the missing API could be added (after 2.4 of course). Ok, I will try to implement a plugin based on Cairo, but this will take some time... Stefan ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin
On 7/25/07, Stefan Roellin wrote: Yes, this would of course also be possible and not too different from a GtkPrint approach. GtkPrint offers dialogs to choose the PageSize etc, which Cairo does not. Export to PDF has often been requested. It would be particularly interesting if it could contain text layers as PDF text elements. We are missing some additions to the PDB text API to make this possible. But the missing API could be added (after 2.4 of course). Ok, I will try to implement a plugin based on Cairo, but this will take some time... Just two question: - Will it be possible since GIMP doesn't use Cairo yet? - Will it be color managed? Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin
Alexandre Prokoudine ([EMAIL PROTECTED]) wrote: - Will it be possible since GIMP doesn't use Cairo yet? It does implicitely, since it already depends on a GTK+ version that depends on cairo. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin
Hi, On Sun, 2007-07-22 at 14:10 +0200, Stefan Roellin wrote: The current implementation/patch now has a disadvantage: if you print to a postscript target, the image has to be exported TWICE: once for the 'print preview widget' (with alpha) and once for the postscript target (without alpha). This is certainly not optimal regarding memory consumption. I have attached a patch to the bug report that outlines a way to work around this problem. If yes, a solution could be to not distinguish between a Postscript and a PDF target (i.e. to embed only opaque images into a PDF despite the fact that PDF can handle images with alpha values). Would this approach have any disadvantages? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin
Sven Neumann wrote: Hi, On Sun, 2007-07-22 at 14:10 +0200, Stefan Roellin wrote: The current implementation/patch now has a disadvantage: if you print to a postscript target, the image has to be exported TWICE: once for the 'print preview widget' (with alpha) and once for the postscript target (without alpha). This is certainly not optimal regarding memory consumption. I have attached a patch to the bug report that outlines a way to work around this problem. If yes, a solution could be to not distinguish between a Postscript and a PDF target (i.e. to embed only opaque images into a PDF despite the fact that PDF can handle images with alpha values). Would this approach have any disadvantages? It pretty much doesn't matter what you can do with a PDF target, so long as there is still the ability to directly print as PostScript and save as EPS/PS. Should an image be intended for print, then there would be no harm in dumping alpha and using opaque. Someone may want to actually further edit an image, in which case a PDF losing alpha would be a disadvantage...but PDF is the wrong format for this anyway (most of the PDF editing tools out there are junk, set with features to sell a product that breaks if you mix it with the wrong situation). The up side to only embedding opaque is easier maintenance, common code set, etc. Quite likely it would result in better reuse of code. If you want a final answer, you're going to have to know who uses alpha in a PDF which is intended to be in its final form, and not as an intermediate product of editing. Newer PDF formats have a lot of features which barely anyone uses...when they are used, I see it for interactive purpose, not for print. D. Stimits, stimits AT comcast DOT net ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin
Sven Neumann wrote: Hi, On Sun, 2007-07-22 at 14:43 -0600, D. Stimits wrote: For me, it is a serious problem. I work in the print industry, typically creating PostScript drivers. The PS output is quite good quality, and every conversion generally suffers serious quality issues. Gimp is one of the best tools available for UNIX side PostScript. Photoshop and some other tools, despite being Adobe products, tend to break standards compliant high end print systems (most of those products work great so long as you don't mix them with other people's products, then they suck...gimp PS works flawlessly with all of the certified systems). As soon as you start making PDF-to-PostScript conversions or PostScript-to-PDF-to-PostScript, the output is hopeless. Don't do it. We are talking about the new Print plug-in here, not about the plug-in that is used to save an image as a Postscript file. So your concerns are probably not valid. Yes and no. The PostScript which I have to slice-and-dice is from save as, but all of the printers involved are PostScript printers. Some can handle PDF, others cannot. If I were to print a high res image on a quality printer (definitely not some ink jet from the local store), it'd be rare that any conversion process would leave the quality in tact. The only time exporting a transparency is a problem is if you plan to print on some sort of custom paper that isn't plain white, but then there should be a background color anyway. With an exception that is irrelevant, there are no printers with transparent ink (that exception being in the dye sublimation, but the transparent ink is a coating for longevity, and has no knowledge of any alpha channel). Show me a printer takes advantage of mixing transparent inks, taking advantage of an alpha channel, and I'll agree that there is a reason to not export to a non-transparent color space. On the other hand, every single printer out there which handles PostScript natively (and there is no such thing as a good PCLprinter, even if it emulates PostScript) will suffer by removing direct PostScript output. I do indeed print directly from gimp without an intermediate step, as proofs and other samples going to a quality PostScript printer are best done from gimp...some of the other products are known to crash printers under some images, gimp never does this, it's the only really stable program for that purpose (all of these printers are Adobe certified, the low end systems start at about $10k, the I-Gen systems range from over $100k on up...which Adobe products tend to crash). Being able to take advantage of a PPD file during print from gimp is very useful, and I print directly from gimp daily. A PDF conversion would ruin this, so I'm in the opposite position by having a real PostScript system. So I pose this question...if print via PDF is to be considered, why remove the existing PS system, which is pretty much the best quality PostScript among all of the apps (commercial and free)? There isn't any reason to not add a PDF print preference, but PDF language is not intended as a print language, it is a document interchange format, and should not be converted to this format until interchange is needed. A preference could easily be set if both formats are available, but there is a genuine need for real PostScript output in the non-windows world. I don't want to hand craft save-as-eps files for specific hardware every time someone wants a sample print, just so I can keep the image quality. I really don't understand why anyone would want to remove PostScript print options instead of adding PDF to it, especially since much of the PostScript code directly translates to PDF code. D. Stimits, stimits AT comcast DOT net ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Print plugin
Hi, I have submitted a patch which (slightly) improves the quality of the print plugin (see Bug #387604). The problem basically was that Postscript can't cope with transparency. In contrast, PDF is able to do so. The current implementation/patch now has a disadvantage: if you print to a postscript target, the image has to be exported TWICE: once for the 'print preview widget' (with alpha) and once for the postscript target (without alpha). This is certainly not optimal regarding memory consumption. So the question is, whether this is a real problem or not. If yes, a solution could be to not distinguish between a Postscript and a PDF target (i.e. to embed only opaque images into a PDF despite the fact that PDF can handle images with alpha values). In this case, we only have to export the image at most once. Stefan ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin
Stefan Roellin wrote: Hi, I have submitted a patch which (slightly) improves the quality of the print plugin (see Bug #387604). The problem basically was that Postscript can't cope with transparency. In contrast, PDF is able to do so. The current implementation/patch now has a disadvantage: if you print to a postscript target, the image has to be exported TWICE: once for the 'print preview widget' (with alpha) and once for the postscript target (without alpha). This is certainly not optimal regarding memory consumption. So the question is, whether this is a real problem or not. For me, it is a serious problem. I work in the print industry, typically creating PostScript drivers. The PS output is quite good quality, and every conversion generally suffers serious quality issues. Gimp is one of the best tools available for UNIX side PostScript. Photoshop and some other tools, despite being Adobe products, tend to break standards compliant high end print systems (most of those products work great so long as you don't mix them with other people's products, then they suck...gimp PS works flawlessly with all of the certified systems). As soon as you start making PDF-to-PostScript conversions or PostScript-to-PDF-to-PostScript, the output is hopeless. Don't do it. If yes, a solution could be to not distinguish between a Postscript and a PDF target (i.e. to embed only opaque images into a PDF despite the fact that PDF can handle images with alpha values). In this case, we only have to export the image at most once. PDF is pretty much a subset of PostScript with a hierarchy, at least in the basic early versions. When you start getting into more recent versions, it diverges, but still contains mainly a subset of PostScript operators for the vector and bitmap part of it. If you wanted support for PDF, you'd be better off making both PS and PDF output options. It'd be nice to have direct PDF output, but this is a document interchange format, and NOT a print format. There is no reason to not add dual output format, but there is an extrordinary loss of quality by removing direct PostScript output (FYI, I must often slice and dice the raw PostScript, and gimp has the most sane version among the common tools). FYI, a proper conversion tool can convert from PS to PDF without loss, but virtually all tools have issues, mainly when converting vector to bitmap, or using lossy compression without an option to say no to it. If anyone really felt the need to improve print options, my own feeling from coding for the print industry is that more options on compression formats and font embedding (perhaps not relevant for gimp) would be appropriate. D. Stimits, stimits AT comcast DOT net ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Print plugin for 2.0
Does 2.0 have any functioning print plugin? If not, what changes need to be made to the current 4.2-based plugin? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin for 2.0
Hi, Robert L Krawitz [EMAIL PROTECTED] writes: Does 2.0 have any functioning print plugin? If not, what changes need to be made to the current 4.2-based plugin? It has a functional print plug-in based on gimp-print 4.2. For GIMP-2.2, we'd like to provide a print plug-in based on a newer gimp-print release (that would be 5.0 then?). Perhaps we would even do that change in some 2.0.x release. It depends on the timing of your releases and whether someone does the necessary hacking. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin for 2.0
Hi, Robert L Krawitz wrote: I'm the Gimp-Print project lead, that's why I asked the question :-) I know :) Sorry to hear the 5.0 release is still a bit away. In the 5.0 tree, the plugin has been split into two pieces, a UI library (libgimpprintui) and the GIMP plugin proper (which is tiny, and contains all of the GIMP-specific code). We should work out the appropriate ownership of of these two components, and the correct dividing line. It would be really great if you would continue to maintain the gimp-print plug-in that's in GIMP CVS. Understandably, since gimp-print is now very much its own project, our release schedules aren't going to match up for the most part, but currently the goal would be to support the latest stable release of gimp-print in the GIMP. Having 2 GIMP plug-ins (1 in gimp-print that's based on the last stable GIMP and another in the GIMP that's based on the last stable gimp-print) doesn't really make sense. I would propose that the gimp-print plug-in gets updated in the GIMP tree when the libgimp API changes, and then gets updated to use the new gimpprint when a stable release comes out. What do you think? Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin for 2.0
Hi, Robert L Krawitz [EMAIL PROTECTED] writes: In the 5.0 tree, the plugin has been split into two pieces, a UI library (libgimpprintui) and the GIMP plugin proper (which is tiny, and contains all of the GIMP-specific code). We should work out the appropriate ownership of of these two components, and the correct dividing line. There's still a GIMP plug-in in the 5.0 tree? Now I am confused. I thought our plan to get rid of that circularity was that you drop the GIMP plug-in entirely and leave it up to the GIMP team to provide a plug-in that builds on the gimp-print library. Is that not the plan? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin for 2.0
Date: Fri, 12 Mar 2004 14:25:23 +0100 From: Dave Neary [EMAIL PROTECTED] Hi, Robert L Krawitz wrote: I'm the Gimp-Print project lead, that's why I asked the question :-) I know :) Sorry to hear the 5.0 release is still a bit away. In the 5.0 tree, the plugin has been split into two pieces, a UI library (libgimpprintui) and the GIMP plugin proper (which is tiny, and contains all of the GIMP-specific code). We should work out the appropriate ownership of of these two components, and the correct dividing line. It would be really great if you would continue to maintain the gimp-print plug-in that's in GIMP CVS. Understandably, since gimp-print is now very much its own project, our release schedules aren't going to match up for the most part, but currently the goal would be to support the latest stable release of gimp-print in the GIMP. Having 2 GIMP plug-ins (1 in gimp-print that's based on the last stable GIMP and another in the GIMP that's based on the last stable gimp-print) doesn't really make sense. I would propose that the gimp-print plug-in gets updated in the GIMP tree when the libgimp API changes, and then gets updated to use the new gimpprint when a stable release comes out. The current plugin (based on 4.2) is basically in sustaining at this point, and really approaching EOL. We're hardly even fixing bugs in 4.2 any more. We're probably going to do one more 4.2 release for a few bugs, an OS X problem that isn't a Gimp-Print problem but which gets blamed on it, and a couple of new Epson printers. But that won't cause you any problems. I'm not going to remove it from our source base, since there will be very few 4.2 releases left. The plugin in our 5.0 tree is another matter. Since the 5.0 API isn't locked down, it's premature (IMHO) to transfer it to the GIMP. There are major structural changes from the 4.2 plugin; in particular, it has been split into two pieces, libgimpprint and the Print plugin proper. libgimpprint is a GTK+ (1.2 right now) UI, without any linkage to libgimp. The GIMP-specific code is in the plugin, consisting of 4 files of less than 1000 lines of code: 4571492 11003 print-image-gimp.c 4251418 13702 print.c 55 2221590 print_gimp.h 38 1991372 print-intl.h 9753331 27667 total The question is what should be transferred to the GIMP when our API stabilizes. Certainly the core GIMP plugin is a good candidate, but libgimpprintui is less clear. It's actually much larger than the plugin proper (and badly in need of cleanup). It could at least in principle be used as a print facility by other GTK-based applications, although it's not completely general (it only handles single pages). 4438 12230 136157 panel.c 13713945 36094 plist.c 155 4653964 print-image-thumbnail.c 44 2151385 printrc.h 105 3823287 printrcl.l 285 6546321 printrcy.y 8692482 25134 ui-utils.c 7267 20373 212342 total (I'd ideally like to support both a 4.2 and a 5.0 plugin concurrently, because people who have built workflows around 4.2 may not want to switch in one shot.) -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin for 2.0
From: Sven Neumann [EMAIL PROTECTED] Date: 12 Mar 2004 14:19:13 +0100 Robert L Krawitz [EMAIL PROTECTED] writes: In the 5.0 tree, the plugin has been split into two pieces, a UI library (libgimpprintui) and the GIMP plugin proper (which is tiny, and contains all of the GIMP-specific code). We should work out the appropriate ownership of of these two components, and the correct dividing line. There's still a GIMP plug-in in the 5.0 tree? Now I am confused. I thought our plan to get rid of that circularity was that you drop the GIMP plug-in entirely and leave it up to the GIMP team to provide a plug-in that builds on the gimp-print library. Is that not the plan? See my previous reply to Dave Nearly on this. That's the plan, but there are architectural and execution issues to be worked. I'm hoping to do a lot of work and get close to locking down the 5.0 API this weekend, although I don't know whether I'll manage to complete everything. The changes I want to do will generalize the input mode support, so you really want them in place before GEGL (and for that matter the Cinepaint folks really need these changes too). I want to stabilize the 5.0 API, and hopefully have something that will be backward compatible at 5.2, so it's premature to transfer ownership yet. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-print-devel] Re: [Gimp-developer] Print plugin for 2.0
Hi, Robert L Krawitz [EMAIL PROTECTED] writes: libgimpprint is a GTK+ (1.2 right now) UI, without any linkage to libgimp. It will have to be ported to the GTK+-2.x API if you want it to be useful. Are there any plans to do that? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-print-devel] Re: [Gimp-developer] Print plugin for 2.0
From: Sven Neumann [EMAIL PROTECTED] Date: 13 Mar 2004 03:45:21 +0100 Robert L Krawitz [EMAIL PROTECTED] writes: libgimpprint is a GTK+ (1.2 right now) UI, without any linkage to libgimp. It will have to be ported to the GTK+-2.x API if you want it to be useful. Are there any plans to do that? No, but we could use a volunteer. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin
Hi, Robert L Krawitz [EMAIL PROTECTED] writes: I expect that we're going to go alpha with 4.2 in the relatively near future, and then release some time this summer. What should we do about syncing up? What are you suggesting? I think we are willing to include a new version with stable gimp-1.2 if it has seen a good amount of testing. I would suggest you release 4.2 and if we do another stable gimp-1.2 release after this release we will consider including the new version. To assure that this happens and enough people test it, we should include 4.2 into gimp CVS as soon as it is released. For gimp-1.3/1.4 this brings up the general question about plug-ins again... Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin
From: Sven Neumann [EMAIL PROTECTED] Date: 20 May 2001 13:47:36 +0200 Robert L Krawitz [EMAIL PROTECTED] writes: I expect that we're going to go alpha with 4.2 in the relatively near future, and then release some time this summer. What should we do about syncing up? What are you suggesting? I think we are willing to include a new version with stable gimp-1.2 if it has seen a good amount of testing. I would suggest you release 4.2 and if we do another stable gimp-1.2 release after this release we will consider including the new version. To assure that this happens and enough people test it, we should include 4.2 into gimp CVS as soon as it is released. That sounds reasonable. Release is probably at least a few months off right now, but I want to get things rolling. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Print plugin
I expect that we're going to go alpha with 4.2 in the relatively near future, and then release some time this summer. What should we do about syncing up? -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
