Bug 133647
|
Description
Kyrre Ness Sjøbæk
2004-09-25 16:35:25 UTC
Created attachment 104321 [details]
A picture of the page described
Just testing with Knoppix on a laptop - adding it there using the cups web interface posed no problems. attaching current, broken config. Created attachment 104529 [details]
The ppd file of the broken install
Created attachment 104530 [details]
the broken printers.conf
Created attachment 104531 [details]
the broken cupsd.conf
Hmm... I got it to work - by configuring it trough cups'es web-interface. But now it is only printing in B/W... Maybe the bug is in some program *creating* the config? What i did in the "localhost:631" interface was to hit "printers" -> "HP2000C"."modify printer" -> "continue" (do not change the name/comment) -> Device: Paralell port #1 -> Make: HP -> Model: DeskJet Series Cups v.1.1 (en) This then stands in the printers info place in "printers": HP DeskJet Series CUPS v1.1 Use system-config-printer to edit this! Location: Printer State: idle, accepting jobs. "CUPS v1.1.21rc2 is ready to print." Device URI: parallel:/dev/lp0 Now printing a test page produces a B/W test page (which is much better that garbage, but still not how it should be...) I now go of doing the same as above, changing just one parameter, the model to "HP New DeskJet series CUPS v.1.1 (en)" and print a test page... And there is colours! Ill attach the new config files. If i have forgotten anything - just ask! Created attachment 104534 [details]
The cupsd.conf which seem to work
Created attachment 104535 [details]
the ppd which seem to work
Created attachment 104536 [details]
the printers.conf which seem to work
Arg... A reeboot, and the problem is back again. (hmm... kudzu altered anything? The printers name hasn't changed, but who knows...) Well, i can now give a better description of how it is distorted. It seems like the printout is "streched" horisontaly. That means that it is all to wide to fit onto the paper. I will attach a picture of what is suposed to be the standard cups testpage. Created attachment 104587 [details]
How a standard CUPS testpage should not look
Please try to create a queue for this printer using system-config-printer (Red Hat menu->System Settings->Printing). Select 'HP' as the manufacturer and '2000C' as the model, if this is not selected automatically. Don't print a test page. After you have added the queue, but before you exit system-config-printer, click on the queue and select 'Edit'. Go to the 'Printer driver' tab and change the driver from hpijs to gimp-print-ijs. Does printing work properly with that configuration? (If not, please don't change any further settings until I ask you to..) Great that someone is looking at it. This is a transcript of what i did: - ssh the box from a nearby fc2 box (X forwarding on) as root - start system config printer (in gui mode) - kill the malfunctioning que (HP2000C) - Create a new que - name: HpNew - Device: local /dev/lp0 (it was automatically detected and configured there) - Select printer manufacturer and model: Hp 2000 C - Finish - No, don't print a test page - Edit HpNew - Printerdriver: not hpijs, but gimp-print-ijs - OK - "use" - just to be shure - Test -> Cups testpage (uppermost entry): Error message: (freely translated from Norwegian) "a problem appeared while sending "CUPS testpage" to que "HpNew" lpr: unable to print file: server-error-service-unavailable" - OK - Close system-config-printer -[root@testpc ~]# /etc/init.d/cups status cupsd kjører ikke (cupsd is not running) -[root@testpc ~]# /etc/init.d/cups start Starter cups: [ OK ] -back into system-config printer -Try to print a test page again - no error messages, just the "does it look good" "yes" "no" - printer starting - Nice test page printed - albeit *very* slowly compared to what that printer is up to. The 'server-error-service-unavailable' thing should be fixed in 1.1.21-5 -- it's an unrelated bug. So the gimp-print-ijs driver works: great. I'll update foomatic to reflect the fact that gimp-print-ijs should be used in preference to hpijs for this model. yeah, sure - it worked, but i have never seen that printer print so sllllloooooowwwww before. It must have taken somethin like 1½-2 minutes to print that page... Before we close this - maybe we should toy a little with the default quality settings? And btw. it looks like the error with hpijs is that it somhow thinks A4 is 2 m wide... Defaults other than 'which driver to use' affect all models that use that driver. The original PPD file did look weird though, like the page size was 0x0. Can you try switching back to hpijs and see if it still gives the same problem? If so, please attach 'printconf-tui --Xexport'. Thanks. I can confirm that switching back to driver "hpijs" makes the printer
spit out what looks like the leftmost part of a 2 metres widw, normal
heigth (A4) cups test page.
By my crude meassurement, i would say that there in the borked output
is 94,5 mm from the rigthmost side of the left black border to the C
in the "C Unix printing system" logo at the bottom left - in the
not-so-borked output there is only about 12 mm. Verticaly, it is
perfectly alligned. The output is only streched horisontally.
Did i mention that the hpijs only used ½ minute to produce the
(borked) page? And that is before calibration of print quality etc.
Here is the output you asked for (with the hpijs driver):
[root@testpc ~]# printconf-tui --Xexport
<?xml version="1.0"?>
<adm_context VERSION="0">
<id NAME="local" SERIAL="1096907398">
<null/>
<null/>
</id>
<datatree>
<printconf TYPE="LIST">
<print_queues TYPE="LIST">
<HpNew ATOMIC="TRUE" TYPE="LIST">
<alias_list ANONYMOUS="TRUE" TYPE="LIST">
</alias_list>
<queue_description TYPE="STRING" VALUE=""/>
<queue_type TYPE="STRING" VALUE="LOCAL"/>
<queue_data TYPE="LIST">
<local_printer_device TYPE="STRING" VALUE="/dev/lp0"/>
</queue_data>
<filter_data TYPE="LIST">
<print_header_page TYPE="BOOL" VALUE="FALSE"/>
<flags TYPE="LIST">
<rerender_Postscript TYPE="BOOL" VALUE="FALSE"/>
<convert_text_to_Postscript TYPE="BOOL" VALUE="TRUE"/>
<send_FF TYPE="BOOL" VALUE="FALSE"/>
<assume_data_is_text TYPE="BOOL" VALUE="FALSE"/>
<send_EOT TYPE="BOOL" VALUE="FALSE"/>
</flags>
<mf_type TYPE="STRING" VALUE="MFOMATIC"/>
<filter_locale TYPE="STRING" VALUE="C"/>
<printer_id TYPE="STRING" VALUE="HP-2000C"/>
<gs_driver TYPE="STRING" VALUE="hpijs"/>
<foomatic_defaults ANONYMOUS="TRUE" TYPE="LIST">
<option_default TYPE="LIST">
<name TYPE="STRING" VALUE="PageSize"/>
<type TYPE="STRING" VALUE="enum"/>
<default TYPE="STRING" VALUE="A4"/>
</option_default>
</foomatic_defaults>
</filter_data>
<filter_type TYPE="STRING" VALUE="MAGICFILTER"/>
<jobsheets TYPE="LIST">
<start TYPE="STRING" VALUE="none"/>
<end TYPE="STRING" VALUE="none"/>
</jobsheets>
<margins TYPE="LIST">
<top TYPE="INT" VALUE="36"/>
<right TYPE="INT" VALUE="36"/>
<bottom TYPE="INT" VALUE="36"/>
<left TYPE="INT" VALUE="36"/>
</margins>
<lpoptions TYPE="LIST">
<cpi TYPE="STRING" VALUE="12"/>
<lpi TYPE="STRING" VALUE="7"/>
<page-bottom TYPE="STRING" VALUE="86"/>
<page-left TYPE="STRING" VALUE="57"/>
<page-right TYPE="STRING" VALUE="57"/>
<page-top TYPE="STRING" VALUE="72"/>
<scaling TYPE="STRING" VALUE="100"/>
<wrap TYPE="STRING" VALUE="true"/>
</lpoptions>
</HpNew>
</print_queues>
<sharing_globals TYPE="LIST">
<browsing TYPE="BOOL" VALUE="TRUE"/>
</sharing_globals>
</printconf>
</datatree>
</adm_context>
[root@testpc ~]#
How about if you change /etc/cups/ppd/HpNew.ppd so that line 127 reads: *FoomaticRIPOptionSetting PageSize=A4: " -dDEVICEWIDTHPOINTS=300 -dDEV&& (i.e. change '595' to '300') and restart cups? Created attachment 104729 [details]
no, still broken
the page to the left is the new output. It seems *quite* broken.
Created attachment 104730 [details]
the changed ppd file
Tomorrow foomatic-3.0.2-2 will be available. Please try that -- it should default to the gimp-print driver now. Honestly - that isn't a solution. Yesterday i tried to use the print a 27 page pdf (7 mb) - a report i had written in LyX. With the Gimpprint driver. What happened? Well... the memory usage increased exponentially, and when all the swap was used up, it started killing processes. I couldn't even log on to a VT to kill gs - i guess there wasn't enough memory to start pam... => ended up killing the process by pulling the plug of the computer. Yes i had little time, yes it was the testmachine so i couldn't loose data. (don't ask me why it killed wnck applet and not gs...) The postcript generated by pdf2ps was almost 300 MB. As soon as i get hold of the SuSE 9.1 personal cd again (it worked there), i shall dd the fedora partitions over to my main disk, install suse, get the ppd's etc, and well talk again. Yes i shall test the new rpm. But this bug is not fixed by defaulting to gimp-print which hangs the computer if you try to print something heavyer than a pure text file. *reopening* Kyrre, which feels really nasty right now. Comment #13 made me think that gimp-print gave correct output, just slowly. I had no idea it would cause such bad effects. Reverting the change. foomatic-3.0.2-3 restores the status quo. ill get suse (where it worked) tomorrow, and grab the ppd from there. Sure, i can get you ssh as well. Just BE WARNED: i am on an ISDN line. i also dont expect to get it online before around 20:00 local time (Oslo/Norway/Europe). You migth contact me by jabber: kyrsjo or msn: kyrsjo. Well I should think you can get it working to some extent using the CUPS native driver like you did in comment #8 -- just do it from the http://localhost:631 interface (and not system-config-printer at all). But ideally we'd like to get hpijs working properly. Ill go plug my fc2 laptop (think it should be the same - fc2 had the same damn problem) into the printer, add the printer trough the port 631 interface, and try to fix it. Okay: Did it. *almost* worked: Selected Hp New as the driver (you know what i mean) - and it basically worked. "imageable area" was a bit different: When using the driver from the web-interface (it was set to A4 in both cases), which i assume is the hpijs driver - i get these on the test page: Imageable area: Page size: 7.76x11.11in 197.2x282.2mm Lower-left: 0.25x0.5in 203.5x294.9mm Upper-Rigth: 8.01x11.61in 203.5x294.9mm Resolution: 300x300 dpi 11781x11781dpm Gimp-print an fc3t2 gives: Page size: 7.99x11.19in 202.9x284.3mm Lower-Left: 0.14x0.5in 3.5x12.7mm Upper rigth: 8.13x11.69in 206.4x297.0mm Resolution: 300x300dpi 11781x11781dpm Gimp-prints definition fitts better on the paper - but both could very well be streched 10 mm longer - if the printer can handle it. If not, gimp-prints definition is better. Hmm... Maybee this is really a system-config-printer bug? Shall i attach the nonborked output from the created setup? BTW the speed of the printer was "okay" now (not perfect). I shall try to print the first page of the doc which effectively crashed the fc3t2 box under gimp-print. doh. Didn't fix it completely, it still runs gs a couple of minutes, before churning wildly away on the disk (from ggv). Acrobat on win32 was almost as bad - the output was in the most horrible quality i ever saw. But it was fast... ahh. took 10-15 minutes of calcs - but its comming now - pretty fast to. Think the reason that it took so long is that it seems to bee a horribly heavy document (took *a while* to render the pdf in lyx... should i see any difference in terms of "time-from-clicking-print-to-printer-starts" if i print the ps instead of the pdf?) But another thing: the pictures now seem very "badly" rasterized - they (almost) look like the work of a modernistic painter playing he is a half-tone printing press (you know what i mean). *** Bug 136397 has been marked as a duplicate of this bug. *** I was just suggesting that *maybe* this is really a system-config-printer bug I understand -- but CUPS uses its own driver. If neither gimp-print nor hpijs support this printer properly they should either be fixed (which I hope to be able to do) or have the 2000C removed from their list of supported models. I am perfectly able to print to the printer from cups - when i have set it up through the web interface. When i set it up through s-c-p, the prints are three times to wide for the paper. Same is case when it is autodetected from kudzu. Yes, I know. When you set up the printer using the CUPS web interface you are using CUPS' own printer driver (hptoraster I think). *This* bug report is that the www.linuxprinting.org recommended driver does *not* work -- and either the recommended driver should be changed or (preferably) the recommended driver should be fixed. Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you! Closing per lack of response to previous request for information. Note that FC3 and FC4 are supported by Fedora Legacy for security fixes only. Please install a still supported version and retest. If it still occurs on FC5 or FC6, please reopen and assign to the correct version. Otherwise, if this a security issue, please change the product to Fedora Legacy. Thanks, and we are sorry that we did not get to this bug earlier. |