Borderless printing to Canon SELPHY CP1500 photo printer (driverless) #492
Comments
|
Could you run the command and attach the output file |
|
On the Ubuntu machine (now running CUPS 2.4.2), the command fails: However, on an older MacBook running CUPS 2.2.9, the command results in: The file Ubuntu with CUPS 2.4.2: MacOS with CUPS 2.2.9: |
|
Should I post the results of one of the other |
|
@porst17 ATTR keyword requested-attributes all,media-col-database in the following ways:
for each of these cases could you run the below command and attach the resulting files here?
|
|
@Ankit3002 Here are the files you requested.
The first two result in |
|
I have investigated and found the possible cause of this bug. The problem was thatthe first margin value in each of the printer IPP attributes I have fixed this now via commit 109981f on the cups-filters 1.x branch. It was already fixed in the second generation of cups-filters, in libcupsfilters. If you are familiar with compiling, you could apply the patch and try it out (or take the current GIT state of cups-filters 1.x). |
|
Thanks for looking into it! I compiled the 1.x branch of cups-filters from source, but it doesn't seem to fix the issue.
|
|
@porst17 Could you run and attach both Also make sure that the |
|
@porst17 could you run the following command and attach
To emulate the printer with the help of your file any user who downloads your file can run the command: and run client software against it: to debug the client software ... |
|
By the way, I have run the above command on my printer, and edited the |
|
Here are the files you requested: Note that the command does not work with this printer. The system's which results in a I hope this still does the job for debugging purposes. The |
|
Thank you very much, @porst17, and especially also thanks for using the alternative test file without I have found out now why my fix did not work for you. Your printer gives different answers in the case of using in the answer. This is missing in the former case, which is the one you used for yesterday's command and which libcupsfilters also uses a fallback when it does not get an answer with I based my fix in cups-filters 1.x on you output with Now, as I see that the problem persisted for you, I have compared your files which you attached on Jan 9, as they are all the same format, and I discovered what I described above. Before I was simply assuming that Now the question is, especially also to @michaelrsweet, how does one "correctly" poll the properties of a driverless IPP printer and how does one interpret them correctly? Important here is especially that @michaelrsweet what is Mac OS exactly doing? Two My suggestion for being safest would be two separate request, one without And also for the parsing of the answers: Where do I have to loo whether borderless printing is available? @michaelrsweet is there a standard on how to poll and how to parse the printer properties data from a driverless IPP printer? |
|
@tillkamppeter The macOS system I used for comparison is an older one running macOS Mojave and cups 2.2.9, which uses a different I don't know if that's what you were asking for, but I wanted to point that out again, just to make sure we are all on the same page. |
|
@tillkamppeter ALL IPP printers are supposed to support the "requested-attributes" attribute with one or more values representing attribute names or groups of attributes: 'all', 'printer-description', and 'job-template' for Get-Printer-Attributes. This has been part of IPP since v1.0 and is called out in both STD 92 (RFC 8011) for the latest IETF IPP/1.1 and in the PWG specifications for IPP/2.0 and IPP Everywhere, not to mention for Apple's AirPrint. So that is the standard for querying attributes. A printer that does not support this is broken, and honestly for the ones that are broken it is really hard to come up with a workaround since the "media-col-database" attribute is only returned when explicitly requested since it is so large compared to the other attributes. Conceptually you could do two separate requests (Get-Printer-Attributes without "requested-attributes" and Get-Printer-Attributes with "requested-attributes" = 'media-col-database', which takes less than twice the amount of time), but you have to decide that you'll be maintaining that hack forever (I never wanted to - make the printer vendors fix their f'ing printers!) Plus the current private API we use for PPD generation expects everything in a single IPP response so you'll need to copy the "media-col-database" attribute from the second response to the end of the first response. The first troubleshooting step for any printer with this problem is to update the firmware on the printer. The various macOS software lists all of the attributes they care about explicitly in "requested-attributes" or uses the defaults (if "media-col-database" isn't necessary). The macOS "ipp2ppd" program (AirPrint PPD generator) also does multiple Get-Printer-Attributes requests. WRT detecting borderless support, you want to look at media-col-database and media-col-ready (for loaded media) - not all sizes will support borderless so you look for entries with 0 margins. |
|
Actually, updating the printer firmware was the first thing I did during the troubleshooting process. The most recent version (1.0.1.0, 1.32) was installed before I opened this issue in the bug tracker. From a developer perspective, I totally understand that you don't want to introduce special treatments of non-conformant printers. From the perspective of the end-user, there is not much I can do to "fix" broken printer firmware. I could call the Canon 1st-level support, but they will probably not even understand the problem, because "it's just working on Windows, macOS, Android and iOS". 🙁 |
|
@porst17 could you create a queue with the following command: Does this queue allow borderless printing? This uses CUPS' internal functionality to poll the properties of a driverless IPP printer and to generate the PPD file. |
"media-col-ready" lists the loaded media, in contrary to "media-ready"
as list of complete descriptions of the media ("media-col" data
structure). This often lists also variants like borderless (it is the
same physical paper).
This can for example make borderless printing work if
"media-col-database" is not available. See
OpenPrinting/cups-filters#492
…tribute
"media-col-ready" lists the loaded media, in contrary to "media-ready"
as list of complete descriptions of the media ("media-col" data
structure). This often lists also variants like borderless (it is the
same physical paper).
This can for example make borderless printing work if
"media-col-database" is not available. See
#492
Backported from libcupsfilters (2.x), commit 3b9ec4aa55
|
Parsing "media-col-ready" in addition helps in this case as the borderless variant is listed. The PPD contained the borderles variant only for the paper size currently loaded, though, not for the other sizes. I have commited the change to both libcupsfilters 2.x and cups-filters 1.x now. |
To get the full set of printer properties from a driverless IPP
printer one does a "get-printer-attributes" IPP request with the
attribute "requested-attributes" set to "all,media-col-database" (note
that "all" does not include "media-col-database" because this
attribute is often very long, it contains all valid combinations of
media size, media type, media source, and margins). For some printers
this fails and we fall back to just "all" and lose valuable
information.
But some of those printers which do not support "requested-attributes"
set to "all,media-col-database" support "requested-attributes" set to
"media-col-database" alone and this we now make use of, by polling
"media-col-database" separately and adding it to the IPP response of
"all" if needed.
We discovered such a printer here:
OpenPrinting/cups-filters#492
To get the full set of printer properties from a driverless IPP
printer one does a "get-printer-attributes" IPP request with the
attribute "requested-attributes" set to "all,media-col-database" (note
that "all" does not include "media-col-database" because this
attribute is often very long, it contains all valid combinations of
media size, media type, media source, and margins). For some printers
this fails and we fall back to just "all" and lose valuable
information.
But some of those printers which do not support "requested-attributes"
set to "all,media-col-database" support "requested-attributes" set to
"media-col-database" alone and this we now make use of, by polling
"media-col-database" separately and adding it to the IPP response of
"all" if needed.
We discovered such a printer here:
#492
Backported from libcupsfilters (2.x), commit 789cca62da
|
I have also added now a separate poll for "media-col-database" , for the case that it did not get obtained in the first place. This way we get a much higher probability to not miss important info about the printer. Especially we get then borderless only for the sizes actually supporting it, and not for every size when we fall back to "media-size-supported" or "media-supported" due to lack of "media-col-database". @porst17 can you test with this now? Do you get borderless for all page sizes now? |
|
I tested 54608f9 (1.x branch) and it works flawlessly. The result of |
|
@porst17 thanks a lot for your feedback. One last thing I want to ask you for: Could you attach your print queue's current PPD file (from @michaelrsweet It seems that having the |
|
The requested PPD file: SELPHY-CP1500.ppd 🤝 |
|
Thank you very much @porst17 . This looks absolutely correct for me now and shows all 3 page sizes also in a borderless variant. Only with the "media-col-ready" parsing added one gets the borderless variant only for the loaded size, in your case Postcard, with the separate poll of ¨media-col-database" one gets borderless for all sizes. |
|
@michaelrsweet , is there a person from Canon in PWG? I recall we (in CUPS) had a similar report, where a Canon printer wasn't able to answer to a request with In general Canon IPP firmware looks problematic - we have two printers in our office which can't give a valid IPP response (they put a collection into 1setof keyword type attribute...), so having some person in Canon would help. But I can understand why some people can make a mistake in this (RFC 8011 - Get Printer Attributes operation): Some people can understand it as the client can ask for attribute names or attribute group names exclusively because of |
|
@zdohnal but assuming that this form of mis-understanding is there and is the possible reason why "all,media-col-database" requests fail on many printers does not only explain that these failures are rather common but also justifies that in cups-filters and also in CUPS we should have a fallback to poll the two separately (what I did in cups-filters now) or even poll the two separately in the first place. So I again highly recommend to do this in CUPS, @michaelrsweet ... Such a software workaround can be done by us immediately (as I did in cups-filters), getting all manufacturers fixing their firmware on all models, all users finding out that there is new fixed firmware, ... will take ages or, most probably never get completed ... |
|
@tillkamppeter Feel free to tackle updating and maintaining this workaround code, but I don't have the bandwidth. And honestly if it was all Canon printers I might be more concerned but so far it looks like a handful of models. I am forwarding this issue to the Canon PWG rep (Steven Young)... |
|
@michaelrsweet the addition which I would do to CUPS for the separate poll of "media-col-database" is small, the same ~20 lines I already have added to the two generations of cups-filters. Not much work to add an d maintain. So I think I will do it. |
In the create_local_bg_thread() function for auto-generating a PPD
file for a CUPS queue for a driverless printer, either via the
"everywhere" model selection or an auto-created temporary queue we
need to query the full capabilities information from the printer.
To get the full set of printer properties from a driverless IPP
printer one does a "get-printer-attributes" IPP request with the
attribute "requested-attributes" set to "all,media-col-database" (note
that "all" does not include "media-col-database" because this
attribute is often very long, it contains all valid combinations of
media size, media type, media source, and margins). For some printers
this fails and we fall back to just "all" and lose valuable
information.
But some of those printers which do not support "requested-attributes"
set to "all,media-col-database" support "requested-attributes" set to
"media-col-database" alone and this we now make use of, by polling
"media-col-database" separately and adding it to the IPP response of
"all" if needed.
We discovered such a printer here:
OpenPrinting/cups-filters#492
|
@michaelrsweet or is the "ultimative" solution for this problem how you are doing in libcups3 in the Here you first poll only |
|
@tillkamppeter The printers having trouble with "all,media-col-database" will have the same issues with the other group names... |
|
So we need to do the same thing in CUPS 3.x ... |
I am trying to set up the Canon SELPHY CP1500 network photo printer on Ubuntu 22.04 (cups 2.4.1) for borderless printing. When printing on macOS, the print dialog offers borderless medias in the media selection dialog. When printing on Android (Mopria), there is a dedicated toggle for "Borderless".
On Linux, however, there is neither "borderless" media to select nor a dedicated "Borderless" option. In the CUPS web interface, the printer's Make and Model is listed as "Canon SELPHY CP1500 HTTP, driverless, cups-filters 1.28.15".
The generated PPD file (internally via the
driverlesscommand?) contains the lineand all photo prints have a white margin around the actual content.
After editing the PPD by hand and setting
the photos are printed borderless as expected.
I also played with
ipptooland was able to send JPEG images directly to the printer using the following IPP file:Images send this way are also printed borderless on the CP1500.
There seems to be something wrong with how the
ImageableAreaof the PPD is determined.For debugging purposes, I attached the PPD output and debug log of
The PPD generated by the above is identical to
/etc/cups/ppd/Canon-SELPHY-CP1500.ppd.Canon-SELPHY-CP1500.ppd:debug.log:The text was updated successfully, but these errors were encountered: