As I followed the printing guide line by line I came across the following problem. $ foomatic-configure -s cups -p Epson-Stylus_Color_880 -c file:/dev/lp0 -n Epson -d gimp-print-ijs Cannot read file /usr/share/foomatic/db/source/driver/gimp-print-ijs.xml! Driver file /usr/share/foomatic/db/source/driver/gimp-print-ijs.xml corrupted, missing, or not readable! Could not run "foomatic-combo-xml"/"foomatic-perl-data"! at /usr/lib/perl5/vendor_perl/5.8.0/Foomatic/DB.pm line 509. This is because where the instructions ask you to type the above command gimp-print has not been emerged yet. The solution is to change code listing 1.2 to the code below. $ emerge cups foomatic gimp-print Also, explanation should be made about the following use flags since they are related to the topic. * foomaticdb * ppds Many thanks.
Regarding the "gimp-print" problem: http://www.gentoo.org/doc/en/printing-howto.xml#doc_chap3 talks about installing a third-party printer driver if you need it. It also mentions that the available ebuilds are for "(..) gimp-print, omni, hpijs, pnm2ppa." In other words, you are asked to emerge those before you start with the "foomatic-configure" script. I'll see what the USE-flags do and if an explanation is needed.
I think it's best just to tell the user to set those USE flags, no? Afaik, foomaticdb is automatically set, and ppds gives you more printing filters...
Hello. Yes. Setting the use flags seems fine as I did do when going through the guide. Also, in the rare cases when foomatic-configure gives errors on execution either due to user error or files being missing there are two additional facts that should be pointed out. (1) In the case, that ppd generation does not work linuxprinting.org offers ready made optimally generated ppd files for many printers. These can be obtained and placed in a suitable location for cups recognition. I have to say that I cannot remember what that location is at this moment. (2) It would also be good to mention that linuxprinting.org is able to confirm which printer driver is best suited for any printer in case grepping does not work. In my case, grepping as instructed in the guide provided no output whatsoever so I went to linuxprinting.org and looked up my printer. It confirmed that my printer (Epson Stylus Color 880) does in fact need to use gimp-print-ijs for best results and also said how well my printer was supported under this driver along with much further useful information. As mentioned before it provides ppd for download also. A small note to say that gimp-print-ijs is generally for Epson may be an idea if you feel is appropriate and accurate. These are for better awareness in case troubleshooting is necessary.
In case that you know what driver to choose (in your case: gimp-print-ijs), how do you proceed? I.e. what arguments do you toss to foomatic-configure?
I did what code listing 4.3 instructed except the second grep statement did not produce any output and the first produced too much output. As an alteration to the first one I did the following. $ cd /usr/share/foomatic/db/source/printer/ $ grep 'Stylus Color 880' * Epson-Stylus_Color_880.xml: <model>Stylus Color 880</model> I couldn't find any way to acquire the driver name without going to linuxprinting.org. Even looking at Epson-Stylus_Color_880.xml did not provide any help other than to say: <en>Works perfectly with GIMP-Print.<p></en> As for foomatic I did same as code listing 4.3. $ foomatic-configure -s cups -p Epson-Stylus_Color_880 -c file:/dev/lp0 -n Epson -d gimp-print-ijs This failed prior to emerging gimp-print but succeeded afterwards.
Created attachment 20690 [details, diff] Patch to printing howto This patchs informs the users to check with the linuxprinting.org site if the grepping fails. It also informs that you can just download ppds for some printers without having to go through all the configuration. Can a docdev please review?
Patch looks good.
version++, date++ :-)
I know, but I never increase the version and date in a patch that needs to be reviewed. Otherwise it could be that someone else patches that document (for another bug) making your patch not apply seemlessly (ofcourse, only one reject, namely the version/date, but still). I rather apply the patch, then manually update date/version, do xmllint and commit it. Like I will do right now :)
