Anton,
> On Sep 24, 2025, at 3:55 PM, Anton Thomasson via ipp <ipp at pwg.org> wrote:
> Hi
>> Since the only baseline JPEG is mandatory (for JPEG-supporting printers) i made a little schoolbook lossless baselinifier application.
> However, there is also jpeg-{x,y}-dimension-supported and jpeg-k-octets-supported to take into account.
> Because of this, i'm looking in to the built-in downscaling in libjpeg (and sane derivatives).
> Even though it is limited to a max downscale factor of 8 it should cover even quite extreme cases.
> (This of course includes decompressing and recompressing the image and isn't lossless).
That is why current Clients typically convert unsupported JPEG/PDF files to Apple or PWG Raster - you'll get better quality and have full control over how the image is printed.
> However, with Exif headers adding orientation completely separately, the question of which dimension is which arises.
The Exif metadata information, if present, can provide useful hints to the Printer for things like pixels-per-inch and orientation. However, we have never explicitly defined what the Printer does with that information, merely that it supports the Exif subset/profile of JFIF.
> From what i understand Exif headers are mandatory to support. (And respect?)
The Exif subset/profile of JFIF is mandatory to support for color Printers (recommended otherwise). As I noted above, we don't say anything about what a Printer does with the metadata.
> I'll stick my neck out and say x=width=horizontal and y=height=vertical.
Technically you are talking about how the image is imposed on a media sheet, so horizontal/vertical (or cross-feed/feed) directionality is not implied by the image dimensions. The "orientation-requested" and "print-scaling" Job Template attributes (among others in the "production" space) also get involved since they tell the Printer how the End User wants the image printed, above and beyond whatever size/orientation information that may be present in the image file.
> But with a Exif rotation of +/- 90 degrees, does the constraints apply to before or after transformation?
> I.e. to the data as stored in the JPEG steam or as imaged onto the page.
The Exif metadata tells you how to "present" or "view" the image, so the image data typically is sensor orientation/dimensions while the preview image (in the metadata) is pre-rotated.
I encourage you to grab images from a digital camera and not necessarily from a smartphone, since smartphones often do a lot of post-processing and use something other than JPEG as a primary storage format. If you don't have access to such files I am happy to send you some examples.
> Most printers, sensibly, have the same limit in both dimensions, but i have logs for at least one that doesn't (and of course it has the lowest values).
There might be "valid" reasons why the hardware can't handle (for example) long scanlines but can otherwise handle decoding tall images.
> Is there an official definition, or should one be added?
Official definition of what?
> (And should it maybe be recommended to not have these constraints differ?)
We defined the ranges separately explicitly because some JPEG decode hardware has arbitrary limits that are different in the X and Y dimensions. I hesitate to place any restrictions on this because you will only end up forcing the lower limit in both directions.
________________________
Michael Sweet