Created attachment 1961964 [details] Logs using journalctl -f -u cups and journalctl -u cups JID=`lpstat -W all | awk '{print $1}' | awk -F '-' '{print $NF}' | tail -n 1` Description of problem: When I try to print any document (even a test page using the CUPS Web Interface) the printer won't print but will be stuck at "receiving data" Version-Release number of selected component (if applicable): Fedora 38 CUPS 2.4.2 How reproducible: Probably low Steps to Reproduce: 1. Add printer with UTAX's PPD 2. Print anything (e. g. a test page) 3. be stuck at "sending data" Actual results: No printing happens Expected results: Printing Additional info: Printer: UTAX LP 3240 Laser Printer PPD file: LP3240.PPD from https://www.utax.co.uk/wp-content/uploads/2021/05/TALinuxPackages_cCD-cLP_20140115.tar.gz (the official website) It has worked before but suddenly stopped. Unfortunately I don't know if a update caused the problem, since I don't print often. I can print using the generic driver, but it doesn't offer all features.
Created attachment 1961966 [details] The job's log
Created attachment 1961967 [details] CUPS' whole log
Created attachment 1961970 [details] The PPD used
Created attachment 1961971 [details] Filter used
Hi, thank you for reporting the issue! I've tested printing to a file using filter and PPD from the official link and it worked without issue (only the scaling looks quite big, but that's not a change since F37). I would recommend reinstalling your printer with the latest official driver from the link for UTAX LP 3240 - I did a diff of those filters and the one from official website is different than the one you use. Do let me know whether it helps.
Thanks for answering, I've now tried reinstalling the driver I fully removed all files installed by install.sh and then running the install.sh script. This time I noticed that the CUPS Web Interface said “The printer or file do not exist anymore”.
(In reply to twboellhoff+redhat.com from comment #6) > This time I noticed that the CUPS Web Interface said “The printer or file do > not exist anymore”. When does the message appear? If you let the tab with old printer opened, removed the printer and the new printer is called differently, I would expect such error is shown.
The error appears for a few seconds before it then disappears and says the job has been completed. I actually don't know why this error appears, since I will always try to print with the new printer and the printer itself gets stuck on sending (receiving) data.
So the printer is still stuck the same way as it was? With the newly downloaded driver from the link? How do you install the printer? Can you share the exact steps?
Ok, I looked at diffs of job log for my test page and your job log: I see that pdftops function and the binaries started by it (gs and pstops) never finish for you and there is a different page size in the job - maybe the different page size caused this? Can you try to update libcupsfilters, libppd and cups-filters packages? All of them should be now at version 2.0~rc1-1 and upstream changelog says there were a page size related fixes.
Yes, the printer is stuck in the same way as it was before with the driver downloaded from the link I install the printer using the install.sh script: #!/bin/bash if [ ! -d /usr/share/cups/model ]; then sudo mkdir /usr/share/cups/model fi if [ ! -d /usr/share/cups/model/UTAX_TA ]; then sudo mkdir /usr/share/cups/model/UTAX_TA fi sudo cp LP3235.PPD /usr/share/cups/model/UTAX_TA/LP3235.PPD sudo cp LP3240.PPD /usr/share/cups/model/UTAX_TA/LP3240.PPD sudo cp LP3245.PPD /usr/share/cups/model/UTAX_TA/LP3245.PPD sudo cp kyofilter_B /usr/lib/cups/filter/kyofilter_B sudo chmod 555 /usr/lib/cups/filter/kyofilter_B if [ -f /usr/lib/cups/filter/kyofilter_B ] && [ -f /usr/share/cups/model/UTAX_TA/LP3235.PPD ] && [ -f /usr/share/cups/model/UTAX_TA/LP3240.PPD ] && [ -f /usr/share/cups/model/UTAX_TA/LP3245.PPD ]; then echo "Installation completed" else echo "Installation failed" fi I've tried reinstalling them: cups-filters x86_64 1:2.0~rc1-1.fc38 updates 210 k libcupsfilters x86_64 1:2.0~rc1-1.fc38 updates 594 k libppd x86_64 1:2.0~rc1-1.fc38 updates 261 k But still get the same result.
The script installs the driver, not the printer. What steps do you take to install the printer?
Oh, to install I turn the printer on and just use the gnome-settings. It automatically chooses the installed ppd.
Have you tested printing with other file than printer test page? It would be interesting to see what output universal filter gives for you: $ sudo PPD=/etc/cups/ppd/UTAX_TA_LP_3240_LP_4240.ppd CONTENT_TYPE=application/vnd.cups-pdf-banner FINAL_CONTENT_TYPE=application/vnd.cups-postscript /usr/lib/cups/filter/universal 1 user '' 1 '' /usr/share/cups/data/testprint > out.ps Once you enter the command, it would be great if you copied the log output from terminal into a file and attached it here, together with screenshot of out.ps content (attach out.ps as well, if the size is acceptable).
I have only tested printing things other than a test page. The command you send had the wrong path, I fixed it. I will attach the log and file.
Created attachment 1966245 [details] Log of out.ps
Created attachment 1966247 [details] Out.ps Test
Debug logs of of the filter show the filter functions and binaries finish if you run the universal filter, which is different from the actual job :( . We can try filtering the input into an external file and then this file send raw to the printer - this should tell us more whether there is a filter error or communication (between filter chain and backend) error. Please enable file devices in CUPS by: $ sudo -i 's,#FileDevice No,FileDevice Yes,' /etc/cups/cups-files.conf && sudo systemctl restart cups and install new printer as file device, where <printer> is a name you choose: $ sudo lpadmin -p <printer> -v file:/tmp/ps -P /etc/cups/ppd/UTAX_TA_LP_3240_LP_4240.ppd -E The print a test page to the new printer, check the /tmp/ps file and attach it together with its job log. In the end take /tmp/ps and send it raw to the actual printer: $ lp -d UTAX_TA_LP_3240_LP_4240 -o raw /tmp/ps If the output from filtering was correct and there is no issue with communication to the printer, the last command should print test page correctly and it would mean communication between filter chain and backend has problem.
Hey, your first command did not seem to edit the config file, so I edited it manually. I also needed to change the file's permissions. I will attach the CUPS log (made using 'journalctl -f -u cups > log_printtofile'). The output however, is the same as before: the printer gets stuck on "receiving data". Also changing emulation from PCL 6 to KPDL did not help.
Created attachment 1966463 [details] Log of the print to file attempt
Created attachment 1966464 [details] File output in /tmp/ps
(In reply to twboellhoff+redhat.com from comment #19) > Hey, your first command did not seem to edit the config file, so I edited it > manually. I also needed to change the file's permissions. /o\... it was supposed to be 'sudo sed -i' and the rest of command, I'm sorry (the second typo...) > > I will attach the CUPS log (made using 'journalctl -f -u cups > > log_printtofile'). > > The output however, is the same as before: the printer gets stuck on > "receiving data". Also changing emulation from PCL 6 to KPDL did not help. Hmm... I don't see the 'lp -d UTAX_TA_LP_3240_LP_4240 -o raw /tmp/ps' job in the logs... can you get them? The /tmp/ps file is not big (660KB), so we won't stuck the printer due the size, but there looks to be something else in the file which causes the printer to be stuck. When I was checking pdftops filter function code, I saw there are a lot of Brother, Kyocera, Utax related hacks (because their internal postscript interpreters are buggy) which are used if we have matching Manufacturer, but we don't have the manufacturer in the string we compare the manufacturer's name to :) . I've tried to come up with patch - would you mind testing the rpms? https://koji.fedoraproject.org/koji/taskinfo?taskID=101514696
Hey, thanks a lot for creating the patch. It works now. I was able to print the test page no problem using the patched RPM. I will also attach the log from the successful print of the test page. If you need any more logs or something, just let me know otherwise, you may close the issue. Thanks for taking the time to fix the issue!
Created attachment 1966925 [details] Log of the successful print Made using the patched libppd RPM
Posted fix upstream https://github.com/OpenPrinting/libppd/pull/21
FEDORA-2023-26ba19b58b has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-26ba19b58b
FEDORA-2023-26ba19b58b has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-26ba19b58b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-26ba19b58b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-26ba19b58b has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.