Bug 485678 - glabels ignores quality settings in print dialog
Summary: glabels ignores quality settings in print dialog
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glabels
Version: 10
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Peter Gordon
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-02-16 07:44 UTC by "FeRD" (Frank Dana)
Modified: 2009-03-03 10:56 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-03-03 10:56:56 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description "FeRD" (Frank Dana) 2009-02-16 07:44:42 UTC
Description of problem:
I noticed that glabels was printing labels that look... well... less-than-spectacular, and I couldn't get them to look good no matter what settings I used. In fact, my settings seemed to have no effect on the output, which was the point I realized there was something amiss.

Turns out, I can get great prints from glabels, but only if I set my printer's DEFAULT print-quality settings to their highest level, which is impractical for everyday printing and wasteful if I forget to change them when printing something less-critical.


Version-Release number of selected component (if applicable):
2.2.4-1.fc10


How reproducible:
Load any image into glabels, place it in the template, and print the label.

  
Steps to Reproduce:
1. Create a label. (I was working with CD labels, specifically.) Put anything at all on it. (A print-resolution image is ideal for this test.)
2. Print to an available printer, leaving quality settings at default.
3. Print again, but adjust the quality settings to anything other than the printer's configured defaults.
4. Adjust printer's default quality settings, and print more tests with varied settings from glabels. Notice that all jobs are again identical, and all match the new configured defaults.

  
Actual results:
Printed labels from two separate jobs are identical.


Expected results:
CD labels that don't look like bad photocopies! ...In other words, printed labels with differing levels of quality, corresponding to settings in the dialog for each job.


Additional info:
I'm using a Brother MFC-5460CN color network printer with the vendor-distributed linux drivers, it's possible this issue is somehow limited to that particular setup. I'm sure it's a glabels issue, though, because:

1. I ran a comparison with OpenOffice Draw (actually a bad test, since its printing support is completely different), printing my label image loaded into a CD template I had lying around. Setting the job options for high quality produced a stunning print, which is when I realized glabels is the problem.

2. Firefox (which DOES use the same print interface as glabels) can print to my printer at varying levels of quality just fine, by adjusting the settings in the print dialog at time of printing.

Comment 1 "FeRD" (Frank Dana) 2009-03-03 10:56:56 UTC
Withdrawing this, my apologies -- I've traced the bug to the vendor-provided wrapper script that drives my printer's configuration.

While it is true that glabels displays the problem where other apps do (may) not, the issue is due to a crashing problem with the script "brprintconf_mfc5460cn", supplied by Brother.

Something that's being sent through by glabels is causing a program that script launches to crash, with the result that per-job configuration is never sent to the printer. firefox and OpenOffice don't seem to be having the same problem, most of the time, but nothing glabels is passing is actually incorrect. It's just better at triggering the bug in the vendor's code.


Note You need to log in before you can comment on or make changes to this bug.