Pivot
  1. Pivot
  2. PIVOT-511

Labels doesn't appear in Print from Browser

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.5, 1.5.1, 1.5.2, 2.0, 2.0.1
    • Fix Version/s: 2.0.1
    • Component/s: wtk, wtk-terra
    • Labels:

      Description

      From a Browser, Printing a page, for some reason I have all Labels not in output (see attached pdf, but the same happens with a print to paper).
      With 1.4 it was not so good but labels were present, while in current 1.5 pre-release it seems that all is present but not labels.

      This should be a great fix to have in the final 1.5

      This happens on Win XP and Windows 7, both from latest Firefox and IE 8, and on all Pivot Applets.

      Sandro

      1. Kitchen Sink _ Apache Pivot 1.4.pdf
        154 kB
        Sandro Martini
      2. Stock Tracker _ Apache Pivot 1.4.pdf
        209 kB
        Sandro Martini
      3. Kitchen Sink _ Apache Pivot 1.5.pdf
        94 kB
        Sandro Martini
      4. Stock Tracker _ Apache Pivot 1.5.pdf
        72 kB
        Sandro Martini
      5. Swing_Pivot Demo.png
        18 kB
        Sandro Martini
      6. Swing_Pivot Demo.pdf
        223 kB
        Sandro Martini
      7. Kitchen Sink _ Apache Pivot 2.0.pdf
        84 kB
        Sandro Martini
      8. Java_Printing.pdf
        7 kB
        Andrei Pozolotin
      9. pivot_511 - Applet.launch
        1 kB
        Sandro Martini
      10. Java Printing.pdf
        11 kB
        Sandro Martini

        Issue Links

          Activity

          Hide
          Greg Brown added a comment -

          This is a strange issue. I was able to reproduce the problem in Windows XP, but I don't have any trouble printing in OS X.

          Since printing applets is a bit of an edge case, I don't see any reason to hold up the 1.5 release for this. However, it is something that we should look into for the next release (whether 1.5.1, 1.6, or otherwise).

          Show
          Greg Brown added a comment - This is a strange issue. I was able to reproduce the problem in Windows XP, but I don't have any trouble printing in OS X. Since printing applets is a bit of an edge case, I don't see any reason to hold up the 1.5 release for this. However, it is something that we should look into for the next release (whether 1.5.1, 1.6, or otherwise).
          Hide
          Sandro Martini added a comment -

          Hi Greg,
          Ok don't worry ... and maybe (if possible) in a 1.5.1 (this and maybe some other small ticket), to have the 1.5 a better and long-life release, before making too much changes improvements in the 1.6.

          Bye,
          Sandro

          Show
          Sandro Martini added a comment - Hi Greg, Ok don't worry ... and maybe (if possible) in a 1.5.1 (this and maybe some other small ticket), to have the 1.5 a better and long-life release, before making too much changes improvements in the 1.6. Bye, Sandro
          Hide
          Sandro Martini added a comment -

          Verify also in the appletviewer (of the jdk) if this happens (I don't remember if it has a Print feature), mainly to simplify development tests.

          Suggestions for the fix:

          • in Pivot 1.4 was working, and since Pivot 1.5 no more.
          • TerraLabelSkin extends LabelSkin , so look at its paint() method
          • try to disable double buffering when the graphics is for a printer (but only here ?). So, in detail:
            see if you can detect whether or not the graphics is from a printer (in this case the graphics object may be an instance of java.awt.print.PrintGraphics), and so we can try disabling double-buffering or disabling the scale factor

          Others (less probable):

          • check when the Java Plugin prints, if a dedicated method could be used to have a right print of text
          • take a look at layout method in LabelSkin (It might also have something to do with the transform. here or in another method)
          • or maybe an alpha channel of the text drawn
          Show
          Sandro Martini added a comment - Verify also in the appletviewer (of the jdk) if this happens (I don't remember if it has a Print feature), mainly to simplify development tests. Suggestions for the fix: in Pivot 1.4 was working, and since Pivot 1.5 no more. TerraLabelSkin extends LabelSkin , so look at its paint() method try to disable double buffering when the graphics is for a printer (but only here ?). So, in detail: see if you can detect whether or not the graphics is from a printer (in this case the graphics object may be an instance of java.awt.print.PrintGraphics), and so we can try disabling double-buffering or disabling the scale factor Others (less probable): check when the Java Plugin prints, if a dedicated method could be used to have a right print of text take a look at layout method in LabelSkin (It might also have something to do with the transform. here or in another method) or maybe an alpha channel of the text drawn
          Hide
          Sandro Martini added a comment -

          For tests in eclipse, try to add to tests subproject (under org.apache.pivot.tests) an html page for loading a sample containing some Labels (and possibly not much other components, like BaselineTest or LabelTest) as an Applet, but if possible, using classpath from eclipse projects (without making jars).
          Or try with the Remote Debugging feature in eclipse, running the test applet in a real browser (probably better, but more complex to setup).

          Some hints for example here:
          http://webmoli.com/2009/01/17/debugging-applet-code-using-eclipse/

          Show
          Sandro Martini added a comment - For tests in eclipse, try to add to tests subproject (under org.apache.pivot.tests) an html page for loading a sample containing some Labels (and possibly not much other components, like BaselineTest or LabelTest) as an Applet, but if possible, using classpath from eclipse projects (without making jars). Or try with the Remote Debugging feature in eclipse, running the test applet in a real browser (probably better, but more complex to setup). Some hints for example here: http://webmoli.com/2009/01/17/debugging-applet-code-using-eclipse/
          Hide
          Greg Brown added a comment -

          This appears to be due to our use of font rendering hints provided by the platform to draw text. On Windows, these hints seem to be appropriate for the screen but not for the printer.

          The fix will require us to check for a PrintGraphics in our paint() methods that draw text and use a default font render context rather than the platform font render context in those cases. Instead of this:

          FontRenderContext fontRenderContext = Platform.getFontRenderContext();

          we'll do this:

          FontRenderContext fontRenderContext;
          if (graphics instanceof java.awt.PrintGraphics)

          { fontRenderContext = new FontRenderContext(null, false, false); }

          else

          { fontRenderContext = Platform.getFontRenderContext(); }

          I have prototyped this in LabelSkin and it resolves the problem.

          Show
          Greg Brown added a comment - This appears to be due to our use of font rendering hints provided by the platform to draw text. On Windows, these hints seem to be appropriate for the screen but not for the printer. The fix will require us to check for a PrintGraphics in our paint() methods that draw text and use a default font render context rather than the platform font render context in those cases. Instead of this: FontRenderContext fontRenderContext = Platform.getFontRenderContext(); we'll do this: FontRenderContext fontRenderContext; if (graphics instanceof java.awt.PrintGraphics) { fontRenderContext = new FontRenderContext(null, false, false); } else { fontRenderContext = Platform.getFontRenderContext(); } I have prototyped this in LabelSkin and it resolves the problem.
          Hide
          Greg Brown added a comment -

          I have to say, I'm baffled by this one. Earlier, I thought I was able to reproduce this problem in Windows XP, but now I can't. Using the current, unmodified code for Pivot 2.0, I am able to print unsigned applets just fine. However, for some reason I am unable to print signed applets (the text simply doesn't show up).

          It is very strange. We may need to see if we can get some help from Oracle on this one - I'm out of ideas.

          Sandro, do you want to ping the Java developer forums? Maybe someone there would be willing to take a look.

          Show
          Greg Brown added a comment - I have to say, I'm baffled by this one. Earlier, I thought I was able to reproduce this problem in Windows XP, but now I can't. Using the current, unmodified code for Pivot 2.0, I am able to print unsigned applets just fine. However, for some reason I am unable to print signed applets (the text simply doesn't show up). It is very strange. We may need to see if we can get some help from Oracle on this one - I'm out of ideas. Sandro, do you want to ping the Java developer forums? Maybe someone there would be willing to take a look.
          Hide
          Sandro Martini added a comment -

          Hi Greg,
          in last weeks I've done many searches on this problem, but I've found nothing.

          Now that you have more info on it, I'll try to ask to Java forums, and post the link here, and then I'll post updates here.

          Probably we should give them a plain AWT test applet, because otherwise I fear that we wouldn't get useful info.

          I'm planning to put a test html page to simplify Applet Tests for this with a real browser (and if possible to debug it).

          Show
          Sandro Martini added a comment - Hi Greg, in last weeks I've done many searches on this problem, but I've found nothing. Now that you have more info on it, I'll try to ask to Java forums, and post the link here, and then I'll post updates here. Probably we should give them a plain AWT test applet, because otherwise I fear that we wouldn't get useful info. I'm planning to put a test html page to simplify Applet Tests for this with a real browser (and if possible to debug it).
          Hide
          Sandro Martini added a comment - - edited

          Some articles on this theme (most of them old !!):

          http://download.oracle.com/javase/1.3/docs/guide/awt/designspec/printing.html

          http://download.oracle.com/javase/tutorial/2d/printing/index.html

          http://www.oracle.com/technetwork/java/whitepaper-138442.html

          http://java.sun.com/developer/onlineTraining/Programming/JDCBook/swing.html

          http://java.sun.com/developer/onlineTraining/Programming/JDCBook/awt.html

          Verify if this could help:
          http://download.oracle.com/javase/tutorial/2d/printing/gui.html
          suggest to implement a print() method on containers (and/or maybe on GUI components) ... if/where needed, so maybe in this way we could avoid changes in paint methods.

          Note:
          from what I read probably could be interesting (maybe later) another Test to Print even from an Application (to see if the problem happens also in this case, so the problem could be in some drawing portions of code).

          Show
          Sandro Martini added a comment - - edited Some articles on this theme (most of them old !!): http://download.oracle.com/javase/1.3/docs/guide/awt/designspec/printing.html http://download.oracle.com/javase/tutorial/2d/printing/index.html http://www.oracle.com/technetwork/java/whitepaper-138442.html http://java.sun.com/developer/onlineTraining/Programming/JDCBook/swing.html http://java.sun.com/developer/onlineTraining/Programming/JDCBook/awt.html Verify if this could help: http://download.oracle.com/javase/tutorial/2d/printing/gui.html suggest to implement a print() method on containers (and/or maybe on GUI components) ... if/where needed, so maybe in this way we could avoid changes in paint methods. Note: from what I read probably could be interesting (maybe later) another Test to Print even from an Application (to see if the problem happens also in this case, so the problem could be in some drawing portions of code).
          Hide
          Sandro Martini added a comment -

          Just tried to Print from Firefox 3.6.10 on Windows XP (and Java 6 Update 21),
          and now from trunk (just before the final release of Pivot 2.0), and now all things appears in the Print (the attach screenshot is for reference).

          Ok, the elements inside the print are not the best (horizontally compressed), but much better than with 1.5.x .

          So I close this bug (really o bug under Pivot 1.5.x and not resolved there) because in 2.0 will be fixed.

          Show
          Sandro Martini added a comment - Just tried to Print from Firefox 3.6.10 on Windows XP (and Java 6 Update 21), and now from trunk (just before the final release of Pivot 2.0), and now all things appears in the Print (the attach screenshot is for reference). Ok, the elements inside the print are not the best (horizontally compressed), but much better than with 1.5.x . So I close this bug (really o bug under Pivot 1.5.x and not resolved there) because in 2.0 will be fixed.
          Hide
          Sandro Martini added a comment -

          Resolved in Pivot 2.0, as shown by today's screenshot and print.

          Show
          Sandro Martini added a comment - Resolved in Pivot 2.0, as shown by today's screenshot and print.
          Hide
          Sandro Martini added a comment -

          Just to ensure that the problem is no more existing, add another Print of our reference Demo: Kitchen Sink, to avoid the doubt of "right" behavior with a mixed demo like Swing_Pivot.

          Both tried from a recent build of 2.0, downloaded "live" from here:
          http://ixnay.biz/pivot-demos/

          Show
          Sandro Martini added a comment - Just to ensure that the problem is no more existing, add another Print of our reference Demo: Kitchen Sink, to avoid the doubt of "right" behavior with a mixed demo like Swing_Pivot. Both tried from a recent build of 2.0, downloaded "live" from here: http://ixnay.biz/pivot-demos/
          Hide
          Sandro Martini added a comment -

          Resolved, so now close it.

          Show
          Sandro Martini added a comment - Resolved, so now close it.
          Hide
          Andrei Pozolotin added a comment -

          Sandro:

          can you please open the issue; we still see this problem on macox, windows, linux

          thank you;

          Andrei.

          Show
          Andrei Pozolotin added a comment - Sandro: can you please open the issue; we still see this problem on macox, windows, linux thank you; Andrei.
          Hide
          Sandro Martini added a comment -

          Reopened, by request from Andrei.

          Andrei, the last time I tried this (in Windows) all seems to work (so I closed it), can you post here some more info (and maybe even some screenshot) ?

          Thank you.

          Bye

          Show
          Sandro Martini added a comment - Reopened, by request from Andrei. Andrei, the last time I tried this (in Windows) all seems to work (so I closed it), can you post here some more info (and maybe even some screenshot) ? Thank you. Bye
          Hide
          Sandro Martini added a comment -

          The issue seem to be present even in 2.0 (or in latest trunk, near 2.0.1 final ?), so updated tracking.

          Show
          Sandro Martini added a comment - The issue seem to be present even in 2.0 (or in latest trunk, near 2.0.1 final ?), so updated tracking.
          Hide
          Drazen Dotlic added a comment -

          Sandro,

          I can provide more info on this issue (Andrei is my colleague, so I'm talking about the same issue).

          We have an applet using Pivot 2.0, we'd like to enable printing of its content. Originally, we wanted to print using browser's print functionality. This does not work at all except in IE, so we print from Java. The printing code is very simple and boils down to implementing Printable (we basically draw directly into a PrintContext).

          I noticed a strange discrepancy - the code I wrote that draws text prints fine, but none of the Pivot Labels do.

          Now, the only difference between my code and Pivot's appears to be the exact text API used. Looking into your trunk (http://svn.apache.org/repos/asf/pivot/trunk/wtk/src/org/apache/pivot/wtk/skin/LabelSkin.java), I can see that you are using drawGlyphVector, while I am simply calling drawString.

          Cursory search on the Internet yields several mentions of buggy Java implementations on Mac and maybe Windows, especially with ClearType enabled, but these should have been fixed by now.

          Now, I've tried this on Windows 7 and latest Java 1.6 with and without ClearType enabled and nothing changes. Andrei also tried the same on Linux and Mac (I tried before on a Mac Snow Leopard and got the same result but will re-test again today). I've also tried with Java 1.7 on a Windows XP VM and it still doesn't work.

          Fortunately, the test case is very simple - a single Pivot Window with a Label with a bit of text, run inside an applet viewer debugging session in Eclipse (assuming that's the IDE you're using) and printing directly from the applet viewer to a PDF 'printer' like CutePDF will immediately show the problem (and not waste any paper, go green!).

          Please note that the only thing that doesn't print is text, Label's background color for example prints just fine.

          If you need more information, do let me know.

          Show
          Drazen Dotlic added a comment - Sandro, I can provide more info on this issue (Andrei is my colleague, so I'm talking about the same issue). We have an applet using Pivot 2.0, we'd like to enable printing of its content. Originally, we wanted to print using browser's print functionality. This does not work at all except in IE, so we print from Java. The printing code is very simple and boils down to implementing Printable (we basically draw directly into a PrintContext). I noticed a strange discrepancy - the code I wrote that draws text prints fine, but none of the Pivot Labels do. Now, the only difference between my code and Pivot's appears to be the exact text API used. Looking into your trunk ( http://svn.apache.org/repos/asf/pivot/trunk/wtk/src/org/apache/pivot/wtk/skin/LabelSkin.java ), I can see that you are using drawGlyphVector, while I am simply calling drawString. Cursory search on the Internet yields several mentions of buggy Java implementations on Mac and maybe Windows, especially with ClearType enabled, but these should have been fixed by now. Now, I've tried this on Windows 7 and latest Java 1.6 with and without ClearType enabled and nothing changes. Andrei also tried the same on Linux and Mac (I tried before on a Mac Snow Leopard and got the same result but will re-test again today). I've also tried with Java 1.7 on a Windows XP VM and it still doesn't work. Fortunately, the test case is very simple - a single Pivot Window with a Label with a bit of text, run inside an applet viewer debugging session in Eclipse (assuming that's the IDE you're using) and printing directly from the applet viewer to a PDF 'printer' like CutePDF will immediately show the problem (and not waste any paper, go green!). Please note that the only thing that doesn't print is text, Label's background color for example prints just fine. If you need more information, do let me know.
          Show
          Andrei Pozolotin added a comment - Sandro, test project: https://github.com/carrot-garden/carrot-bugger/tree/master/carrot-bug-pivot-print Adnrei.
          Hide
          Andrei Pozolotin added a comment - - edited
          Show
          Andrei Pozolotin added a comment - - edited result of printing from this test: https://github.com/carrot-garden/carrot-bugger/tree/master/carrot-bug-pivot-print attached file: https://issues.apache.org/jira/secure/attachment/12496277/Java_Printing.pdf note: there is no text rendered.
          Hide
          Sandro Martini added a comment - - edited

          Hi all,
          thank you very much for the info, as you I was thinking that many bugs in Java2d were already resolved ...

          I can change the drawing method inside LabelSkin (and attach here a patch), but we have to see what Greg say on it.
          Or better, to avoid strange behavior (and/or performance, and/or antialiasing, etc), maybe we could even think to leave the current implementation as default, and provide another (as you suggested), driven by a startup property ... what do you think ?

          Bye

          Show
          Sandro Martini added a comment - - edited Hi all, thank you very much for the info, as you I was thinking that many bugs in Java2d were already resolved ... I can change the drawing method inside LabelSkin (and attach here a patch), but we have to see what Greg say on it. Or better, to avoid strange behavior (and/or performance, and/or antialiasing, etc), maybe we could even think to leave the current implementation as default, and provide another (as you suggested), driven by a startup property ... what do you think ? Bye
          Hide
          Drazen Dotlic added a comment -

          Sandro,

          thanks for looking into this. We're basically fine with whichever solution you come up with. Since we're pressed with time, we might end up "monkey patching" Pivot for this one particular deployment, but we would like to do it in a way that lets us later simply drop in a regular newer version containing the same (more or less) code.

          If you want to minimize impact/preserve compatibility, you might consider detecting the kind of graphics used for drawing (it should be PrintGraphics when printing) and then use the second code path which does work. Apparently, not many people are facing this issue so for those like us this would work fine and for the others nothing would change.

          What do you think?

          Drazen

          Show
          Drazen Dotlic added a comment - Sandro, thanks for looking into this. We're basically fine with whichever solution you come up with. Since we're pressed with time, we might end up "monkey patching" Pivot for this one particular deployment, but we would like to do it in a way that lets us later simply drop in a regular newer version containing the same (more or less) code. If you want to minimize impact/preserve compatibility, you might consider detecting the kind of graphics used for drawing (it should be PrintGraphics when printing) and then use the second code path which does work. Apparently, not many people are facing this issue so for those like us this would work fine and for the others nothing would change. What do you think? Drazen
          Hide
          Sandro Martini added a comment -

          Drazen,
          your suggested approach could be the best: keep the current behavior by default but draw text labels in another way when printing ... I'll try this ASAP (but as you know I have long times ...). I'll post here a patch based on this approach.

          Bye

          Show
          Sandro Martini added a comment - Drazen, your suggested approach could be the best: keep the current behavior by default but draw text labels in another way when printing ... I'll try this ASAP (but as you know I have long times ...). I'll post here a patch based on this approach. Bye
          Hide
          Sandro Martini added a comment -

          Hi all,
          after some tests, I'm sorry but even with the double pipeline enabled (default as currently, and new only for print), using drawGlyphVector / drawString doesn't solve, or better the label in never printed (tests in appletviewer) ... but I have other ideas to try (like trying to write the print() method inside LabelSkin, and see what happens).
          Note that at the moment I haven't yet committed something, but if possible today I'll commit at least the test case for the issue.

          As suggested, inside paint() I tried verifying the graphic context, but it seems it's never a PrintContext ... so is someone has other ideas I'll be happy to apply.

          Let's update soon.

          Show
          Sandro Martini added a comment - Hi all, after some tests, I'm sorry but even with the double pipeline enabled (default as currently, and new only for print), using drawGlyphVector / drawString doesn't solve, or better the label in never printed (tests in appletviewer) ... but I have other ideas to try (like trying to write the print() method inside LabelSkin, and see what happens). Note that at the moment I haven't yet committed something, but if possible today I'll commit at least the test case for the issue. As suggested, inside paint() I tried verifying the graphic context, but it seems it's never a PrintContext ... so is someone has other ideas I'll be happy to apply. Let's update soon.
          Hide
          Noel Grandin added a comment -

          Sandro, can you try fiddling with the code in ApplicationContext at line 562 that looks like:

          graphics.setRenderingHint(RenderingHints.KEY_RENDERING,
          RenderingHints.VALUE_RENDER_SPEED);
          display.paint(graphics);

          try removing the setRenderingHint line, or changing it to VALUE_RENDER_DEFAULT or VALUE_RENDER_QUALITY and see if that fixes things.

          Show
          Noel Grandin added a comment - Sandro, can you try fiddling with the code in ApplicationContext at line 562 that looks like: graphics.setRenderingHint(RenderingHints.KEY_RENDERING, RenderingHints.VALUE_RENDER_SPEED); display.paint(graphics); try removing the setRenderingHint line, or changing it to VALUE_RENDER_DEFAULT or VALUE_RENDER_QUALITY and see if that fixes things.
          Hide
          Drazen Dotlic added a comment -

          Sandro,

          indeed printing from applet viewer won't result in PrinterContext being used (using the viewer is still the simplest way to confirm the existence of the problem).

          However, we don't print from the viewer , nor do we use browser's print (since that ignores complete surface of the applet in all browsers but IE) - we do it manually by calling "print" on a Printable derivative of our own which simply uses given Graphics to draw the desired component. This Graphics instance is indeed a derivative of the PrinterGraphics (when printing, I just checked/debugged) so for us the code you have now - assuming the "drawString" replacement works just like the "drawGlyphVector" - is good enough.

          Could you please submit a patch/ commit what you have?

          Thanks.

          Show
          Drazen Dotlic added a comment - Sandro, indeed printing from applet viewer won't result in PrinterContext being used (using the viewer is still the simplest way to confirm the existence of the problem). However, we don't print from the viewer , nor do we use browser's print (since that ignores complete surface of the applet in all browsers but IE) - we do it manually by calling "print" on a Printable derivative of our own which simply uses given Graphics to draw the desired component. This Graphics instance is indeed a derivative of the PrinterGraphics (when printing, I just checked/debugged) so for us the code you have now - assuming the "drawString" replacement works just like the "drawGlyphVector" - is good enough. Could you please submit a patch/ commit what you have? Thanks.
          Hide
          Sandro Martini added a comment -

          Hi all,
          Noel, I tried all combinations of your suggestion but nothing changes .... sorry, but thanks for the help.

          Drazen, I can't commit nothing before we release the 2.0.1 (currently in trunk), but I'll post here a patch as soon as I have a working fix.
          The problem I have now is that inside the paint() method, I'm not able to understand when the paint is "normal" or when it is for a "print" so currenlty I'm not able to have the double pipeline ... so I think I could try to implement in LabelSkin a simple print() method and see what happens ...
          If you have some suggestions they are welcome.

          Thank you for now.

          Bye

          Show
          Sandro Martini added a comment - Hi all, Noel, I tried all combinations of your suggestion but nothing changes .... sorry, but thanks for the help. Drazen, I can't commit nothing before we release the 2.0.1 (currently in trunk), but I'll post here a patch as soon as I have a working fix. The problem I have now is that inside the paint() method, I'm not able to understand when the paint is "normal" or when it is for a "print" so currenlty I'm not able to have the double pipeline ... so I think I could try to implement in LabelSkin a simple print() method and see what happens ... If you have some suggestions they are welcome. Thank you for now. Bye
          Hide
          Drazen Dotlic added a comment -

          Sandro,

          could you please send us a patch? Our code, printing "by hand" will definitely trigger sending of the PrinterContext down into the paint code.

          As I've said, we don't like it but if we have to we'll "monkey patch" this temporarily (using code from you) because we have an applet in production with printing implemented but disabled since it's not working for Labels.

          Thanks,

          Drazen

          Show
          Drazen Dotlic added a comment - Sandro, could you please send us a patch? Our code, printing "by hand" will definitely trigger sending of the PrinterContext down into the paint code. As I've said, we don't like it but if we have to we'll "monkey patch" this temporarily (using code from you) because we have an applet in production with printing implemented but disabled since it's not working for Labels. Thanks, Drazen
          Hide
          Sandro Martini added a comment -

          Eclipse Test launch file to run pivot_511.bxml as an Applet, inside AppletViewer (from eclipse), and try to print from there.

          Show
          Sandro Martini added a comment - Eclipse Test launch file to run pivot_511.bxml as an Applet, inside AppletViewer (from eclipse), and try to print from there.
          Hide
          Drazen Dotlic added a comment -

          Sandro,

          we've integrated the patch you've sent me and it's working great for us. Could you please let us know if and when do you plan to integrate it and into which version? We have our own build tracking trunk which we've disconnected now because we've implemented this patch but we'd like to sync with trunk again if possible (so we'd appreciate if you'd put this in trunk).

          Thanks again for the work done, it solves our issue perfectly.

          Show
          Drazen Dotlic added a comment - Sandro, we've integrated the patch you've sent me and it's working great for us. Could you please let us know if and when do you plan to integrate it and into which version? We have our own build tracking trunk which we've disconnected now because we've implemented this patch but we'd like to sync with trunk again if possible (so we'd appreciate if you'd put this in trunk). Thanks again for the work done, it solves our issue perfectly.
          Hide
          Sandro Martini added a comment -

          Drazen, very good ... the only thing to change in that patch could be to have the usual (non-print) test as first, to reduce the (minimal) overhead.

          If there aren't objections from others (today/tomorrow) I'll commit this for 2.0.1 final.

          Just for reference, I attach now the current patch (so others can see),
          and re-attach the final before committing it.
          Maybe add even an enhancement ticket and marked as solved in 2.0.1 and move this for 2.1 ...

          Thank you again for your help to make Pivot better .

          Show
          Sandro Martini added a comment - Drazen, very good ... the only thing to change in that patch could be to have the usual (non-print) test as first, to reduce the (minimal) overhead. If there aren't objections from others (today/tomorrow) I'll commit this for 2.0.1 final. Just for reference, I attach now the current patch (so others can see), and re-attach the final before committing it. Maybe add even an enhancement ticket and marked as solved in 2.0.1 and move this for 2.1 ... Thank you again for your help to make Pivot better .
          Hide
          Sandro Martini added a comment -

          The current patch.
          Note that I didn't put here in attach only because I wasn't sure it solve the problem.

          Show
          Sandro Martini added a comment - The current patch. Note that I didn't put here in attach only because I wasn't sure it solve the problem.
          Hide
          Noel Grandin added a comment -

          In general, it looks good to me

          +// graphics.drawGlyphVector(glyphVector, x, y + ascent);
          Don't leave commented code in. just remove it. We have subversion if we want to know what the old code looked like.

          + // workaround for PIVOT-511
          Please add a more useful description of why the workaround is necessary. Having to go find a bug-report while reading the code is a real hassle.

          Show
          Noel Grandin added a comment - In general, it looks good to me +// graphics.drawGlyphVector(glyphVector, x, y + ascent); Don't leave commented code in. just remove it. We have subversion if we want to know what the old code looked like. + // workaround for PIVOT-511 Please add a more useful description of why the workaround is necessary. Having to go find a bug-report while reading the code is a real hassle.
          Hide
          Drazen Dotlic added a comment -

          Sandro,

          I'm assuming the patch will end up in the trunk sooner or later?

          Show
          Drazen Dotlic added a comment - Sandro, I'm assuming the patch will end up in the trunk sooner or later?
          Hide
          Sandro Martini added a comment -

          Hi Drazen, got no objections from others so just committed in as fix for PIVOT-805.
          Try to reconnect your CI Server with Pivot trunk, and in case of problems tell me ... but to avoid confusion, please post comments on it in PIVOT-805 (be free to reopen it in case of problems).

          Show
          Sandro Martini added a comment - Hi Drazen, got no objections from others so just committed in as fix for PIVOT-805 . Try to reconnect your CI Server with Pivot trunk, and in case of problems tell me ... but to avoid confusion, please post comments on it in PIVOT-805 (be free to reopen it in case of problems).
          Hide
          Sandro Martini added a comment -
          Show
          Sandro Martini added a comment - Interesting (but a little old) article: http://www.apl.jhu.edu/~hall/java/Swing-Tutorial/Swing-Tutorial-Printing.html
          Hide
          Sandro Martini added a comment -

          The latest fix for PIVOT-815 seems to fix even this.

          Show
          Sandro Martini added a comment - The latest fix for PIVOT-815 seems to fix even this.
          Hide
          Sandro Martini added a comment - - edited

          Sample print after the latest fix, as you can see the problem seems to be fixed now.

          @All: this is another (small but important) fix for Pivot, please provide feedback.

          Thank you.

          Show
          Sandro Martini added a comment - - edited Sample print after the latest fix, as you can see the problem seems to be fixed now. @All: this is another (small but important) fix for Pivot, please provide feedback. Thank you.
          Hide
          Sandro Martini added a comment -

          Finally this has been resolved, as a sample, look at the pdf file in attach ("Java Printing.pdf", with date 2011-11-10).

          Drazen (and all others), be free to reopen the issue in case of problems.

          Now I'll open a related (new issue), but for 2.1 on the need to rescale output before printing it.

          Show
          Sandro Martini added a comment - Finally this has been resolved, as a sample, look at the pdf file in attach ("Java Printing.pdf", with date 2011-11-10). Drazen (and all others), be free to reopen the issue in case of problems. Now I'll open a related (new issue), but for 2.1 on the need to rescale output before printing it.

            People

            • Assignee:
              Sandro Martini
              Reporter:
              Sandro Martini
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development