pappl
pappl copied to clipboard
michaelrsweet
HEIC/HEIF support for AirPrint/iOS
Is your feature request related to a problem? Please describe. So by default doing AirPrint of a photo to an image printer using a newer iOS device the HEIC images get ballooned from 3 MB to a 36+ MB PDF file. Super slow on low bandwidth WIFI as well as IOT printer server devices. To make matters worse, Android devices appear to print MUCH quicker on the same print system only because they only deal with image/jpeg types.
Describe the solution you'd like Support image/heic since that is the path ALL Apple devices are moving to for image printing.
Describe alternatives you've considered I don't have any good options here. The _ipps txt record var of pdl shows the different types the printer supports. If the phone has the image type as HEIC then Apple's implementation will ALWAYS force HEIC->PDF conversion before transmit due to the 'Driverless' printing contract. Apple's going to force EVERYONE to leave image/jpeg and has chosen to burn this bridge and make things difficult for novice users just wanting to print a photo image from their phone to a photo printer via AirPrint.
Additional context I'm happy to test and setup up a test framework to make this happen. I wrongly put this as a bug against CUPS which is not the case. That ticket and more details is located here: https://github.com/apple/cups/issues/5849
@Waxhaw So, you probably want to file a bug with Apple about this, since sending a 36MB PDF is almost certainly not the right answer. I suspect they are doing so to preserve the original color space information vs. sending raster (AdobeRGB or sRGB) or converting to JPEG first (which might result in a slight loss of quality but can include color space information).
Anyways, the available open source HEIF implementations are not ideal. I will look at adapting or writing something for a future PAPPL update.
@Waxhaw So, you probably want to file a bug with Apple about this, since sending a 36MB PDF is almost certainly not the right answer. I suspect they are doing so to preserve the original color space information vs. sending raster (AdobeRGB or sRGB) or converting to JPEG first (which might result in a slight loss of quality but can include color space information).
I have filed an issue. Apple is a difficult entity to deal with. I've filed a bug via the Feedback assistant and assigned the bug against AirPrint from the Photo App on both iOS and iPadOS. FB8922872 is the ID. I also even created an AppleCare incident ticket that 'supposedly' has been escalated to engineering as well. I've been hearing crickets. Thank you for the quick response!
libheif might be usable, but two issues come to mind:
- It is licensed under the LGPL3 whose patent terms are bad for embedded implementations.
- It is written in C++ which is eternally a runtime compatibility nightmare on every platform I've ever used.
Oh, and for the record the HEIF patent situation really sucks. It isn't at all clear how an open source implementation of HEIF is treated by the various licensors, and so any HEIF support I may or may not add will be an OPTIONAL feature of PAPPL and as far removed/separated as possible.
@michaelrsweet Thanks for the info! Sad that Apple has put so much into the new image format with VERY little support to use it correctly in an Open Source environment.
OK, at this point I'm thinking it will be at least 12 or 13 years before the patents have expired, and there is no indication that the patent ~~trolls~~ holders will allow for open source implementations/usage, so I'm closing this bug as 'wontfix'... Sorry...