[jira] [Comment Edited] (PDFBOX-3584) Build and test PDFBox with JDK9

["Tilman Hausherr (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PDFBOX-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15738434#comment-15738434 ] 

Tilman Hausherr edited comment on PDFBOX-3584 at 7/20/17 4:13 PM:
------------------------------------------------------------------

There will be some work to do for in PDFDebugger for jdk9:
https://bugs.openjdk.java.net/browse/JDK-8169976
{quote}
Everything is bigger in JDK 9 because we now support hi-dpi and will
display at the size we always should have displayed.
In JDK 8u and earlier Windows would have "auto-scaled" Java windows
except that we told it not to.
Now with very hi-dpi displays that approach is no longer viable so whilst
we still tell windows not to auto-scale, we now display at the correct
size and display as much as possible at "full" resolution.

If you have an image (like splashscreen, or application icons) then
*unless* the application provides ones that are at the higher resolution
we have no choice but to auto scale just as windows would do itself given
the chance.

The glyph rendering in splashscreen is therefore not "glyph rendering" at all.
It is just whole-image scaling.

Perhaps we could make a special case to not auto-scale splashscreen images
unless DPI scale of the display is at least 150%. But I somewhat doubt that
the splashscreen is on screen long enough to matter *AND* this would cause
a tricky problem when that transitions into the API controlled splashscreen.
The size would have to change then and it would be all wrong.

The apparent rendering glitches in the display of PDF-Debugger suggest that
it is rendering to a software BufferedImage it has created at a fixed size like
800x1000 pixels. When we blit that to the display which is at 125% we need
to scale it up to 1000x1250 pixels. So again you get artifacts.
The only solution is to update the app to "not do that". It should draw
to the Swing back-buffer, or query the default transform.
This is NOT a new problem. If they'd printed that BufferedImage it would
have looked god-awful. So apps have always needed to be aware of
the transform. It is just that many ignored it and got away with it - until now.

So the bottom line here is there is nothing we can do on the JDK side for these issues.
You need to contact the app developers. 
{quote}
Currently we just pass the image to JLabel.setIcon(new ImageIcon(image)).


(Update 20.7.2017: that was fixed in PDFBOX-3665)


was (Author: tilman):
There will be some work to do for in PDFDebugger for jdk9:
https://bugs.openjdk.java.net/browse/JDK-8169976
{quote}
Everything is bigger in JDK 9 because we now support hi-dpi and will
display at the size we always should have displayed.
In JDK 8u and earlier Windows would have "auto-scaled" Java windows
except that we told it not to.
Now with very hi-dpi displays that approach is no longer viable so whilst
we still tell windows not to auto-scale, we now display at the correct
size and display as much as possible at "full" resolution.

If you have an image (like splashscreen, or application icons) then
*unless* the application provides ones that are at the higher resolution
we have no choice but to auto scale just as windows would do itself given
the chance.

The glyph rendering in splashscreen is therefore not "glyph rendering" at all.
It is just whole-image scaling.

Perhaps we could make a special case to not auto-scale splashscreen images
unless DPI scale of the display is at least 150%. But I somewhat doubt that
the splashscreen is on screen long enough to matter *AND* this would cause
a tricky problem when that transitions into the API controlled splashscreen.
The size would have to change then and it would be all wrong.

The apparent rendering glitches in the display of PDF-Debugger suggest that
it is rendering to a software BufferedImage it has created at a fixed size like
800x1000 pixels. When we blit that to the display which is at 125% we need
to scale it up to 1000x1250 pixels. So again you get artifacts.
The only solution is to update the app to "not do that". It should draw
to the Swing back-buffer, or query the default transform.
This is NOT a new problem. If they'd printed that BufferedImage it would
have looked god-awful. So apps have always needed to be aware of
the transform. It is just that many ignored it and got away with it - until now.

So the bottom line here is there is nothing we can do on the JDK side for these issues.
You need to contact the app developers. 
{quote}
Currently we just pass the image to JLabel.setIcon(new ImageIcon(image)).

> Build and test PDFBox with JDK9
> -------------------------------
>
>                 Key: PDFBOX-3584
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-3584
>             Project: PDFBox
>          Issue Type: Task
>            Reporter: Tilman Hausherr
>              Labels: jdk9
>         Attachments: gs-bugzilla695582-transparency-fill-stroke.pdf
>
>
> Issue to collect problems and solutions for building and testing PDFBox with JDK9.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org