Posted: Thu Sep 18, 2003 8:33 am Post subject: New patch is available for testing
After spending the last several weeks working on fixing many of the bugs that people have reported in this forum, I have fixed enough of the bugs that I felt it was time to post a new NeoOffice/J patch for testing.
If you are interested in testing the new patch, you can download the lastest patch binaries and install them in an existing NeoOffice/J 0.0.1 installation using the following steps. Important: this patch will only work on Mac OS 10.2 or higher. Don't bother installing it if you are running Mac OS X 10.1:
cd <NeoJ installation directory>/NeoOfficeJ.app
sudo tar zxvf <path to downloaded *.tar.gz file>
- Restart NeoOffice/J
For those of you that are interested, here is a list of the most visible changes:
1. Emulating a mouse right-click using a mouse "click-and-hold" has been removed. While I liked this feature, it had too many conflicts with many of the OOo tolbar buttons. So now a right-click is generated using a "Ctrl-click" (or right-clicking the mouse if you have a multi-button mouse).
2. Images are now printed at a much higher resolution. Before, images were printed at screen resolution (i.e. 72 dots per inch). Now, images are printed at 288 dots per inch to more closely match the resolution of the average printer.
3. Lines and rotated text are now drawn more smoothly. Before, lines and rotated text appeared jagged. Now, they are drawn nearly as smooth as horizontal lines and text.
4. Page orientation is now automatically set when printing. I moved the Java page setup dialog (e.g. page size, orientation, etc.) to the File -> Printer Settings menu item. This allows the OOo code to automatically set the print orientation to match the document's orientation that has been set in the Format -> Page menu.
5. Java and OOo printing are now synchronized. Before, the OOo code would continue printing even after the Java print dialog has been cancelled or a sburange of pages has been printed. Now, the OOo code will stop printing whenever the Java print job has ended.
6. Printed PDF files can be viwed in the Preview application. Before, opening a PDF file printed from NeoJ would open fine in Adobe Acrobat, but would cause Preview to hang. This problem has been fixed by printing images in small tiled chunks.
7. Presentation documents are no longer blacked out. Before, NeoJ would sometimes paint presentation pages as solid black. Now, all pages are displayed correctly.
If you find any bugs or unexpected behavior, please post them here.
A few bugs and other issues I've noticed thus far after applying the printtest5 patch (in no particular order):
1. There appears to be something very broken with the highlighting of text in Writer. If I type something, select it and then flick the (hovering) pointer between the Highlight and Font Colour buttons in the toolbar, the selection highlight around the text will sometimes disappear (N.B. I haven't pressed any of the buttons, just hovered the mouse over them). Once disappeared, double clicking the text to highlight it again results in bizarre behaviour - text is sometimes highlighted, sometimes not and sometimes the reverse of what you would expect happens. Deleting the text and starting again seems to solve the problem, that is until I repeat the hovering over the Font Colour and Highlight buttons trick.
2. In my Calc document that I'm currently working on as a test, when selecting my chart and then pressing control click to get the contextual menu it takes a very long time for the menu to appear for the first time (at least 5 or so seconds).
3. Switching the General View preferences to Macintosh causes the cloverleaf command symbol to appear as a box in the menu shortcuts
4. Just as a FYI, but you probably know it well enough already, overall performance ranges between the OKish to the very, very slow on my system (iMacDV 400MHz, slot-loading DVD-ROM, 640MB RAM, MacOS X 10.2.6, MacOS Z-9.2.2).
5. Printing appears to be a real CPU and memory hog - I'm seeing a tremendous amount of paging while printing a relatively simple Calc chart. It apparently hasn't even spooled yet and this is my top reading for soffice.bin:
Literally thousands of pages are being paged out to my disk as well... scrub that, I had to force quit in the end. Printing using the hpijs foomatic drivers for a HP Colour LaserJet 4550.
6. This occurred with the printtest4 patch too - when starting up, prior to the appearance of the NeoOffice/J splashscreen, my system will choke badly, presumably due to high CPU usage by NO/J.
Posted: Thu Sep 18, 2003 11:30 pm Post subject: One Bug and One RFE.....
I am very happy with the level of quality that you have been able to deliver with NeoOffice/J!!! Great Job...
Issue-
The problem that I ran into was when I select Print from the file menu the Printer Option box pops up. I then decided that I would like to cancel my print, so I pressed cancel but the native print dialog box still opened up after I cancel the Printer Options box. Not a big issue just seemed to behave incorrectly.
RFE-
Would it be possible to hide the dock and the top menu bar so that presentations can be displayed full screen? This would be a great option!
Joined: Jun 07, 2003 Posts: 234 Location: near Cologne, Germany
Posted: Thu Sep 18, 2003 11:53 pm Post subject:
There's another display-problem in the presentation module with the "printtest5"-patch, I've emailed to Patrick yesterday evening, while the trinity-forum wasn't reachable:
The first side of the presentation wasn't displayed correctly, the centered text ist only a black box. OpenOffice displays this side correctly. Here are some screenshots:
OpenOffice (Mac/X11) http://schlesi.is-a-geek.org:8080/NeoOffice/Temp/oox11
NeoOffice/J with printtest5 http://schlesi.is-a-geek.org:8080/NeoOffice/Temp/neoj
Joined: Sep 18, 2003 Posts: 434 Location: London, UK
Posted: Fri Sep 19, 2003 1:39 am Post subject:
Another bug I noticed yesterday:
In Writer, after creating a Table, I wasn't able to mouse-shift select multiple cells which is similar to what I experienced in Calc spreadsheet cells prior to printtest5
Joined: Sep 18, 2003 Posts: 434 Location: London, UK
Posted: Fri Sep 19, 2003 4:40 am Post subject:
I've repeated (except this time using AppleTalk to a HP LaserJet 4000) the attempt to print my Calc generated chart with the same end result. Severe disk thrashing (I had 6 swapfiles prior to starting the print and this increased to greater than 20 before I decided to force quit). FWIW, I performed a sample 15 on the soffice.bin process prior to force quitting, if that is any help Patrick? Let me know if it is and I'll send it to you.
Note, I was able to successfully print a pure text document from Writer prior to the attempt at the Calc chart, so it doesn't seem likely that it is a printer/print protocol issue.
Thank you everyone for testing this patch so quickly! I've done some quick research on each of the problems. To make things simpler, here's a combined list of the problems reported so far and what I have found:
Quote:
There appears to be something very broken with the highlighting of text in Writer. If I type something, select it and then flick the (hovering) pointer between the Highlight and Font Colour buttons in the toolbar, the selection highlight around the text will sometimes disappear
I believe that this problem is due to "overclipping". Last night, I found a bug in my code that causes some painting to be clipped more than expected. I have fixed this clipping problem in the CVS repository.
Quote:
In my Calc document that I'm currently working on as a test, when selecting my chart and then pressing control click to get the contextual menu it takes a very long time for the menu to appear for the first time
and
Quote:
In Writer, after creating a Table, I wasn't able to mouse-shift select multiple cells which is similar to what I experienced in Calc spreadsheet cells prior to printtest5
I believe that the problem here is that Mac OS X's Java maps a Ctrl-click to a mouse right-click and maps Shift-click to mouse middle-click. They did this to handle mouses with only a single button. OOo, on the other hand, was originally designed for Windows, OS2, Linux, and Solaris where single buttom mice are almost non-existent. On these platforms, a Ctrl-click is very distinct from a mouse right-click. However, on Mac OS X, these are the same action. So, unfortunately, I think that we are stuck with this problem.
Quote:
Switching the General View preferences to Macintosh causes the cloverleaf command symbol to appear as a box in the menu shortcuts
I found that this when you select the "Macintosh" style, OOo shrinks the font size in all of the menus. Not only does this cause problems with the cloverleaf symbol, but it really messes up Japanese characters. It is not obvious where the font size is being reset but I will keep looking for it.
Quote:
Printing appears to be a real CPU and memory hog - I'm seeing a tremendous amount of paging while printing a relatively simple Calc chart. It apparently hasn't even spooled yet
and
Quote:
This occurred with the printtest4 patch too - when starting up, prior to the appearance of the NeoOffice/J splashscreen, my system will choke badly, presumably due to high CPU usage by NO/J.
There are 2 things that I have noticed in the OOo code that appear to make printing such a memory and CPU hog. The first is that fact that OOo converts the pages to be printed into "metafile" format in memory. Then, it renders this "metafile" and sends the rendered page to the printer. The second is that OOo will create a scaled copy of all images to be printed in memory before sending them to the printer. Since printers are usually much higher resolution than the screen, printing an images can consume a lot of memory very quickly.
As for startup, the underlying OOo code is very CPU intensive on all Unix platforms. I know that both I and the Aqua NeoOffice developers have been continually trying to eliminate on the most egregious CPU hogs in the OOo code - event handling - with only limited success so far. On Windows this code is fast but on all Unix platforms it is a memory hog.
Unfortunately, since NeoJ is based on the OOo code, NeoJ inherits all of the OOo bugs and performance problems. CPU usage is (and will be) a problem for OOo on Mac OS X for some time to come.
[quoet]The problem that I ran into was when I select Print from the file menu the Printer Option box pops up. I then decided that I would like to cancel my print, so I pressed cancel but the native print dialog box still opened up after I cancel the Printer Options box.[/quote]
This problem is due to the fact that the OOo Printer Option dialog always returns "OK" even if the "Cancel" button is pressed. In other words, for this dialog box, "Cancel" does not mean cancel. From what I can tell, the "Cancel" button means "use the default values".
Quote:
Would it be possible to hide the dock and the top menu bar so that presentations can be displayed full screen? This would be a great option!
I am no Carbon or Cocoa expert (my background is heavy Java and Unix programming) so I don't know how to do this. However, if someone can post some sample code that does this (or at least shows/hides the Dock), I can put it into the NeoJ code.
Quote:
The first side of the presentation wasn't displayed correctly, the centered text ist only a black box. OpenOffice displays this side correctly.
This is an interestly bug that I am still working on finding a fix for. The problem is that OOo is trying to paint and fill a polygon with 22 points. The strange thing is that this polygon is really a square with each of the corners repeated 5 times. From what I can tell, OOo expects this to paint really tiny rectangles at each corner of the larger rectangle. However, Java fills in the entire larger rectangle that this strange polygon describes.
I have some time today and tomorrow so I am going to work on this last bug and see if I can locate where the fonts are shrinking in the "Macintosh" style menus. When I have some fixes, I will post them and the clipping fix in an updated patch.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Fri Sep 19, 2003 10:11 am Post subject:
pluby wrote:
Quote:
Would it be possible to hide the dock and the top menu bar so that presentations can be displayed full screen? This would be a great option!
I am no Carbon or Cocoa expert (my background is heavy Java and Unix programming) so I don't know how to do this. However, if someone can post some sample code that does this (or at least shows/hides the Dock), I can put it into the NeoJ code.
In Cocoa you need to actually make a new window and put it in the topmost ordering layer on top of the dock and menubar. An example of how to do this for a Cocoa window is in Neo's vcl/aqua/source/window/VCLWindow.m in the VCLWindow_BeginFullScreen() function (and how to get out of it in End).
In Carbon you can try invoking the pair of calls HideMenuBar()/ShowMenuBar() to just get rid of it:
We tried that from X11 OOo and it didn't work...funny that...but I think that was because our process wasn't the one that had the CFRunLoop underneath it for the actual menubar.
To do the dock at the same time with simple calls will, I believe, require using another 10.2 specific feature. There's a pair of calls GetSystemUIMode()/SetSystemUIMode() that should do precisely what you need, but again are not functional on 10.1:
Joined: May 31, 2003 Posts: 219 Location: French Alps
Posted: Fri Sep 19, 2003 10:50 am Post subject: huge swap while printing
I Think I must followup on the printing/swapping issue, as there is a tremendous difference between printest4 and printest5 on this matter.
My graphic file that caused problem on the previous release (without 256m memory limit) now displays correctly but no longer prints. I also stopped the print process when reaching 16 swap files. I was able to print this file with printest4 and the 256m limit and some swapfiles. I though the current limit of 1024m (1Gig) was the cause of such swap use. I tried to switch back to 256meg, but stopped the print when reching 9 swap files which was the max used before. after cancelling (not killing) Neo/J still took time to recover, using 12 sawp files. Even if the swap is correctly released after the print achieve (if it does ever), it's not a possible choice to require such a free space on the disk.
On this point, this patch is a regression over the previous, even using the 256m limit.
On minor issues list I add this one: some of the shortcuts no longer work (they did previously). The command-A=select-all is an exemple.
I don't think it is a regression. Instead, its a tradeoff of memory usage versus image resolution when printing. In printtest4, images were printing at screen resolution (i.e. 72 dpi) whereas in printtest5, images are printing closer to printer resolution (i.e. 288 dpi). This means that each image printed in printtest5 is going to use 16 times more memory than printtest4. Hence all the swapping.
The real question here is which resolution do we use? 72 dpi is much less of a memory hog but it will render images very jagged.
I have no preference either way. However, I think either choice is going to leave someone unhappy.
Joined: Sep 18, 2003 Posts: 434 Location: London, UK
Posted: Fri Sep 19, 2003 11:38 am Post subject:
Another bug - if you use Command-H to hide NO/J, it will hide the app, but it will also cause an h to be typed in your frontmost document (well, in Writer at least, I haven't checked the others)
As for the printing, evidently the way it is at the moment is completely unworkable - it wasn't as though my image (a chart) was terribly complex, yet it ate up over a gig of hard disk space before I had to force quit... and it hadn't even started spooling to the printer. That isn't going to be acceptable to anyone, especially if you don't have much HD space free!
I can't make any recommendations as to how to overcome this as I don't understand the underlying mechanism... obviously 72dpi printing isn't acceptable either... but the current mechanism for printing doesn't look as though it is going to work _________________ PBG4, 1.5GHz, SuperDrive, 1GB RAM, 128MB VRAM, 5400rpm 80GB HD, MacOS X 10.4.5
A gig of disk? That doesn't sound normal. I wonder if there is some sort of infinite recursion that is happening. Can you send the document to my private e-mail: patrick.luby@planamesa.com? Also, how are you measuring swap usage? I would like to see if I get similar swap measurements with your document on my machine.
As for the Command-H problem. That bug is in OOo X11 as well which is why you see if in NeoJ.
Posted: Fri Sep 19, 2003 10:59 pm Post subject: some notes
Well, I'm not near a printer, but my output to PDF shows the graphics are looking a lot better! Much more useable.
My outline bullets are still looking like empty squares and not bullets (and not showing up in printouts).
I'm happier with right-click now. Most Mac mousers are used to ctrl-click for contextual menus.
The shift-click being a Java decision is a bummer. I can see that shift-apple-arrow is a work around for some situations, but it's not nearly as intuitive. Is there some way we could map middle-clicks to shift-click? I don't think there's any use for middle-click in OO (is there?).
Joined: May 31, 2003 Posts: 219 Location: French Alps
Posted: Sat Sep 20, 2003 5:30 am Post subject:
pluby wrote:
I don't think it is a regression. Instead, its a tradeoff of memory usage versus image resolution when printing. In printtest4, images were printing at screen resolution (i.e. 72 dpi) whereas in printtest5, images are printing closer to printer resolution (i.e. 288 dpi). This means that each image printed in printtest5 is going to use 16 times more memory than printtest4. Hence all the swapping.
The real question here is which resolution do we use? 72 dpi is much less of a memory hog but it will render images very jagged.
I have no preference either way. However, I think either choice is going to leave someone unhappy.
and
pluby wrote:
A gig of disk? That doesn't sound normal. I wonder if there is some sort of infinite recursion that is happening.
That's what I meant.
I also stopped printing process around the 1Gb swap space (16 swap files x 80 Mb each).
I vote for this better resolution printing. A page at 288 dpi is around 8 Mpx, say 32 Mb to have it in true colors, a 7 pages document should not be more than 300 Mb, even if all in memory before printing begins. There must be a bug somewhere. And, BTW, is your printing process rendering all pages before starting to print? I don't think this is the problem here, but with a big document this could also lead to unacceptable memory use.
Max
I believe the OOo printing process is rendering all of the images before it draws to NeoJ's first Java print page drawing surface. It does this in OOo X11 as well. How it works is that it the OOo applications (Write, Calc, etc.) render all of the pages into a Windows Metafile format in memory, then they invoke the NeoJ code to send each page to the printer. The only change that NeoJ has that OOo X11 does not is that I set a integer variable to 288 so that the OOo applications think the printer is 288 dpi and provide a java.awt.Graphics object when OOo requests the current page's drawing surface. In theory, the NeoJ Java code should not be holding any extra memory on top of what the OOo applications create.
Of course, there might be bugs in my code. If a NeoJ print job uses up over 1 GB of swap and never ends and it is only a few pages long, then it is likely that one of my printing functions is recursively calling itself and never ending. Or, I have a big memory leak somewhere. These types of bugs would result in more and more memory being allocated until you finally run out. I suspect that JKT's problem might be a recursion problem since JKT is printing only a simple chart.
If you or JKT culd send me a document that has this memory problem, I would really appreciate it. It is much easier to run real documents while in the debugger to see what OOo and NeoJ are actually doing.
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
I don't think there's any use for middle-click in OO (is there?).