On Tue, 7 Apr 2026 11:26:32 GMT, GennadiyKrivoshein <[email protected]> wrote:
>> These changes fix https://bugs.openjdk.org/browse/JDK-8372952 "Respect >> landscape orientation user selection on macOS and Linux". >> >> There are three issues which cause this bug. >> #### The first issue >> Media printable area does not match the corresponding media size for the >> landscape-oriented medias. \ >> An example of the actual prints on a paper 80mmx40mm (Epson T-TA88V) >> [actual_cut_off.pdf](https://github.com/user-attachments/files/25064646/actual_cut_off.pdf) >> >> #### The second issue >> _MediaSize_ does not allow landscape-oriented medias (X dimension bigger >> than Y dimension of the media) so rotated size is used, but the media >> printable area stays the same - landscape-oriented. >> Current implementation does not allow to use landscape-oriented paper >> because _MediaSize_ >> constructor allows portrait paper only (width < height). >> >> I read comments about _MediaSize_ restrictions (width<height) in >> https://bugs.openjdk.org/browse/JDK-8041911, which states that this is "by >> design" and specification. But I did not find media size restrictions in the >> https://datatracker.ietf.org/doc/html/rfc2911. >> The RFC defines "orientation-requested" attribute, that was mentioned in the >> JDK-8041911 comments, but this attribute indicates the desired orientation >> for printed print-stream pages and is used for only a subset of the >> supported document formats ('text/plain' or 'text/html') to format the >> document. \ >> As described in the RFC >> https://datatracker.ietf.org/doc/html/rfc2911#section-15.3 >>> If the document data has been formatted, then go to step 2. Otherwise, the >>> document data MUST be formatted. The formatting detection algorithm is >>> implementation defined and is not specified by this document. The >>> formatting of the document data uses the "orientation-requested" attribute >>> to determine how the formatted print data should be placed on a >>> print-stream page >> >> Therefore, if a printer object uses a landscape-oriented paper, a document >> format is "text/plain" and an "orientation-requested" attribute contains >> "portrait" value then the printer object should rotate the document 90 >> degrees. \ >> If a printer uses a portrait-oriented paper, a document format is >> "text/plain," and an "orientation-requested" attribute contains value >> "portrait" then the printer object does no rotation. >> >> Also, https://datatracker.ietf.org/doc/html/rfc3382 defines a "media-size" >> IPP attribute which identifies the size of the media. The RFC contains an >> example of this attribute where the ... > > GennadiyKrivoshein has updated the pull request incrementally with one > additional commit since the last revision: > > Add warnings into MediaPrintableAreaTest Looks like my review comments did not get posted. Let's try again over here. This PR is not an easy one to follow all the consequences "When using landscape paper (the paper width > the paper height), the printed content is cut off on Linux and Mac." I think it might then be easiest to focus entirely on Linux, and be happy with that first because you are changing a lot of stuff on macOS. public static CustomMediaSizeName create(String name, String choice, 200 float width, float length) { IIRC, this bubbles up to the app as a reported paper size that is enumerated via Java API. So it has to be valid MediaSize per the Java SE spec which says MediaSize is a two-dimensional size valued printing attribute class that indicates the dimensions of the medium in a portrait orientation, with the X dimension running along the bottom edge and the Y dimension running along the left edge. Thus, the Y dimension must be greater than or equal to the X dimension. try { new MediaSize(width, length, Size2DSyntax.INCH, value); } catch (IllegalArgumentException e) { /* PDF printer in Linux for Ledger paper causes "IllegalArgumentException: X dimension > Y dimension". - We rotate based on IPP spec. */ - new MediaSize(length, width, Size2DSyntax.INCH, value); + */ + CustomMediaSize.create(width, length, Size2DSyntax.INCH, value); Ok .. so this creates a sub-class instead, but re-trying with the already rejected w/h Oh .. but you then do this public static CustomMediaSize create(int x, int y, int units, MediaSizeName media) { CustomMediaSize cms; if (x > y) { cms = new CustomMediaSize(y, x, units, media, LANDSCAPE); } else { cms = new CustomMediaSize(x, y, units, media, PORTRAIT); } Ok, that lets you construct it . But then you go right ahead and break the API contract because you over-ride all the getters to swap things around public float getX(int units) { return orientation == PORTRAIT ? super.getX(units) : super.getY(units); } Also since you don't over-ride every super-class method (just the ones that mattered to your use case) so it is inconsistent. That would be fixable, but the API contract is the real issue. So a different solution is needed. - Changing the API contract would be only for the future - But why does it need to change ? Why do printers not understand what portrait format is ? Maybe relaxing the spec is our best real answer here rather than fighting this, but it is moot if you need a fix that can be applied to existing releases. You will need to fix it with transformations that do not bubble up into API ------------- PR Review: https://git.openjdk.org/jdk/pull/29560#pullrequestreview-4210061214 PR Comment: https://git.openjdk.org/jdk/pull/29560#issuecomment-4356809172
