Bug 719390 - f[15/16/17/18] vs. high-resolution, larger-format printing
Summary: f[15/16/17/18] vs. high-resolution, larger-format printing
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: cups
Version: 18
Hardware: All
OS: Unspecified
high
high
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-06 16:52 UTC by Benjamin Kosnik
Modified: 2014-02-05 11:49 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-05 11:49:30 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
inkscape SVG file, super B page size with hairlines (120.04 KB, image/svg+xml)
2011-07-06 16:52 UTC, Benjamin Kosnik
no flags Details
epson stylus photo r2400, f15 configure (653.83 KB, application/vnd.cups-ppd)
2011-07-07 17:09 UTC, Benjamin Kosnik
no flags Details
epson stylus photo r2400, f15 foomatic config (43.39 KB, application/vnd.cups-ppd)
2011-07-07 17:10 UTC, Benjamin Kosnik
no flags Details
epson stylus photo r2400, mac os x 10.6.8 ppd (28.59 KB, application/octet-stream)
2011-07-07 17:37 UTC, Benjamin Kosnik
no flags Details
epson stylus photo r2400, f14 foomatic config (43.38 KB, application/vnd.cups-ppd)
2011-07-07 18:55 UTC, Benjamin Kosnik
no flags Details
epson stylus photo r3880, f18 configure (827.00 KB, text/plain)
2012-11-26 19:32 UTC, Benjamin Kosnik
no flags Details
epson stylus photo r3880, f18 openprinting configure (22.07 KB, text/plain)
2012-11-26 19:33 UTC, Benjamin Kosnik
no flags Details

Description Benjamin Kosnik 2011-07-06 16:52:35 UTC
Created attachment 511536 [details]
inkscape SVG file, super B page size with hairlines

Description of problem:

Larger-format, high-resolution printing with foomatic-derived drivers broken in F15. This is a regression from F14.

Version-Release number of selected component (if applicable):

%rpm -qa | grep cups | sort
cups-1.4.7-3.fc15.x86_64
cups-devel-1.4.7-3.fc15.x86_64
cups-libs-1.4.7-3.fc15.i686
cups-libs-1.4.7-3.fc15.x86_64
cups-pk-helper-0.1.2-1.fc15.x86_64
ghostscript-cups-9.02-1.fc15.x86_64
gutenprint-cups-5.2.7-3.fc15.x86_64
libgnomecups-0.2.3-9.fc15.x86_64
pips-spr2400-cups-2.6.4-1.i386
python-cups-1.9.57-1.fc15.x86_64

%rpm -qa | grep gutenprint
gutenprint-foomatic-5.2.7-3.fc15.x86_64
gutenprint-extras-5.2.7-3.fc15.x86_64
gutenprint-cups-5.2.7-3.fc15.x86_64
gutenprint-5.2.7-3.fc15.x86_64

%rpm -qa | grep foomatic
gutenprint-foomatic-5.2.7-3.fc15.x86_64
foomatic-db-filesystem-4.0-28.20110221.fc15.noarch
foomatic-db-ppds-4.0-28.20110221.fc15.noarch
foomatic-4.0.7-2.fc15.x86_64
foomatic-filters-4.0.7-2.fc15.x86_64
foomatic-db-4.0-28.20110221.fc15.noarch

How reproducible:

Print the included inkscape svg file, which includes hairlines on a SuperB page size, ie 13 x 19, at resolutions of 2880 x 1440, on a Fedora 15 system that has been set up to use foomatic + epson PPDs. 

Try the following methods:
a) "print" dialogue from within inkscape (right page size, wrong res)
b) "save as" dialogue from within inkscape, save as PDF (right page size, wrong resolution)
c) "save as" dialogue from within inkscape, save as PostScript (wrong page size, right resolution)

None of these three combinations will get both the resolution and page size correct. This is a regression from F14.

From what I can tell, there has been a change to use poppler instead of foomatic-rip to send to cups. (In addition to now having to do all driver config via localhost:631..... but that's for the next bug report) Is this correct? Does this account for the difference between the PDF and PS files above? Is there a way to use foomatic-rip instead of poppler on Fedora 15?

Steps to Reproduce:
1. open attached file in inkscape on F15 machine
2. print
3. be amazed at the wasted ink
  
Actual results:

lower-res, pixelated print with line weights off > 100%

Expected results:

high-res print with correct line weights

Additional info:

Comment 1 Tim Waugh 2011-07-07 08:39:55 UTC
Please attach the PPD you are using, from /etc/cups/ppd.

Comment 2 Benjamin Kosnik 2011-07-07 17:09:34 UTC
Created attachment 511757 [details]
epson stylus photo r2400, f15 configure

Comment 3 Benjamin Kosnik 2011-07-07 17:10:04 UTC
Created attachment 511758 [details]
epson stylus photo r2400, f15 foomatic config

Comment 4 Benjamin Kosnik 2011-07-07 17:37:13 UTC
Created attachment 511764 [details]
epson stylus photo r2400, mac os x 10.6.8 ppd

Comment 5 Benjamin Kosnik 2011-07-07 18:55:21 UTC
Created attachment 511782 [details]
epson stylus photo r2400, f14 foomatic config


Not known good, as that one is gone, but this is a reconstruction configured in the same manner

Comment 6 Tim Waugh 2011-07-08 09:00:36 UTC
I'd expect the PPD from comment #2 to give best results, i.e. the one with fewer moving parts.

It would be very useful to be able to see the IEEE 1284 Device ID for this printer, a string containing things like "MFG:" and "MDL:".  Could you please run these commands?:

su -c 'lpinfo -l -v'
/usr/lib/cups/backend/snmp $HOSTNAME

(where $HOSTNAME is the hostname or IP address of the printer, assuming it is network-connected.)

In the mean time I'll take a look at the raster output to see if I can reproduce it on-screen.

Comment 7 Benjamin Kosnik 2011-07-08 15:51:08 UTC
usb:

%lpinfo -l -v
Device: uri = usb://EPSON/Stylus%20Photo%20R2400
        class = direct
        info = EPSON Stylus Photo R2400
        make-and-model = EPSON Stylus Photo R2400
        device-id = MFG:EPSON;CMD:ESCPL2,BDC,D4;MDL:Stylus Photo R2400;CLS:PRINTER;DES:EPSON Stylus Photo R2400;
        location =

Comment 9 Tim Waugh 2011-07-20 15:27:49 UTC
I tried option (a), capturing the data file from /var/spool/cups and performing filter transformations on it by hand to get to raster format.

Unfortunately, because of the huge dimensions of the raster file, rasterview refuses to let me view it.  Looking at the metadata with hexdump though, the page size is 13"x19" as expected and the hardware resolution is set to 2880x2880 (possibly rows are doubled up making it really 2800x1440?).

More investigation needed.

Comment 10 Benjamin Kosnik 2011-07-27 15:14:00 UTC
I've moved back to F14 for the time being for hi-res output.

Yes, this is a large page size. However, it is a standard photographic print size, even though it may not be heavily used by office workers.... hate to break it to you, but on F14 I can print out hi-res files at twice this "huge" size. (Ie, custom 13 x 38" page sizes). 

So something is definitely wrong on F15.........

Comment 11 Benjamin Kosnik 2011-10-26 18:01:42 UTC
This is still very broken on F16. I'm adjusting the severity of this bug since it is a regression preventing me from updating to latest Fedora and the last release that works is soon to be discontinued.

Comment 12 Benjamin Kosnik 2012-11-26 19:27:37 UTC
Hey Tim. This has been bugging me for some time.

The printer I was using at the time of this originating bug report has been retired.

However, I have been able to confirm that this bug is still present in F17/F18, ie trunk development with another large format printer. See this link for more details:
http://sunglint.wordpress.com/2012/11/22/epson-3880-vs-linux-printing/

To work around this, I am using fedora for document creation, printing as PDF in inkscape, and then taking the linux-generated pdf file and printing it on mac os. 

Boo.

Printing the generated pd on linux leads to much frustration as the prints have rasterization/resolution issues. Is there anything else I can try? 

Any commentary appreciated. I'm thinking of trying to port the lsb/RHEL5 drivers to fedora, in an effort similar to epson-inkjet-printer-escpr, ie something like epson-large-format-printer-escpr.

I notice that many of the filters used in the apple PPD are in the propsed cups-filters package. Do you think this package, and these filters, would help?

Are there ways to manipulate the resolution or raserization of the Gutenprint drivers?

This is a tremendous quality regression in the linux printing stack! This seems likely to be an issue that surfaces for RHEL7 as well.

Comment 13 Benjamin Kosnik 2012-11-26 19:30:01 UTC
ulloa config, has two network printers

 lpinfo -l -v

Device: uri = dnssd://Samsung%20CLP-310%20Series%20(clp-315w)._printer._tcp.local/
        class = network
        info = Samsung CLP-310 Series (clp-315w)
        make-and-model = Samsung Samsung CLP-310 Series
        device-id = MFG:Samsung;MDL:CLP-310 Series;FZY:1;
        location = 
 
Device: uri = dnssd://EpsonStylusPro3880-1F71E2._printer._tcp.local/
        class = network
        info = EpsonStylusPro3880-1F71E2
        make-and-model = EPSON Epson Stylus Pro 3880
        device-id = MFG:EPSON;MDL:Epson Stylus Pro 3880;FZY:0;
        location =

Comment 14 Benjamin Kosnik 2012-11-26 19:32:17 UTC
Created attachment 652225 [details]
epson stylus photo r3880, f18 configure

Comment 15 Benjamin Kosnik 2012-11-26 19:33:28 UTC
Created attachment 652227 [details]
epson stylus photo r3880, f18 openprinting configure

Comment 17 Fedora End Of Life 2013-12-21 08:28:27 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 19 Fedora End Of Life 2014-02-05 11:49:33 UTC
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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