We have a major problem affecting our customers of a large Flex 3 RIA.
Our RIA prints large plans (an example would be (1,500 x 2,000 pixels) created by the user by dragging sprites onto a grid and, because these contain transparency we have to use bitmap printing.
Flash Player 11 seems to break this printing - depending on the size of a plan some parts of it (the bottom for a high plan or the right hand side for a wide plan) are missing some of the Sprites on the printed plan. For very large plans printed over several pages (using the PrintJob.AddPage() method) we end up with several blank pages too.
We are using mx.Printing.FlexPrintJob and adding pages in this way:
printJob.addPage(planCanvas, rect, printJobOptions);
where rect is a flash.geom.Rectangle used to define each page's mask area.
In order to get the plans to render correctly in the past we have always had to have them re-scaled to display fully on screen just before printing:
I wonder whether something has changed that makes this ineffective now?
Can anyone point me in the direction of what new 'feature' in FP11 might be causing this and any ideas for solving it?
planCanvas.scaleX = planCanvas.scaleY = canvasPrintingScale;
printJobOptions.printAsBitmap = true;
... REST OF PRINTING CODE...
I have encountered this emerged bug/problem - once client is using FP 11, only the first page out of several bitmap pages is printed; the remaining pages come out blank; i.e. the printer spits out correct number of pages, but only the first page bitmap is actually sent.
I also have a large project with thousands of users, with an administrative utility for teachers to print login sheets for their classroom. If I try to print to the Adobe PDF printer, it will take a while and only print 2 or 3 of the dozens of pages that it should have sent. There is no error... just far less than the expected number of pages make it into the final PDF. This was functioning perfectly for years, and based on my timestamp, the file hasn't been modified since Feb. 2011, so I'm sure my code is fine. Why do the latest versions of the player break so many features? I can't even resize my browser window when Flash is active. I love Flash, but these are serious crippling issues that are going to force me to make a decision to move away from using it if Adobe can't get thier **** together.
The blank/missing page issue is indicative of running out of print spool disk space. Check the spooling print job size. If it is huge and there isn’t enough space on the disk try to make more space.
I haven’t seen this problem in FP11 per-se. It was first an issue in FP 10 and changes were made in FP 10.3 I believe. Maybe it broke again in FP11 or the fix wasn’t “perfect”. The underlying issue was that Flash started to use some of the native print features of the OS and Windows added a high-resolution printing option that was on by default. This caused the player to generate really huge bitmaps per page and blew out the spooling disk space on older systems. I think the fix was to not create such huge bitmaps but I think the bitmaps are still bigger than they were in FP9.
IIRC, you can alleviate the problem by changing the print settings in Control Panel but that requires visiting every desktop. Also, I found that overriding that setting in page/printer setup in the print dialog does not help, you have to change the default in Control Panel.
The missing page issue was not because of running out of print spool disk space. It was a frame script TIMEOUT issue with Flash. Proof of this is in my solution to the problem: I implemented a "pseudo thread" that distributes the calls to PrintJob.addPage over multiple frames. An added benefit of this is that I can update a progress bar to display the print progress as each page is sent to the printer. Without distributing the calls over multiple frames, Flash throws a script timeout error before all pages are printed and before the PrintJob.send method is called. The job is sent to the printer eventually, but because of the script timeout, not all calls to addPage were made and the call to send was omitted as well.
Anyway, the solution of distributing the calls over multiple frames works, and is actually better because it allows the display to be updated between sent pages. HOWEVER... I think the player should not throw an exception, unconditionally, that interrupts the script when calls to native functionality such as addPage are made which are expected to take some time. I understand the importance of having a timeout, and the importance of writing code to avoid them, but this type of situation could be handled better by the player when the user and programmer both know that it just needs a little bit more than 15 seconds to execute.
For example, increasing the timeout deterministically and temporarily by a constant value of 15 seconds when a call to addPage is detected (not each call, but just the first one), would perform a one-time extension of the script timeout for that executing frame. Make the player a little more intelligent by setting a flag that says "this particular script cycle might take a bit longer than 15 seconds, so give it 30). It would be very helpful, and as a deterministic, once-per-frame thing, it wouldn't compromise the script timeout functionality. And it's not even like you'd be giving the programmer that control... the Flash player could have a list of built-in methods, such as PrintJob.addPage, which are known to take some extra time, which would invoke the time extension.
If that's not possible, then the player should ASK the user if they want to allow the script to continue, and if they choose Yes, then no error should be thrown in the script and the script should be allowed to continue uninterrupted (for another 15 seconds, then ask again). If they choose NO, then it would be perfectly appropriate to throw a script timeout error which the app could handle. Printing 15 or 30 pages is not an uncommon thing, and between the time taken in the print dialog and spooling the pages, this can easily cause a script to timeout. At the very least, this behavior should be documented and a recommendation to distribute print jobs over multiple frames should be made. Thanks for reading!
Europe, Middle East and Africa