• Type: Enhancement
• Component: javafx
• Sub-Component: graphics
• Affected Version: fx2.0

• Priority: P2
• Status: Closed
• Resolution: Fixed

• Submitted: 2011-10-13
• Updated: 2015-06-16
• Resolved: 2013-01-28

JDK 8
8Fixed

It would be wise to make the print option in JavaFX the same way it is in Swing. 17-01-2015 The feature was implemented and tested. Close. 12-07-2013 >Is there any Linux support? 100% untested, but given that it relies on underlying JDK APIs which are tested on Linux I expect it to be functional there, altough there could be surprises in the rendering parts. 29-01-2013 Is there any Linux support? 29-01-2013 The initial API and implementation has been pushed into the graphics scrum. It has mainly been tested on Windows as the Mac testing is blocked by needing headful AWT support. We do expect tweaks and revisions to the API as we learn by using it. Those will be tracked as new/separate JIRA bug ids. 28-01-2013 Mark, I suppose you are imagining an API on PrinterJob that is something like "showPrinterSpecificPreferences(Window owner); which on Windows maps to a call to PrinterProperties(..) as documented at : http://msdn.microsoft.com/en-us/library/windows/desktop/dd162837%28v=vs.85%29.aspx We could provide something this but, yes, this is a bit ahead of where we are and expect to be able to do in this initial release as its a somewhat advanced usage. I could imagine apps calling that not understanding that its really only for dialog implementors as I've never seen it used standalone in native apps. I also have no idea if this is possible on any other platform. It could also be a minority need. How many people will want to write a custom dialog ? The expectation is that most apps will want to use the native dialog for the user experience, just one part of this being that it will allow them access to all those vendor printer driver specific setting you talk about that are not supported in platform API. 27-12-2012 I have a question about printer capabilities. Seems like this is still in Phase 1 of the 6 phase plan, so maybe this Phase 2 question is a bit premature. However, I don't want to forget to ask. It is sometimes necessary to create a customized print dialog for an application. However, there is no end (and perhaps rightly so) to what the printer folks can dream up as to what type of settings they may decide to support. Some of these don't necessary involve the rendering process, but rather how to set up the job (like a user name and password, for instance). Is there going to be a way to bring up the driver-specific print dialog from inside a custom dialog to set these additional properties and then have them sent to the printer? Beyond this, would these attributes / settings be accessible to the API at least to the point where the they could be re-applied programmatically? I can only imagine the complications this might imply, but without the ability to open the driver-specific dialog, it is hard to have a complete printing solution. 26-12-2012 Thank you Phil and Richard for clarifying this issue because we are loading and working with hi-res images and we need to be able to retain as much fine detail as possible. We also need to be able to size and position images precisely on the printed page. Sounds like we're going to be ok. 19-12-2012 OK cool. You have the option with Image when you load whether to load the entire high res and we scale it down, or scale it down at the time of loading (in which case it would print lo-res). But as long as we can display the image at a certain size relative to the rest of the scene but get the high res bits at print / scale time (such as with retina display) then we'll be OK. Is there an updated set of JavaDocs with the changes Randahl suggested? 18-12-2012 When we have access to the original resolution source image then I don't think there will be any problem. We'll scale directly from image space/resolution to printer device space/resolution. There is no need to go via a 72dpi intermediary. I'm sure that ImageView has to keep that original image around at full resolution since it has a very similar requirement depending on the size of the window/viewport .. My testing on the current prototype shows that if I print an ImageView backing a very hi-res image (5760x3840 jpg) then the job spool file size is correspondingly large (and commensurate with the size spooled from Windows Photo Viewer) and it looks to have retained the information. 18-12-2012 On Rick's point, I was wondering how we handle images? For example, if I am printing a book or glossy, I want to use a high resolution image. However, if 1/72 is all I have and you are going to scale things up, then wouldn't this result in an inability to rendering hi-resolution images? Either I have a high resolution image I've scaled down to fit in my layout, which then gets scaled up (and I'm guessing we actually will do both scaling operations?), or I have a smaller image that just gets scaled up and doesn't give me the high quality image printing I might have been looking for. 18-12-2012 Randahl, Again sorry for the delay. > Awesome API. I only have a few minor review comments: > 1. JavaDoc for cancelJob states "This marks a job to be cancelled at the earliest opportunity. ie it may return immediately without waiting" ��� Question: Will it not always return immediately? What do you mean by "may"? I'm not completely happy with that wording either and it does need another look. The sentence after that gives a clue as to what I was trying to express as we might want to return fast to make it less painful to use "cancelJob()" in a dialog where a user presses a button and there could be a perceptible delay on that thread whilst we synchronized with the job and tried to interrupt the printing of the page. > 2. It would be best to start the docs of PageLayout by stating how a page layout is created, since traditional Java object construction with "new" is not an option. Will do. > 3. Since Printer acts as a factory for PageLayout it might be more appropriate to name the method createPageLayout, rather than getPageLayout (which sounds like it is a getter method). Good point. Agreed. > 4. Using int[] for page ranges is error prone. I would recommend changing the method to setPageRanges(PageRange... pageRanges), which both strengthens the semantics of what is going on, and avoids the problem with an odd number of ints. PageRange could have two properties start and end which should be settable using the constructor as in setPageRanges(new PageRange(0, 5)); I was not super comfortable with int[] in general and that that one needed more thought. The varargs idea sounds good to me. 13-12-2012 Rick, Sorry for the delay in replying. The DPI should be available by querying the PrinterResolution but I'm not sure you need it The API's coordinate space for width and height is points (1/72 inch) Under the covers we would apply a transform to device space so you just convert from mm to points and express the quantities as floating point numbers which we will map to the closest integer device resolution location. 25.4mm is the usual conversion of 1 inch, so the multiplier is x= y = 100 * (72/25.4) and r = 50 * (72/25.4) 13-12-2012 Update due date to reflect the current progress 10-12-2012 Awesome API. I only have a few minor review comments: 1. JavaDoc for cancelJob states "This marks a job to be cancelled at the earliest opportunity. ie it may return immediately without waiting" ��� Question: Will it not always return immediately? What do you mean by "may"? 2. It would be best to start the docs of PageLayout by stating how a page layout is created, since traditional Java object construction with "new" is not an option. 3. Since Printer acts as a factory for PageLayout it might be more appropriate to name the method createPageLayout, rather than getPageLayout (which sounds like it is a getter method). 4. Using int[] for page ranges is error prone. I would recommend changing the method to setPageRanges(PageRange... pageRanges), which both strengthens the semantics of what is going on, and avoids the problem with an odd number of ints. PageRange could have two properties start and end which should be settable using the constructor as in setPageRanges(new PageRange(0, 5)); So looking forward to this! Nice work. Randahl 03-12-2012 Our app requires printing a subtree of nodes in a spatially accurate way - precise to about 0.1 mm. After the user selects a printer along with quality, orientation, margins, page size etc, we need to be able to find out how many dots are available in the printable area along with the user-selected resolution, so that we can create our subtree and size the nodes to be printed accordingly. From the recent wiki posting and the draft API, it is not immediately apparent how to do this. Would you please provide an example of how to set up a PrinterJob to draw a circle with its center located exactly 100.0 mm from the top and left of the printable area, with a radius of exactly 50.0 mm? 03-12-2012 Docs/OK 03-10-2012 G11N/OK - most likely no translation required. 20-09-2012 Draft API will be ready 11/02. 12-09-2012 SQE/OK based on input from Kevin/Vivian that we should get API/Spec by beginning of Nov (possibly end of Oct). The only concern is hardware 12-09-2012 One more question: is there any engineering spec for the feature and API? 31-08-2012 Phil, Kevin - could you please estimate when SQE will have something available to test? 07-08-2012 Implements A360 Feature http://oracleplan.oracle.com/gotoEntity?entityType=FEATURE&entityId=708334 03-08-2012 High level plan is to start off in a sandbox and proceed in steps 1. The initial focus here is on task RT-17662 : getting the rendering part prototyped and then [mostly] working. This one is difficult to measure because it covers a lot and is where more of the unknowns lie 2. We will then create initial public APIs around printer discovery and attributes and SQE can start to develop tests. 3. Either now, or before this point it should be functional enough to move from sand box to mainline and SQE can start testing. 5. Webview and controls teams can proceed with adding CSS and printing support 6. Finalise the API and move into bug fixing mode. 10-11-2011