Job 1515 was created by "fake" printer and send to backend http. Job 1516 was received over http and sent to usb backend (as far I understand). If job 1515 was send directly to usb it would produces garbage. Going through http fixes the problem. In my opinion http causes only, that job is first created and later sent in single not interrupted, complete stream to usb backend. In direct case job may be sent in several chunks (and not single single step), because filter "stack" pstops/rastertospl does not produce steady stream. Or pstops/rastertospl stack finishes job (closes output, sends EOF or so) and when it is received by usb backend it interrupts uploading job to the printer (even there are still some data to upload). It is only my guessing, so does it make any sense?
** Attachment added: "error_log" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/898385/+attachment/2620829/+files/error_log -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/898385 Title: Chromium is not able to print on Samsung SCX-3200 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/898385/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
