Printing resolution paradigm (again)

[Max_Barel]

begin disclaimer
Past experiences showed that, when I express my thoughts, especially when writing in English, I can hurt susceptibility.
I know the huge work that Patrick has done on Neo/J.
This is not criticism but suggestion.
end disclaimer

The last 0.7 version has much improvement and bug fixes concerning printing. But it still take 16 swap files and very long time (several minutes) to print (to Preview) ONE page with bitmap images (Patrick, this is the page 4 of the press review file that I sent to you, with one transparent object). This definitely is a stopper. Not acceptable for end users.
I read and understood the posts about the resolution choice among 72dpi and better. My thought is that the choice should be left to the user, as it is in OOo. There are already options to do this in the printing pane of the Options dialog.
Depending of this setting:
--if "Reduce bitmaps" is checked then
----if "optimal quality" is selected then print at 300 dpi (as help states)
----or if "standard quality" is selected then print at 200 dpi (as help states)
----or if "resolution" is selected then print at the selected resolution
--else print bitmapped object (images) at their native resolution.

This last eventuality might be the trickiest to achieve in Java. In PostScript it is possible to imbed a bitmap and let the intepreter scale it as needed. This is the better choice because there are optimized algorithms do do pixel interpolation and such.
Neo/J use Java to generate a PS file and IMO it is a waste of resource to do the work of image sizing at this stage.
How to pass on the image at its native resolution and specify a dimension to scale, using the Java API is far beyond my knowledge…
Max

[pluby]

[pluby]

Max,

I did some experimenting with the code and I have some good news and some bad news on this subject.

First the good news. Printing causes the underlying OOo code to do a lot of scaling when any images are printed. This is where all of the memory is being used. In the NeoJ 0.7 code, I use the OOo built-in scaling functions to perform any scaling. By switching to the Java scaling methods, the number of swap files created when I print the 7-slide image-intensive sample file that you sent me with "Fit to Page" and "Print With Transparency" is cut in half! Printing the file and opening it in Adobe Acrobat caused only 3 new 80 MB swap files to be created. It stayed at 1 80 MB swap file. This change does not change the size or resolution of the PDF file. I have commited this change to the CVS repository.

Now the bad news. Controlling image resolutions from the configuration settings is not feasible. What I found is the OOo code will, in many cases, scale images sending the image to my printing code. In other words, a lot of image scaling is done in the application (e.g. Writer, Calc, Impress) layers. The only control that my code has it setting the maximum allowed printer resolution. Apparently, the application layers perform scaling based on this value. Currently, I have this number set to 300 dpi (or less if the printer can't handle 300 dpi).

So why is this bad news? There are a few reasons. First, it makes it impossible to pass unscaled images to the printer and let the printer do the scaling since OOo will have already scaled the image. Second, the OOo code does not handle transparency very well. OOo assumes that window and printers can't handle transparent pixels even though Java has no problem with such pixels. Consequently, OOo renders a transparent image by scaling the pieces of the image and layering them in a buffer (lots of memory!) and then printing this layered buffer.

So, there are limits to what can be done. At least the switch to Java scaling should help. I also can implement one more change that will help reduce memory usage and PDF file size but only in certain cases. In certain cases, the OOo code does not prescale the images and will ask my code to scale the image. AFAIK, this only happens when you print with "Trim to Fit" and "Print Without Transparency". In these cases, if the highest-resolution image on a page is less than the printer resolution, I can adjust the current page's resolution down to match resolution of the highest-resolution image on that page. In other words, if OOo asks my code to scale a bunch of 72 dpi images when printing to a page, I can set the resolution of the current page to 72 dpi and not scale the images. This reduces the amunt of memory required and the size of the PDF generated for this page by a substantial amount. This also offloads scaling to the printer.

Patrick

[Max_Barel]

Patrick,
Your good news sounds pretty good. The ultimate goal of the printing in Neo/J is to be as efficient as OOO/X11. You can't rewrite the whole thing. If this last improvement achieves equivalent printing time and memory use in Neo/J compared to OOo/X11, it's OK, IMO.
What I don't understand is why it's (was) so heavy in NeoJ compared to OOo.

About the bad news. This resolution/scaling paradigm is always a nightmare, even for the end user to figure out what is going on. Making the best use of pixels in an image without losing some and without creating useless ones is tricky. I try as much as possible to avoid intermediate scaling by an application, beside the last one. And this last one should be handled by the printing system, which has all information to do it, and whose algorithms are used throughout the system, then justifying the optimization work. That's why I try, in OO, to get a correct printer setup to be able to print a page without scaling it ("trim to fit").
Transparency is one of the possibles complicating cases, though. If the underlying system does not offer support for it, it must be done in the application. OOo rely on X11 for display and for PostScript for printing. X11 does not support transparency, I'm not sure about PostScript.
To make the long story short: make you best to avoid scaling, and if you have to, do it in Java since it's more efficient.
That's what your recent fixes do, aren't they?

[pluby]

Max,

I have some good news. Over the last few weeks I have made quite a few changes to the printing process in order to reduce the memory usage. While making those changes, I figured out where the maximum printing resolution set in Tools -> Configuration is cached in the VCL code.

Once I found this cached value, telling the printer to scale images to the user's maximum resolution was fairly easy.

So, in the patch that I posted yesterday in the testing forum, printing images now follows the steps that you originally proposed:

[Max_Barel]

Yesterday I tried twice to download the last patch and it failed.
It's now underway.
I'll test it and report if there is more to say. If not, thank you for considering my suggestion.