NeoOffice/J now has printing

[pluby]

I finally finished implementing all of the printing functionality in NeoOffice/J! But I need help testing the new functionality.

If you are interested in testing the new printing functionality, you can download the lastest printing binaries and install them in an existing NeoOffice/J 0.0.1 installation using the following steps:

- If you have not already installed NeoOffice/J 0.0.1, download and install it from:
http://trinity.neooffice.org/modules.php?name=Downloads&d_op=viewdownload&cid=4
- Download the latest printing binaries from:
http://www.planamesa.com/neojava/downloads/temp/printtest3.tar.gz
- Open a new terminal and execute the following commands to unzip the file:

[Max_Barel]

We already thank you for the great job you have done one Neo/J and printing. Now is the time of bug reports.

- No image printing. This one is surprising. After loading the printest3 tarball. I tested some file around and found that it does not print images at all. Jpeg or tiff are ignored, eps are printed as they are displayed i.e. as a markup of an eps file. Now, I guess why the PDF generated files are thinner than OOo/X11 ones! The test I reported in an other post contains two images.
- Modal dialog lock-up. When Neo/J is printing, if the underlying OOo thread pop a dialog, like transparency in image or paper size etc. The two dialogs lock each other and you can't click or close anyone. The main thread is still responding, but if you try to quit NJ it refuses because being printing. You must kill the app.
- No even-odd selection. This is not exactly a bug, rather an OS X lack. Switching to native OS X print dialog has the side effect of loosing the ability of select odd or even pages for double side printing. There is still the possibility to print to a PDF file and use Acrobat Reader trick to print the only odd or even (afaik, Preview can't).

About UI (of topic): Pluby, if you wish, I can post a small list of UI related bug or issues. I don't think it's now on you priority list so I'll wait for you to ask.

[Guest]

Max,

Thanks for the feedback. It appears that I still have some work to do .

[Max_Barel]

[pluby]

Max,

I was able to replicate the "dialog lock-up problem". It seems that OOo has many cases when it will show a modal dialog after printing has started.

Since Java's printing APIs display the modal "Printing" dialog and modal Java dialog grab all mouse events, the only solution is that I must suppress the display of any OOo modal dialog once printing has started.

This solution is fairly easy to implement. But it will force the user to automatically get the default option associated with each modal dialog. I realize that this is not ideal. Any thoughts?

As for the options dialog that I already suppress, I will add that back when I implement the above fix.

Patrick

[OPENSTEP]

Erk, I really do hate this dialog modality issue. I can only think of two approaches, the suppress all modal dialogs option as already mentioned as one. The other may be a bit trickier...

I know in Carbon/Cocoa print dialogs you can extend a print dialog with custom controls that show up in a subpanel. Theoretically, we might be able to do something along the lines of "queuing" any other modal dialogs until a user pressed an "Options" button within the print dialog. Then, the next modal dialog could enter its event loop off of the handler from the custom control. This may require some type of weird deferred wizadry in the base class dialog constructor...most client code seems to invoke "Execute" and assume that when it returns the dialog's options have been specified.

In theory, the print dialog should be handled by the primary run loop, so doing this wouldn't cause the event loop to start jumping to weird threads. I honestly think deferring the dialogs may just be too difficult, but in theory it may be the cleanest approach. Thoughts?

ed

[pluby]

Ed,

Earlier today I came to same conclusion that deferring the printing dialogs was the most realistic approach. Fortunately, I found that I was creating the print dialog much earlier than necessary. So, instead of creating the print dialog in SalPrinter::StartJob, I now do it in the first call to SalPrinter::StartPage. This works like a charm.

Apparently, OOo invokes SalPrinter::StartJob and then does all of the checks that display modal dialogs. After all of the modal dialogs are displayed, OOo invokes SalPrinter::StartPage to get the first page to print to.

I have also fixed Max's other bugs (i.e. images and transparency). Fortunately, they weren't as bad as I thought they would be. I am doing a clean build of the installer. Expect to see an new posting and updated binaries in a couple hours.

Patrick

[pluby]

I have posted an updated set of printing binaries. This new set of binaries fixes the following bugs that Max Barel reported in this same thread:

- Images don't print - Images now print (even transparent ones)
- Modal dialog lockup - Surpringly, I did not need to suppress the OOo dialogs that Max was seeing. Instead, I just delayed the start of Java's printing process. This allows the OOo dialogs to appear without any lockup.
- The OOo print options dialog never appears - I have reenabled this dialog when you select the File->Print... menu item.

Also, I added my fix for the OOo bug that mangles non-ASCII path names iin the OOo file dialogs.

If you are interested in testing the latest fixes, you can download the lastest printing binaries and install them in an existing NeoOffice/J 0.0.1 installation using the following steps:

- If you have not already installed NeoOffice/J 0.0.1, download and install it from:
http://trinity.neooffice.org/modules.php?name=Downloads&d_op=viewdownload&cid=4
- Download the latest printing binaries from:
http://www.planamesa.com/neojava/downloads/temp/printtest4.tar.gz
- Open a new terminal and execute the following commands to unzip the file:

[Max_Barel]

Hi Patric,
I have been too busy these days to do extensive testing of the printest4 improvements.
Nevertheless here are a few remarks:
- No printing of EPS images. This version brings no improvement on this matter. OOo never displayed EPS on screen but included the EPS in the PostScript stream. Neo/J does not. Instead it prints the thumbnail used for displaying the EPS placeholder. Loosing the PS font capability isn't too serious, but embedding EPS is a useful feature to keep, if possible.
- The PDF file generated by this last version hangs Preview. If a PDF file is generated and saved using option in the standard print dialog, it can be opened and displayed with Acrobat Reader, but not in Preview. I presume this is a PDF 1.2/1.3 issue, because if the generated file is filtered by ps2pdf, it then opens in Preview. This is not major concern but still a hitch in the normal Cocoa print sequence edit-preview-print.
- One of my graphic files cause Neo/J to crash, while printing correctly in OOo/X11. I have no clue on this (buffer size?). Here under a crash dump. Notice that this is the kind of crash where OO display a message "all files have been saved...", but, in Neo/J, the next launch does not offer the option to recover the temp file.
- I also noticed that Neo/J always prints the whole file, even if only some page is selected. We can cope with this, if it's the simple way to print in Java. Also when the print process is canceled from the Cocoa progress window, this one close but Neo/J continue printing to the end.

Neo/J is now very close to replace OOo/X11 for everyday work (keeping it at hand just in case), while the Neo team works on the Aqua port.

[pluby]

Max,

Here's some info on the problems that you reported:

- No printing of EPS images - The reason for this is that I have not ported the EPS rendering code that is used by X11 to Java. So right now this code does nothing in NeoJ. If you send me an EPS file via e-mail (the ones I have don't have much content and are pretty useless for development and testing), I can look at implementing EPS when I get some spare time. In theory, the approach for NeoJ would be different than X11. In NeoJ, I would convert the EPS to a set of Java drawing instructions and/or JPEG images so that I can render the EPS to a Java window or printer.

- The PDF file generated by this last version hangs Preview - I could not replicate this with a simple Writer document. Could you send me a sample file via e-mail that causes the problem? My guess is that certain drawing instructions (e.g. transparency) may cause Java to render in PDF 1.3. If my assumption is correct, then it is a matter of finding which instructions do this an rewriting the code to avoid those instructions.

- One of my graphic files cause Neo/J to crash, while printing correctly in OOo/X11 - From the dump file you posted, NeoJ is crashing in the method where NeoJ allocates memory in the JVM for drawing an image. By default, on Mac OS X Java sets an upper limit of 64 MB of memory. This may not be enough in your case. To test if this is the cause, try increasing the upper limit to 256 MB by using the following steps:

1. Execute the following command to open the "setup" script:

[Max_Barel]

I followup here, rather than by mail to avoid duplicate issues, and because it gives me an opportunity to congratulate Patrick about his amazing efficiency. As Ed and Dan for the OOo/Neo thread, you are doing a great job.

[pluby]

Max,

There is one nasty side affect of setting the Java maximum memory really high: Java can sometimes delay running its garbage collector based on the fact that it has more memory available! Hence, RSS will keep increasing.

Last night, I added explicit garbage collection whenever a window is destroyed. This seems to best approximate when a document is closed and seems a good time to clean up memory.

With this extra code in place, I can now repeatedly open and close a 241 page text document, print it, and close it and RSS stabilizes at about 115 MB. This tells me that although the initial opening and printing of a large document increases RSS, subsequent reopenings are reusing the RSS already allocated.

Now that I have the explicit garbage collection in place, I also changed the setup script to set Java maximum memory really high (-Xmx1024m) which will cause VSZ to be really high (about 1.3 GB). Although this sounds strange (and it did to me!), I talked with a friend of mine who seems to understand how operating system memory managers work. His unerstanding was that merely allocating VSZ memory doesn't actually cause the real memory to be tied up. If Mac SO X's memory manager is similar to other Unix memory managers, real memory is not tied up until the application tries to actually use the memory.

This scheme, however, only works if the application (i.e. my Java code) does not leak memory. This will be something to watch closely for in the next printtest patch that I post.

Patrick