Replies: 4 comments 5 replies
-
|
Hi, IIUC you experience the problem when printing via iPhone - have you built our project for your phone? If you haven't, please contact the Apple support for further help. |
Beta Was this translation helpful? Give feedback.
-
|
My setup consists of DNP RX1 and Orange Pi3B running Linux with CUPS and the most recent version of Gutenprint 5.3.5. Everything used to run smoothly and flawlessly until the iOS 17.5.3 update.
Ever since the update, I am able to print; however, the guillotine or the 2-inch cut function is not working.
Wysłane z iPhone'a
… Wiadomość napisana przez zdohnal ***@***.***> w dniu 07.08.2024, o godz. 15:19:
Hi,
IIUC you experience the problem when printing via iPhone - have you built our project for your phone?
If you haven't, please contact the Apple support for further help.
|
Beta Was this translation helpful? Give feedback.
-
|
This is almost certainly the issue with Gutenprint conflating media size with finishing options, using slightly different media sizes to convince CUPS (via PPD files) that there are separate media sizes vs. what gets exposed to iOS over IPP/AirPrint. This functionality will not work and there is active discussion on the Gutenprint developer list on how to fix this (in Gutenprint)... |
Beta Was this translation helpful? Give feedback.
-
|
I should provide some additional context that was sent to me (and led me to tell them to bring it up here) Supposedly, they were able to do 2x6 strip printing just fine until they applied an iOS 17 update. Apple changed something that led to:
Keeping in mind that Gutenprint has only ever supported the "classic" PPD-based CUPS flow, and that all IPP functionality is provided by 3rd-party software layered on top of it, I see these as the salient questions:
From what I can tell, the answer to the first two questions is "yes". Which leads to the final question:
|
Beta Was this translation helpful? Give feedback.
-
|
@speachy I don't think Apple changed anything in iOS 17 WRT the media-col value it sends to a CUPS server. Assuming the user is using some version of CUPS 2.4.x (which is the only version that claims iOS compatibility), they will also need to have configured the list of "ready" media to report to iOS clients (via the "ReadyPaperSizes" directive in cupsd.conf). The default is "Letter,Legal,Tabloid,4x6,Env10" when the default paper size is "Letter" and "A3,A4,A5,A6,EnvDL" otherwise. (CUPS reports the intersection of the ready and supported sizes for each queue - not perfect but better than not working...) It is possible that one of these standard sizes is getting mapped to an alternate size name with the same dimensions. To answer your questions:
No. Run "cupstestppd" on the file and you'll get errors concerning the paper dimensions not matching the size names. Additionally (and this isn't something the PPD checker can test for), the 2-up 2x6 size conflates media size with a finishing process (cutting) which isn't something that the PPD specification allows for. FWIW, there are some standard IPP sizes that are more than 2 ISO sizes stacked on top of each other - A4x[3-9], for example - but there is no notion of cutting those into individual pages and those sizes are unique.
Yes. Having multiple PageSize's with the same PaperDimension is undefined, so you can't depend on which size will match based on the dimensions.
As I said above, I am not aware of any media changes in iOS 17. Which media size matches the list of PPD sizes (sorted by dimensions) is essentially undefined/random, and the size difference needs to be more than 0.5mm (recommended IPP media matching tolerance) for us to distinguish between sizes coming from iOS and more than 0.02mm (CUPS PPD mapping tolerance) for the PPD sizes to not be merged. If someone can provide the PPD file I can run some additional tests to see what, exactly, is happening at each step of the job processing. |
Beta Was this translation helpful? Give feedback.
-
Hmm, I strongly suspect that the user is did not do this. Though come to think of it, they didn't tell me what CUPS version they were using either. (And like any bug report, I know what was reported is lacking possibly significant details, but they were pretty adamant that it worked prior to the iOS update, hence my kicking it upstairs here)
Ah, so the problem stems from the use of the "wXXXhYYY" naming convention? As of Gutenprint 5.3, that's easily (if tediously) changed now that each printer's internal definition fully defines its own PageSizes (instead of having to share a global list). (Though I notice that various manufacturer-supplied PPDs universally eschew Adobe Standard names in favor of something like "P4x6" or "ME_10x15" instead, which cupstestppd merely WARNs about)
With the notable exception of 2x6" strip derivations of larger sizes, N-cut variations nearly universally have different physical dimensions than their standard counterparts -- For example on most of these models, an "6x8-div2" print requires supplying an image 60-ish pixels longer than the "6x8" size -- so in practical terms I don't see a "good" way around implicitly combining that stuff. (Which is why OfficialManufactuerDrivers(tm) nearly exclusively do it this way)
As of 2023-12; every PageSize has a unique PaperDimension. (Or least should have; it's possible I missed some. I'll audit this as part of the manual renaming of all 529 DEFINE_PAPER(...) definitions)
All I have to go on is the specifics of the "it used to work, then stopped with iOS17" report I received. But if the difference in sizes needs to be at least 0.5mm, then that might be the underlying issue here, as with current Gutenprint the sizes differ by only one pont (ie 0.35mm) (A one-point difference was sufficient to resolve this problem for prior iOS versions, according to folks who discovered this workaround by manually editing the PPDs)
Thanks. Do you want it now, or should I wait until after I get rid of those "wXXXhYYY" PageSizes? |
Beta Was this translation helpful? Give feedback.
-
|
If you can send me a PPD before the changes then I can at least confirm what is happening. And then once you have the changes I can look at the "after" PPD to confirm things are working as desired as well... Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Sorry about taking so long, but here's the PPD that's generated by the current code. It doesn't have the pagesize renaming, but it now ensures pagesizes are at least 2pt different from each other. It also has corrections for pagesizes I'd missed, and properly adjusts the imageablearea to compensate for the larger pagesize. cupstestppd hard fails on the file due to an illegal translation string that I still need to deal with. (Thanks to UTF-8 the string is simply too long) |
Beta Was this translation helpful? Give feedback.
-
|
I followed the suggestion you provided to my friend via email, where you instructed to remove 'tow288h432' in the PPD file, and it worked like a charm! Thanks a million to everyone involved in the discussion. |
Beta Was this translation helpful? Give feedback.
-
Hello everyone, I'm looking for help and I hope someone has already had this problem and can help me solve it.
Trying the dnp line and have dnp rx1hs . I am able to get them to print , my issue is I cannot activate the cutter on any of them. It’s odd because the cutter does activate under test, but when printing an actual picture from my camera roll and selecting the 4x6*2 media I cannot get the cutter to activate. Any tips ?
Important note: when printing via an Android phone, it works just fine. Only when printing via iPhone does the
problem persists.
Beta Was this translation helpful? Give feedback.
All reactions