Add printing support in Pinta

[grofaty]

In Pinta 0.6 for Windows XP I create a image but sometimes I would like to print this image. I see no support for printing in Pinta (there is no File | Print). It would be nice if printing is supported in Pinta.

[grofaty (grofaty)]

Just an quick update. I have Pinta 1.0 installed and this feature is not implemented yet. I see a printing the biggest MISSING feature in Pinta. I have installed Pinta on my friend computer and he liked it very much, but then asked me how to print a picture... The easiest solution is to use some other image editing program that ALSO has a printing support. This is one single big missing feature in Pinta from my point of view.

[Cameron White (cameronwhite91)]

I agree, this is definitely a useful feature that I'd like to get implemented for a future release.

[Robert Nordan (rpvn)]

It should be quite doable, there is multiplatform printing support in gtk-sharp somewhere. It's used in Tomboy Notes (although for text, not images) so we can have a look there to see the basics.

[Olivier Dufour (olivier-duff)]

here it is:
http://developer.gnome.org/gtk/2.24/gtk-High-level-Printing-API.html#gtk-High-level-Printing-API.description

Olivier Dufour

On Mon, Sep 12, 2011 at 10:32 PM, Robert Nordan
<email address hidden>wrote:

> It should be quite doable, there is multiplatform printing support in
> gtk-sharp somewhere. It's used in Tomboy Notes (although for text, not
> images) so we can have a look there to see the basics.
>
> --
> You received this bug notification because you are a member of Pinta
> Developers, which is subscribed to Pinta.
> https://bugs.launchpad.net/bugs/728426
>
> Title:
> Add printing option in Pinta
>
> Status in Pinta:
> New
>
> Bug description:
> In Pinta 0.6 for Windows XP I create a image but sometimes I would
> like to print this image. I see no support for printing in Pinta
> (there is no File | Print). It would be nice if printing is supported
> in Pinta.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/pinta/+bug/728426/+subscriptions
>

[grofaty (grofaty)]

I will just write some ideas what it would be nice if implemented:
1. Print-preview.
2. Print default picture as-is (the same size and layout).
3. Re-size image to fit to specific paper format like: A4 standard paper size.
4. Print layout options: Portrait and Landscape.
5. Number of copies (default 1).

Most of this features options should probably be available on the same print window dialog.

[Manish Sinha (मनीष सिन्हा) (manishsinha)]

I work looking at this. Not sure if this should be implemented as an extension or as part of codebase. I was thinking extension because I am reusing code snippets which are LGPL. I am not sure about license compatibilities between LGPL and MIT.

Since MIT license should not limit what kind of licensed code can link to it at runtime, I think addin/extension should be a safe bet

[grofaty (grofaty)]

First of all I am not a lawyer, so I may be wrong... but I have read a lot of license like documentation, so I know little bit about licensing the program.

If you would like to combine the work of two programs that uses different licenses both licenses must permit this combining.

MIT LICENSED PROGRAM:
You can do with the code what ever you like to do (also sell, even re-license the program under closed-source license etc) with two restrictions: a) in source code you need to provide info that code was part of the MIT license and in source code write the copy-right owner of the original code and b) developer of the code does not provide warranty of any kind (developer is protected against suit). If two programs are combined the derived program can be re-licensed under any other license.

GPL LICENSED PROGRAM:
You can do with the program what ever you like to do (also sell the program), you can even modify the program, but at the moment you pass the code (executable) to the third person, you must also provide all derived source code. Developer is not permitted to re-license the program. If two programs (one of them is GPL program) are combined the derived program must be licensed under GPL.

LGPL LICENSED PROGRAM:
With this kind of licenses are in most of the cases used for libraries. The license is very similar to GPL but with exception that non-LGPL code can be linked with libraries in any way. LGPL code library can also be linked to closed-source programs (logically also with MIT like programs). Restriction is: if you change the code inside the library that is licensed under LGPL any derived work of changed library must be also licensed under LGPL.

IN THIS PARTICULAR CASE:
So in this case you can create an extension or write it inside main program, no difference. In both cases the restrictions are EXACTLY the same. If you change the library code you need to provide source-code changes and license all of the changes under LGPL. (But if this happens I suggest to contact the copy-right owner of library, so he/she can upgrade the code and include your changes in next version and any other project that uses this code can benefit.)

But don't forget combining the code and merging is not the same. If you just link your code with LGPL library then this is just combining. But if you copy the code and merge your code with the code from library then all derived code must be licensed under LGPL code.

So the main question is, is this LGPL code stored in library (separated file/files) and you will just call the library from Pinta (this is OK no license problem) or is this software just part of the code and you would like to merge (not link) this code into existing Pinta's code - merge it in such a way that there is no way to know which code is from LGPL program and which from existing Pinta program (so no library) - in this case don't do this you will be violating the LGPL license of library and we don't want that (unless all of the Pinta code is re-licensed under LGPL).

I assume code is stored in some separate files (libraries) if not I suggest them to store them like libraries and make it sure this code is stored separately and not changed in any wa...

[grofaty (grofaty)]

My previous post was only about license. From end-user point of view it is not difference if this print plug-in is integrated into main product or it is used as extension. What mathers is what will happen with the code when new version is released and printing stops working? What will developers say? This is plug-in code and we are waiting for plug-in developer to fix the code for new version of Pinta. If this is the case, then I am for integrated solution without plug-in. But if developers will fix the problem in extension, then I don't care if this is extension or not.

But like I have written in my previous post we must NOT violate the license. How is this snippet code written? Is it a library? If not can it be stored as library? If yes, then I suggest to write printing support in Pinta without extension. Just use calls to library from main code.

[Robert Nordan (rpvn)]

It's quite possible to have an extension that is maintained by the core developers. and it's probably just as well to have printing as an extension/plug-in/add-in for two reasons: One is maintainability, and the other is that users without printers may just want to switch the functionality off.

Legally speaking I don't think there's any problem with having an LGPL extension linked from the main program, but it would require a license note stating that the extension was under the LGPL. My main issue with that is that it is a minor pain in the ass. Putting LGPL code in the main program is a no go because that would require relicensing the whole thing to LGPL.

[Manish Sinha (मनीष सिन्हा) (manishsinha)]

> Putting LGPL code in the main program is a no go because that would require relicensing the whole
> thing to LGPL.

I don't think so. Since MIT is compatible with GPL. Since LGPL is even
less copyleft, then it should be a lesser problem.

Re-licensing the whole thing is not needed. Most authors don't accept
such code because they want the whole application to be of same
license.

Take for an example - Tomboy. It contains code with MIT, GPL and LGPL
in one same codebase.

[grofaty (grofaty)]

Yes and no. LGPL license permits linking (calling library) from the main program code, but it does not permit to merge the code into one code that is no way to know which code is LGPLed and which is MIT. If you can't separate the code into library (external file) and you would still like to have one merged version of program, then LGPL requires relicensing all of the product to LGPL license. So the main question is: can you separate the LGPL code into library. If yes then printing can be written as main part of the code and just calling library from main program. If this library separation is not possible, then write an extension and put whole extension code under LGPL.

"... users without printers may just want to switch the functionality off." Yes sure, but I don't think this should be the only argument. For example I never use Effects, so it would be nice to exclude this functionality into extension. Don't think this should be done. There are just core functionalities (printing is one of them, and effects is the second in image editing program) that should just be included in main program. I have never seen a printing support in extension, this is core function. So this should not be the only argument of decision.

I suggest to look into the code and find out if LGPL code can be stored into library and if it can, then write printing into main program, if not then write an extension.

[Manish Sinha (मनीष सिन्हा) (manishsinha)]

On Wed, Oct 19, 2011 at 4:02 PM, grofaty <email address hidden> wrote:
> Yes and no. LGPL license permits linking (calling library) from the main
> program code, but it does not permit to merge the code into one code
> that is no way to know which code is LGPLed and which is MIT. If you
> can't separate the code into library (external file) and you would still
> like to have one merged version of program, then LGPL requires
> relicensing all of the product to LGPL license. So the main question is:
> can you separate the LGPL code into library. If yes then printing can be
> written as main part of the code and just calling library from main
> program. If this library separation is not possible, then write an
> extension and put whole extension code under LGPL.

Well, the point point of license compatibility is whether code licensed under
two different licenses can be used together or not. If GPL and MIT are
compatible,
then why not LGPL and MIT?

Just FYI, Tomboy has MIT and GPL code mixed together.

Yes,there is a way to make out which code is GPL and which is MIT in the
source code - The license header. Every file in MIT licensed codebase should
have a license header - though LGPL/GPL codebase should also do that.

So all the Pinta would be under MIT and this printing file would be under MIT
with the license and copyright clearly stated at the top of the file.

"then LGPL requires relicensing all of the product to LGPL license"
I would like to see some cases or references to this problem.

I can still implement it as an extension. Will look into it

[Robert Nordan (rpvn)]

Ok, now I dug up a relevant link: http://www.dwheeler.com/essays/floss-license-slide.html

License compatibility doesn't mean they can be used interchangeably, only that code under one license can be combined with the other and relicensed without breaking the original license terms.

Basically, when you say that something is GPL-compatible it means that it can be merged into a GPL program, but it only works one way. (In favour of the GPL.) The merging goes MIT/BSD -> LGPL -> GPL, but you can't merge the other way. For Tomboy it's unproblematic to have MIT code in an LGPL program, but for us to have LGPL code in an MIT program is a problem.

Tomboy used to have the printing add-in (yes, some people do have their printing functions as extensions) under the GPL which worked because it was distributed alongside Tomboy but not integrated with it. It has since been relicensed as LGPL. (September last year.) If there was any GPL code inside of Tomboy proper it would have been a major problem and Tomboy would either have to strip it out or go full GPL.

[grofaty (grofaty)]

Manish, sorry for confusion in my post #11 I was responding to Robert's post #9, but in the middle of this posting you have posted new post me anaware of your post, so confusion was made, because you thought that I responded to your post, but I wasn't. Sorry, I should make a reference in my post.

I totaly agree with Robert in post #13. LGPL code cann't be integrated into MIT code. MIT license is not violated in this case, but LGPL license is. Like I have written in second paragraph of #7: "If you would like to combine the work of two programs that uses different licenses both licenses must permit this combining." MIT permits combining from LGPL, but LGPL does not permit to be combined into MIT.

The difference beetween GPL and LGPL: In you program you are allowed to LINK your main program to ouside LGPL licensed library, but in your program you are not allowed to link to GPL library (or any other code). GPL and LGPL both have the same restrictions about changing the code. If you change the GPL or LGPL code you have to license derivated work as GPL/LGPL.

Because you can bundle LGPL library and MIT program into program's bundle (like EXE installation file in Windows), you are also permited to bundle the LGPL extension with MIT program into program's bundle. So if you would really really really like to play safe, then extension is fine.

What kind of decision you will make (extension or integrate printing into main code linking to external LGPL library) is your developers decision and decision of maintainer what kind of code will he accept when merging your code into official Pinta's branch. I am just trying to help us to better understand the licensing issues.

OK, back to main topic of licensing. If decision is made to write extension using LGPL code then whole extension is probably the easiest way to license as LGPL (but it is not required if in your extension you will just link - call functions from - library in this case you can license your extension with any kind of license even closed-source if you like and you will not violate the LGPL license). But I don't guaranty that maintainer will accept closed-source extension and distribute is inside a Pinta installation bundle program.

If decision is made to write printing support into main Pinta program, then LGPL code MUST be in separate library and just link your main Pinta's code to library, because if not then you are violating the LGPL license.

P.S. I would not refer to Tomboy as a good license solving project reading the bugs reports like this: https://bugs.launchpad.net/tomboy/+bug/190862 makes me very sceptical about license knowledge of Toboy authors.

[Manish Sinha (मनीष सिन्हा) (manishsinha)]

On Wednesday 19 October 2011 07:33 PM, grofaty wrote:
> If decision is made to write printing support into main Pinta program,
> then LGPL code MUST be in separate library and just link your main
> Pinta's code to library, because if not then you are violating the LGPL
> license.
I think the best way is to have it in an extension. that would be in
any case safer than mixing code.

By the way, many of the components in Pinta are actually extensions
including effects.

-
Manish

[grofaty (grofaty)]

Manish, the only consideration I have is the extension maintenance when new version is released and something in extension must be fixed to extension work properly and you as extension writer lose interest/time to fix it. If the code lands to git and developers/maintainers are willing to work on the code (and if I understand Robert correctly they will) to make sure printing is working fine, then it is fine by me.

It was nice discussion about licensing and we must make sure everything in code is properly licensed.

BTW, I am willing to test printing support when some code is ready, even if it is from your personal git repository.

[Manish Sinha (मनीष सिन्हा) (manishsinha)]

On Wednesday 19 October 2011 10:47 PM, grofaty wrote:
> Manish, the only consideration I have is the extension maintenance when
> new version is released and something in extension must be fixed to
> extension work properly and you as extension writer lose interest/time
> to fix it. If the code lands to git and developers/maintainers are
> willing to work on the code (and if I understand Robert correctly they
> will) to make sure printing is working fine, then it is fine by me.

This extension thing is just an implementation trick to avoid licensing
issues. Even effects are implemented as extensions.

Extensions will break *only* if the API is broken in backward
incompatible way which I doubt would happen

[Manish Sinha (मनीष सिन्हा) (manishsinha)]

Due to lack of time, I am un-assigning myself

[grofaty (grofaty)]

I am marking this bug as "in progress", because company "POD Exchange" is in the middle of development of printing. If someone has any interest on helping, then join mailing list discussion at:
https://groups.google.com/group/pinta/browse_thread/thread/7aa1d84b0c7efe05?hl=en

[Cameron White (cameronwhite91)]

I'm going to look into doing this for 1.5

[Cameron White (cameronwhite91)]

This is being worked on for GSoC.

[Rik Shaw (rik-shaw)]

Great to hear it may be going ahead this summer at GSoC. Thanks for the efforts.

[grofaty (grofaty)]

@iveand, some preliminary printing is already done, so printing is possible in Pinta 1.5. But current printing is very basic without any customizations. GSoC will bring printing to decent level which many of end users expect from drawing/imaging program.

[Cameron White (cameronwhite91)]

FYI - I'm planning to disable printing before the 1.5 release, as the current implementation is not very well tested, doesn't handle errors, and has a bunch of bugs / missing features.

[grofaty (grofaty)]

Cameron, this is very humble and wise decision from you and I fully support your decision. Currently printing is not very helpful and looks like little bit unfinished. As seen from #20 you have planned to add more sophisticated printing support in 1.5, but now GSoC is planned and you wisely postpone this task. We should wait to add more advanced (and also some basic one) printing options as result of this project in 1.6.

Currently as printing is implemented in Pinta wide majority of users will not be happy with printing and will be in hunt to find some other tool to print. Also when release is done we can expect some PR and journalists may misjudge Pinta on one single feature that is not prime time ready.

Probably the best is to disable for 1.5 and after release enable it back to be available in master and in future development release, so Andrew could pick up where you left.

[G4JC (gaming4jc2)]

This is definately a must have, I went to File > Print an image just today and then realized it doesn't exist.
Glat to see you guys are working on it! +1 :)

[grofaty (grofaty)]

I compiled Pinta from source from today repository tagged as "Pinta-release-1.5" and I see Print feature is removed as expected from Cameron post #24.

This printing feature was planed for Google Summer of Code 2013, but Andrew was not able to complete it, so probably it is not going to be in Pinta for some time. Cameron, I suggest to remove "Andrew Davis" from "Assigned to" list of current bug report.

[Rik Shaw (rik-shaw)]

Too bad it was not able to be completed this past summer. Is it true there is no active work being done on bringing printing to Pinta?

[Cameron White (cameronwhite91)]

This is something that we will be working on for the next release of Pinta

[Janet (bugzilla-kerridis)]

Any news about printing in pinta?

[Cameron White (cameronwhite91)]

Printing is also disabled for 1.7 since it's not ready yet.

[Andreas Fester (andreas-fester)]

Would it be simpler to provide at least a "save as PDF" function in the first step?
When you say "Printing is disabled", is there already a branch which contains some printing related code?

[Cameron White (cameronwhite91)]

There isn't a separate branch, it was just the menu item that was turned off to hide the incomplete functionality (https://github.com/PintaProject/Pinta/blob/master/Pinta/Actions/File/PrintDocumentAction.cs)
I don't think it's likely any easier to implement PDF saving - it would make more sense to just spend some development time implementing the things that aren't currently being handled correctly from the GTK printing functionality, like scaling

[grofaty (grofaty)]

When printing was made available in Pinta, it didn't really work properly (like user is expecting). Printing picture and it was printed 2 cm x 1 cm in top left of paper.

I expect picture is printed in 100% into the paper if it fits the paper or it picture is scaled down to fit on paper.

Beside printing it would be nice to have some Print Preview, so user could see what is going to be printed.

Maybe also adjusting some print quality to preserve ink.