Welcome to NeoOffice developer notes and announcements
NeoOffice
Developer notes and announcements
 
 

This website is an archive and is no longer active
NeoOffice announcements have moved to the NeoOffice News website


Support
· Forums
· NeoOffice Support
· NeoWiki


Announcements
· Twitter @NeoOffice


Downloads
· Download NeoOffice


  
NeoOffice :: View topic - Printing resolution paradigm (again)
Printing resolution paradigm (again)
 
   NeoOffice Forum Index -> NeoOffice Development
View previous topic :: View next topic  
Author Message
Max_Barel
Oracle


Joined: May 31, 2003
Posts: 219
Location: French Alps

PostPosted: Tue Oct 14, 2003 9:06 am    Post subject: Printing resolution paradigm (again)

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
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Tue Oct 14, 2003 9:48 am    Post subject: Re: Printing resolution paradigm (again)

Max_Barel wrote:
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 admit that printing is a bit clunky and inflexible right now and I expect it will be area that we will be constantly trying to improve with each release. I consider NeoJ to still be at the prototype stage of its existance so don't worry: I don't think it is complete.

Max_Barel wrote:
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.


I like this approach. The tricky part will be how to access this information in the printing code. OOo tends to keep its formatting information separate from the code that actually does the printing so I will have to look into this and see and there is a way that I can grab this information when my code is setting the printer resolution.

Right now, I would guess that OOo is scaling images to the resolutions listed above. But because I have set the printer resolution to a higher setting, Java is probably rescaling the images. This probably explains why printing is so slow and is taking so much memory.

Max_Barel wrote:
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…


I believe that this is already being done. Java uses CoreGraphics to stream the drawing operations to a PDF file. For images, CoreGraphics writes the bits and the bounding box dimensions to the PDF file. The only problem is that Java won't let you set the PDF bounding box for an image. Instead, Java seems to calculate it using the width and height of the image (in pixels) x 72 / printer resolution.

Given the above limitation as well as the numerous image printing bugs that Java has (e.g. I have to merge all images on the same page into a single combined image which makes the PDF file baloon in size), I will probably look at the CoreGraphics APIs to see if I can print images directly instead of through Java.

BTW, I figured out why the Carbon EPS drawing functions don't work. The CoreGraphics stream PDF and just ignores anything (like EPS) that is not valid PDF. Even when you select the "Save As PostScript" option in the native print dialog, CoreGraphics prints PDF and then converts it to PostScript using the /usr/libexec/cups/filter/cgpdftops command! It appears that Mac OS X is really getting away from PostScript.

Patrick
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Sat Oct 18, 2003 11:19 am    Post subject:

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
Back to top
Max_Barel
Oracle


Joined: May 31, 2003
Posts: 219
Location: French Alps

PostPosted: Sun Oct 19, 2003 10:47 am    Post subject:

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?
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Mon Nov 17, 2003 11:45 pm    Post subject:

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:

Quote:
--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.


I also added one extra memory-reducing feature: if "Reduced bitmaps" is checked and the highest resolution bitmap has a lower resolution than the checked maximum resolution, print at the resolution of the highest resolution bitmap.

Patrick
Back to top
Max_Barel
Oracle


Joined: May 31, 2003
Posts: 219
Location: French Alps

PostPosted: Tue Nov 18, 2003 11:02 am    Post subject: Sound good!

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.
Back to top
Display posts from previous:   
   NeoOffice Forum Index -> NeoOffice Development All times are GMT - 7 Hours
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Powered by phpBB © 2001, 2005 phpBB Group

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © Planamesa Inc.
NeoOffice is a registered trademark of Planamesa Inc. and may not be used without permission.
PHP-Nuke Copyright © 2005 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.