Could you reproduce the color problem when printing directly from gimp ?
Because the version of kipi-plugins ( kipi-plugins-printimages ) did not change at all so i doubt it's related to kipi-plugins update.

Keywords: (none) => NEEDINFO
CC: (none) => balcaen.john
Source RPM: (none) => kipi-plugins-1.9.0-3.1.mga1.src.rpm

Please give the information asked in comment #1, if you want that there is a chance for us to find the cause of your bug and fix it.

CC: (none) => stormi
Assignee: bugsquad => balcaen.john

I have been working with Florian Hubold. I think that my printer is not supported in Mageia. Florian had me check ppd files. I tried the one that worked in ML2010.2. Also one from cups and 2 from mageia. Nothing worked. I tried it in gwenview using print ass't and in gimp using gutenprint. In gwenview I used a jpg and in gimp an xcf file.

The printer is an HP Photosmart Plus b209a-m. 

One problem is that if I install the printer using the control center the HP device manager does not recognize it and I have to reinstall using the device manager. This gives me 2 ppd files in /etc/cups/ppd.

This is a comment I received from Angelo Naselli:

Well i've just tried my hp photosmart premium c309g-m
and had some color issues as well, my print result was dark green
stronger...

Ok i'm reassiging to bugzilla team since it's not a problem related to kipi-plugin but rather the print system (eitheir cups or the hp support in mageia 1)
I switch the src.rpm to cups (but maybe hplips is better)

@ gary
did you try eventually the hplip-tools available in mageia 2010.2 ?

Source RPM: kipi-plugins-1.9.0-3.1.mga1.src.rpm => cups-1.4.6-3.mga1.src.rpm

I went here for info.

http://hplipopensource.com/node/224

I did an hp-check in Mageia and ML2011.2. They both looked to have the same results. I did not do a line by line comparison. I think the fact that the hp device manager did not recognize the Mageia CC install may have a bearing. That gave me 2 ppd's in /etc/cups/ppd and 2 differently named printers. I also installed it in cups and got a third ppd and another named printer. All the names were a variation of my printer. In ML2011.2 I only have one ppd. I am using ML. I do have mageia on a flash drive and can do some testing if required.

FWIW, i've rebuilt hplip 3.11.5 from ML2010.2 updates and my printed photos are darker as well.

assign to cups maintainer

Assignee: bugsquad => dmorganec

Investigating a bit i found these bugs:

https://bugs.launchpad.net/hplip/+bug/885246

http://forums.opensuse.org/english/get-technical-help-here/applications/467129-hplip-images-wont-print-libreoffice-2.html

They say it's a ghostscript issue. I will try to downgrade to check it, last cauldron version 9.04 seems to be affected as well even if the output is better
than in mageia 1.

Suse seems to have fixed it:
http://lists.opensuse.org/opensuse-updates/2011-06/msg00007.html

hmm, since that patch has been added at the beginning of 2011 i suspect is already in 9.02, it is in 9.04 (cauldron) as i checked. I will do some more tests with hplip new then...

I tried new hplip in cauldron and it seems to work well now, can we provide new hplip in testing to see if ghostscript 9.02 and it are the solution?

i backported hplip and it's not enough. i believe gs is a bit harder to backport, and needs to build more things, i can't effort it if it can't be updated for our policy.

*** Bug 3382 has been marked as a duplicate of this bug. ***

CC: (none) => mageia

I know that there may be only a few of us with this problem and therefore not a high priority. However it is keeping me from using Mageia. I am forced to use ML2010.2. I am strictly a user. Would appreciate your help.
Gary

It's definitively a ghostscript problem. I removed my backported hplip and added a backported ghostscript and it prints well, maybe a little bit darker yet bat well.

Gary, you can get my packages from here:
http://www.linux.it/~anaselli/Backport/mageia%201/ghostscript/
You should update the ones you have with the old release, mine were:
ghostscript-module-X-9.02-2.mga1
ghostscript-9.02-2.mga1
ghostscript-common-9.02-2.mga1
lib64gs9-9.02-2.mga1
lib64ijs1-0.35-79.mga1
If you have problems, you can write me.

I tried them as far as i could, if they give some regression with other packages, please tell me and i will try to fix that also.

If you see that print outs are better but a little bit darker as well, i could try to upload hplip also.
Let's see if it's fixed for us at least, in the hope to have good news from update and backport policies. 

Have a happy new year,
Angelo

@ Gary
@ Martin

Can you please try Angelo's packages (comment 16) and report here how they work for you?

CC: (none) => marja11

I have tried Angelo's packages and they have cured the problem.
Thanks Angelo.
Gary

@ Martin Foster

Can you confirm that Angelo's packages solve the problem? (see comment 16)

Yes they work. See comment 18.
Gary

Angelo, do you plan an update in mga 1 ? (ghostscript 9.04 is in updates)

@ Gary

I know they work for you, that is why I asked Martin Foster.

To get feedback from him is important, because of what Angelo wrote in another bug report https://bugs.mageia.org/show_bug.cgi?id=2405#c10

The more people report that his packages fix their problem, the more chance that the fix will be included in Mageia 1

Manuel (comment 21) as you said it's against our policy, so we need a good reason to update :) (moreover i'm not the gs and hplip maintainer either ;) )

What do you mean by saying that gs 9.04 is in updates?

(In reply to comment #23)
> Manuel (comment 21) as you said it's against our policy, so we need a good
> reason to update :) (moreover i'm not the gs and hplip maintainer either ;) )

Well, should maybe be discussed on mageia-dev mailing list, but just adding some patches in ghostscript which adress this issue, without changing version nummber, is perfectly in conformance with our updates policy, maybe you misunderstood something? Otherwise, ghostscript is maintained by nobody, and hplip maintainer is not active so far, i've done all the updating and i'd be OK with it (if it's really needed for this issue, i believe ghostscript alone should fix this)

Florian, i was not able to patch gs 9.02 with needed patches. I don't think it's
that easy, but i'm not a gs hacker as said a lot of time here and in dev mailing list. 
Upstream developers changed that part of code (at least the one that affect
this bug) and added a patch after to fix this... but feel free to give it a look
and work on it... :)

Angelo

(In reply to comment #19)
> @ Martin Foster
> 
> Can you confirm that Angelo's packages solve the problem? (see comment 16)

Yes, I can confirm that the green tinge on black print is solved with Angelo's pacakages.

any news or any decision?

(In reply to comment #24)
> (In reply to comment #23)
> > Manuel (comment 21) as you said it's against our policy, so we need a good
> > reason to update :) (moreover i'm not the gs and hplip maintainer either ;) )
> 
> Well, should maybe be discussed on mageia-dev mailing list, but just adding
> some patches in ghostscript which adress this issue, without changing version
> nummber, is perfectly in conformance with our updates policy, maybe you
> misunderstood something? Otherwise, ghostscript is maintained by nobody, and
> hplip maintainer is not active so far, i've done all the updating and i'd be OK
> with it (if it's really needed for this issue, i believe ghostscript alone
> should fix this)

(In reply to comment #27)
> any news or any decision?

Your ghostscript package is version 9.04 and the current one is 9.02, so if this hasn't been discussed yet on mageia-dev, it should be

Do you mind writing a mail about this and explain why version 9.02 can't be fixed?

Well, even with another subject, that was discussed and Florian offered to
port the patch in that case also.
http://article.gmane.org/gmane.linux.mageia.devel/9303/match=hplip+3.11.10+call+testing+feedback+needed

I could not be able to port that patch to 9.02 because it can't be added as it 
is, i tried to follow the code to patch it by hands, but it was a big effort and
too many changed were needed. So if i have to back port a lot of changes, 
which is the difference in back-porting the package itself? 
Which is the risk on wrong back porting and breaking more things instead
of back-porting all and knowing that a lot of stable distros already use it?

And yes we can pretend to get it as 9.02 building 9.04...

If we look through before Christmas mails I'm almost sure I tried to talk about
this bug again, but the most don't want to update with a new version if you're not
called libreoffice or firefox or thunderbird... 

But here we have people with a problem, and they have it solved by testing my package, do they have regressions? I can say for what i use, i only get 
benefit... I believe it's enough to go on and certainly i won't leave 
if someone in the future have regressions (although not seen in cauldron, 
where i put the changes first and where they staid for enough)

Meh, must've forgot. OK, i'll try to take a look again at the patches, but may take some time, feel free to ping me again here or on IRC in case of no reply in due time.

For the problem in general of pushing a new ghostscript version to mga1, this is no good idea, and the comparison is lacking. The ones you mentioned are end-user programs, and also leaf ones (means not that much other packages are depending on them) here we're talking about updating a major part of our printing/graphics stack, this is just not the same.

FWIW, if your packages fix the problem, why don't you just mail -discuss again and offer your packages as a workaround? It's not an optimal solution, but a working one, no?

(In reply to comment #30)
 
> (means not that much other packages are depending on them)

Typo, meant to write "(means that no/not many other packages are depending on them)"

(In reply to comment #30)
> Meh, must've forgot. OK, i'll try to take a look again at the patches, but may
> take some time, feel free to ping me again here or on IRC in case of no reply
> in due time.
Ok I'm ready to help if needed.

> For the problem in general of pushing a new ghostscript version to mga1,
> this is no good idea, and the comparison is lacking. The ones you
> mentioned are end-user programs, and also leaf ones (means not that much
> other packages are depending on them) here we're talking about updating a
> major part of our printing/graphics stack, this is just not the same.
Yes that's why i asked for help in this task.
And that's why i care of considering pros and cons.
Btw i mentioned in that mail also monodevelop... that could not be updated 
even if it is a leaf at a moment... (but that's another subject)

> FWIW, if your packages fix the problem, why don't you just mail -discuss
> again and offer your packages as a workaround? It's not an optimal
> solution, but a working one, no?
The workaround is enough explained here and the packages so wha has the 
problem can get from my link or also here:
http://www.mageiaonline.it/mol-repo/i586/
http://www.mageiaonline.it/mol-repo/X86_64/

But the real point is I spent time to understand and follow this problem and
the risk of regressions wins against the benefit of having it fixed.
We can have a long time testing if needed before updating it (IMHO of course),
if we have no time to rebuild all the dependencies, i can contribute, just
knowing what and we can divide tasks :)

Cheers,
	Angelo

(In reply to comment #32)

> http://www.mageiaonline.it/mol-repo/X86_64/
Sorry:
http://www.mageiaonline.it/mol-repo/x86_64/

(In reply to comment #32)

> But the real point is I spent time to understand and follow this problem and
> the risk of regressions wins against the benefit of having it fixed.
> We can have a long time testing if needed before updating it (IMHO of course),
> if we have no time to rebuild all the dependencies, i can contribute, just
> knowing what and we can divide tasks :)
> 
> Cheers,
>     Angelo

@ QA

WDYT? Are you OK with this?

CC: (none) => qa-bugs

Marja this is mostly a packaging policy issue (after a quick skim through the later comments). If packagers are happy to release this then we're happy to test it, as far as we can do. That decision is usually taken before we get involved.

The only problem I can foresee from a QA perspective is that this ideally should be tested on a wide range of hardware and we have very limited between us. That would be an issue regardless of the version upgrade though so in some ways it's irrelevant. As with anything, we test what we can test.

We have asked for assistance with testing on the mageia-discuss ML with previous printing updates though, hplip if memory serves, with varied success.

@ Claire

Thanks for explaining :)


@ Angelo
@ Florian

So what should happen with this bug report?

ghostscript 9.04 should be put into updates testing.

Then QA will test, and also post an article to the discuss
mailing list asking for people to help testing.

CC: (none) => davidwhodgins

(In reply to comment #37)
> ghostscript 9.04 should be put into updates testing.
> 
> Then QA will test, and also post an article to the discuss
> mailing list asking for people to help testing.

@ Angelo
Could you push it to updates_testing?

Keywords: NEEDINFO => (none)

(In reply to comment #38)
> (In reply to comment #37)
> > ghostscript 9.04 should be put into updates testing.
> > 
> > Then QA will test, and also post an article to the discuss
> > mailing list asking for people to help testing.
> 
> @ Angelo
> Could you push it to updates_testing?

@ DMorgan

I just tried to ping you on IRC to tell you that I asked Angelo to do this, but you aren't there :(

[10:32] <xochiquetzal> dmorgan was last seen in #mageia-dev 23 hours 41 mins ago leaving the channel.

To comment #38, Marja i cannot until tonight at home, if you find dmorgan, and have something against it we have time :)
I will try to ask tonight before starting anyway ;)

Angelo

ghostscript-9.04-1.1.mga1 should be uploaded in core/testing, please test it.

@ Marja what we have to do now? I think it's early for an advisory, or do we have to write it anyway?

If it's ready for qa, please assign it to qa-bugs@ml.mageia.org
with an advisory.

There is now ghostscript-9.04-1.1.mga1 in core/testing to validate
-------------------------------------------------------

Advisory text:
-------------------
Some HP printers even if fully supported, have problems in
printing photos, output colors are darker than original.

This update solve the issue.

Uploaded packages are
ghostscript-9.04-1.1.mga1
ghostscript-common-9.04-1.1.mga1
ghostscript-doc-9.04-1.1.mga1
ghostscript-dvipdf-9.04-1.1.mga1
ghostscript-module-X-9.04-1.1.mga1
ghostscript-X-9.04-1.1.mga1
lib64gs9-9.04-1.1.mga1
lib64gs9-devel-9.04-1.1.mga1
lib64ijs1-0.35-81.1.mga1
lib64ijs1-devel-0.35-81.1.mga1

Status: NEW => ASSIGNED
Assignee: dmorganec => qa-bugs

Testing complete on i586 for the srpm
ghostscript-9.04-1.1.mga1.src.rpm

Testing included converting pdf to gs, viewing gs, etc.

Testing complete on x86_64

Tested conversion to pdf, viewing ps and printing from gwenview to HP printer.
No regressions noted.

Update Validated

Could sysadmin please push ghostscript-9.04-1.1.mga1.src.rpm from core/updates_testing to core/updates

Advisory
--------
Some HP printers even if fully supported, have problems in
printing photos, output colors are darker than original.

This update solve the issue.

Keywords: (none) => validated_update
CC: (none) => derekjenn, sysadmin-bugs

Update pushed

Status: ASSIGNED => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED