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
%rpm -qa | grep gutenprint
%rpm -qa | grep foomatic
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
3. be amazed at the wasted ink
lower-res, pixelated print with line weights off > 100%
high-res print with correct line weights
Please attach the PPD you are using, from /etc/cups/ppd.
Created attachment 511757 [details]
epson stylus photo r2400, f15 configure
Created attachment 511758 [details]
epson stylus photo r2400, f15 foomatic config
Created attachment 511764 [details]
epson stylus photo r2400, mac os x 10.6.8 ppd
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
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'
(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.
%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;
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.
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.........
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.
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:
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.
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.
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;
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;
Created attachment 652225 [details]
epson stylus photo r3880, f18 configure
Created attachment 652227 [details]
epson stylus photo r3880, f18 openprinting configure
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.
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
Thank you for reporting this bug and we are sorry it could not be fixed.