On 28-Jan-19 12:23 AM, Philip Race wrote:
This seems to invalidate the preceding comment as well as contradict
it's intent :
/* The printed text must scale linearly with the UI.
519 * Calculate the width on screen, obtain a TextLayout with
520 * advances for the printer graphics FRC, and then justify
521 * it to fit in the screen width. This distributes the
spacing
522 * more evenly than directly laying out to the screen
advances.
523 */
I am not sure when
531 if (!isFontRenderContextPrintCompatible(frc, deviceFRC)) { would
return "false" since we are in an isPrinting() block and you are
comparing the screen and printer FRCs, so then you will inevitably end
up calling 532 layout = createTextLayout(c, text, g2d.getFont(), frc);
which will create spacing at screen resolution.
In the other two places in this file where a test similar to that at
531 is used,
if the result is that they aren't compatible, then a TextLayout is created
using the deviceFRC .. the opposite of what you are doing here.
In drawStringImpl(), I guess it is doing the same as I am doing (calling
with screen frc if not compatible)
if (isPrinting) {
FontRenderContext deviceFRC = g2d.getFontRenderContext();
if (!isFontRenderContextPrintCompatible(frc, deviceFRC)) {
layout = new TextLayout(iterator, deviceFRC);
AttributedCharacterIterator trimmedIt =
getTrimmedTrailingSpacesIterator(iterator);
if (trimmedIt != null) {
float screenWidth = new TextLayout(trimmedIt, frc).
I am not sure if the comment in l519-523 is introduced in JDK-6488219
(as I am not able to see the fix in JBS)
but since it is claimed that this bug is regression from this fix
onwards, maybe this comment is not sacrosanct.
So I think you will regress
https://bugs.openjdk.java.net/browse/JDK-6488219
Are you running Swing printing tests when you make changes here ?
The bug above is covered by java/awt/print/PrinterJob/SwingUIText.java
but it is manual since pass/fail is a subjective manual verification ..
I ran with / without fix and this looks the same to me.Here's the output
http://cr.openjdk.java.net/~psadhukhan/8214702/print-output-afterfix.pdf
http://cr.openjdk.java.net/~psadhukhan/8214702/print-output-beforefix.pdf
Regards
Prasanta
-phil.
On 1/25/19, 3:41 AM, Prasanta Sadhukhan wrote:
Hi All,
Please find an updated webrev using FontRenderContext compatible to
printer device. With this, swing text with and without leading spaces
are printed ok.
http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.1/
Regards
Prasanta
On 25-Jan-19 11:01 AM, Prasanta Sadhukhan wrote:
On 25-Jan-19 10:57 AM, Philip Race wrote:
On 1/24/19, 8:19 PM, Prasanta Sadhukhan wrote:
On 25-Jan-19 2:00 AM, Phil Race wrote:
I can't work out what you are trying to say.
The changes are only in the printing code path.
However what it looks like to me is that Prasanta is now using
TextLayout for printing only under
the same conditions as we use it on screen -- which is when
"international" text is being rendered.
This will reintroduce clipped text bugs which the existing code
was meant to fix so I don't think it
can be right.
OK. Thanks for the info. I didn't know that as I am not able to
get the fix for JDK-6760148 which is pre 7u23 where mercurial
tracking began.
It may not be pretty or a complete solution but I think we need
to look at breaking the text into
the leading spaces + the rest of the trimmed string and using the
screen advance of the
leading spaces to position the rest of the justified text.
Are you implying the leading spaces in text is making text
justifcation going astray?
Yes.
I have seen even without leading spaces in swing text in console
, the text justification during printing is wrong as I am getting
That is quite different from what you showed earlier.
The earlier embedded image was "with" leading spaces inswing text.
The above was "without"
Regards
Prasanta
The first visible chars are all aligned properly. But all the
adjustment for the width
is being assigned to one space.
For this you will need to look into the text layout justification code.
-phil.
Regards
Prasanta
-phil.
On 1/24/19 9:33 AM, Sergey Bylokhov wrote:
Hi, Prasanta.
On 24/01/2019 02:18, Prasanta Sadhukhan wrote:
Proposed fix is to check if we need text layouting for printing
too as it is done for swing text drawing on console. If we need
text layouting, then only use textlayout justification.
For swing components we skip textlayout by default because of
performance reason(when we know that it should be safe to do),
are you sure that it is safe in your case? Will the text scales
in the same way as the components on which it drawn?
BTW the new codepath missed the call:
g2d.setColor(((PrintColorUIResource)col).getPrintColor());
