Posted: Tue Sep 30, 2003 8:35 pm Post subject: Another printing patch is now available
I have fixed enough of the bugs reported against the last patch 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>
For those of you that are interested, here is a list of the most visible changes:
1. Printing now prints at whatever resolution the printer is set at. This means that if you are printing to a file or printing a preview, you get 72 dpi (just like OOo) but if you are printing to a real printer you get the printer's current resolution. I removed the hardcoded 288 dpi resolution because this makes PDF files extremely large. Now I understand why most PDF documents are set to 72 dpi).
2. I believe that I have finally eliminated the mangled print images. These mangled images were due to Java's PDF driver and, through extensive trial and error, I have implemented code that avoids this problem. Apparently, the Java printing APIs are very fussy!
3. Images no longer print in small tiles. As a result of the fixes for the mangled print images, the code can now print images fully without any tiling. One note: you still need to disable antialiasing in Preview's Preference's window to view the PDF images in Preview. No adjustments are needed to veiw them in Adobe Acrobat.
4. Launching NeoOffice/J by double-clicking a file in the Finder no longer causes an empty Writer document to open. This always annoyed me quite a bit (I have probably opened each of your test documents at least 100 times each) and the fix wasn't very painful to implement.
5. Shift-mouseclick now works. This bug was found by more than one tester and is now fixed.
6. Kerning (i.e. condensing and expanding) text is now supported.
I think that printing is getting solid enough that it might be worth releasing a new NeoOffice/J version. I was thinking of "0.8" or something like that since copy and paste still needs to be done. Although NeoOffice/J is far from perfect, releasing a new version will allow more people to install NeoOffice/J without having to install any test patches to get basic printing support.
I probably won't get around to packaging the release until next week (Dan and I need to update the splash screen and the version numbers in various files), so if you find any show-stopper bugs (i.e. NeoJ hangs or crashes), let me know and I will try to fix them before I push out a new release.
Lastly, I would like to express my thanks to all of the testers who have been patiently testing the patches and sending really good examples of the bugs that they have found. Your efforts have made it much easier to find and fix the bugs.
Patrick
P.S. I have found a way to make all of the NeoJ online help display "Command" instead of "Ctrl". Unfortunately, I could not include this in the patch but I will definitely include it in the next release.
If you want to test this out, you need to open the following file using the "sudo" command and replace all occurrences of "UNIX" with "MAC":
One small suggestion......
Would if be possible when you do the update or package the latest Neo/J that you put in the Brand X icons?? I really hate the OOo images too windows like....
This would be a great addition to add to Neo/J
Thanks if possible....still great if not...
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Tue Sep 30, 2003 10:42 pm Post subject:
It's actually a little tricky to just add in the icons...since NeoJ's built off of the stock OOo 1.0.3 GM, there's no icons and the necessary Ximian patches for using their icons aren't in the source The other problem with using the straight Ximian icons is that this would require translating the alpha bitmap support into Java code...probably painful.
The approach I'm thinking of would be to move in the non-alpha Neo icons derived from the Ximian icons...it shouldn't require tweaking vcl too much, but I need to commune with Patrick to learn how to add in patches and hope it won't be too painful to come up with a way to replace just about all of the .bmp files in a stock OOo checkout for building Neo/J. This may be more relevant in the dev forum,...
Joined: Sep 18, 2003 Posts: 434 Location: London, UK
Posted: Wed Oct 01, 2003 6:59 am Post subject:
A few comments while I test the latest release (printing of my spreadsheet chart now works, woohoo, but I'm having a resolution problem that I want to test fully before making any definitive comments on the results):
1) A new release with a higher 0.x is a definite IMO - NO/J is usable for test purposes, with evident faults, but the current 0.0 notation doesn't give that impression (to my mind it meant "don't even bother downloading and trying to use me yet" - I was extremely surprised to find out just how stable and usable the 0.0 version was and I only downloaded it owing to boredom and a sense of "hell, why not see how far along things are"). A 0.6, 0.7, or 0.8 notation would, IMO, encourage more people to give it a test run and help out with the troubleshooting.
2) However, having said that, there are at least three major issues that remain with NO/J before it can go final. The first is time taken to launch, the second is general UI responsiveness (i.e. lack of) and the third is copy/paste.
I don't know how much can be done about the 1st - probably not a lot, but it is less of an issue if the final 1.0 version is stable and doesn't suck CPU when idle (or have any nasty memory leaks). People can just leave it open once launched (although, the annoying OOo 1.0 feature of closing the app when the last document is closed will cause problems with that!).
The second issue is a huge problem IMO - UI responsiveness has to be hugely improved before a 1.0 final release, or a very high "low-end" spec for running NO/J will have to be recommended. Currently, performance is not good enough on my hardware for it to be usable for proper work - I can live with it while testing, but if I were someone who just came across the app the lack of speed would immediately make me delete the app no matter how good the features.
The third issue is going to be dealt with so I won't comment any further on it.
I guess that, from the above reasoning, to my mind the next release with the printtest patch rolled in, should be version 0.7 at most; then when copy/paste is added, 0.8; and the 0.9 to 1.0 final notations should be reserved for optimising the launch and UI speed so that it can be said hand-on-heart, that 1.0 final is a decently performing native OS X port. Anyway, that's my tuppence on that matter.
Back on topic, a few comments on the current printtest7 patch release that don't relate to printing:
1. This was true of earlier releases as well - on launch, the NO/J splash screen takes a long time (tens of seconds) to appear, thus potentially giving an impression that the app is failing to launch.
2. Is there any way to alter the default window size on launch/of new documents - I like to have mine at fullscreen (1024x768 resolution) and new windows currently appear to be 800x600 and centred on the screen.
3. The interface seems even slower compared to the previous patch. Menus take a long time to appear and alterations to charts take a long time to get reflected in the window. Screen redraws take longer to occur as well.
Cheers,
Jonathan
P.S. I suffered a crash when highlighting a .psd file in an Insert Graphic>From File dialogue in Writer - should I post a crash log here or is there somewhere more appropriate? _________________ PBG4, 1.5GHz, SuperDrive, 1GB RAM, 128MB VRAM, 5400rpm 80GB HD, MacOS X 10.4.5
I don't know how much can be done about the 1st - probably not a lot, but it is less of an issue if the final 1.0 version is stable and doesn't suck CPU when idle (or have any nasty memory leaks). People can just leave it open once launched (although, the annoying OOo 1.0 feature of closing the app when the last document is closed will cause problems with that!).
Unfortunately, OOo is renowned for sucking up CPU on all Unix platforms. I can't tell you how much time I spent last spring trying to change OOo's code so that it does suck so much CPU constantly checking if there is an event to dispatch (OOo never blocks if there are no pending events). The bad news is that OOo has this behavior very tightly wound into their code. Hence, what you see in this patch is what you will likely see for in future releases.
JKT wrote:
The second issue is a huge problem IMO - UI responsiveness has to be hugely improved before a 1.0 final release, or a very high "low-end" spec for running NO/J will have to be recommended. Currently, performance is not good enough on my hardware for it to be usable for proper work - I can live with it while testing, but if I were someone who just came across the app the lack of speed would immediately make me delete the app no matter how good the features.
I have noticed that, in general, NeoJ runs 50% slower on my wife's G3 machine than on my G4 and both have similar amounts of memory and disk. I think performance is important. However, I know it will be very timeconsuming finding and fixing the bottlenecks. So, in the meantime, I think I will put a warning on download for G3 users when I post the next release.
JKT wrote:
I guess that, from the above reasoning, to my mind the next release with the printtest patch rolled in, should be version 0.7 at most; then when copy/paste is added, 0.8; and the 0.9 to 1.0 final notations should be reserved for optimising the launch and UI speed so that it can be said hand-on-heart, that 1.0 final is a decently performing native OS X port. Anyway, that's my tuppence on that matter.
I am not very picky about the release number so 0.7 sounds OK to me. I am also hesitant to put 1.0 on a release too early as this would only encourage a flood of user support questions which I am not prepared to handle.
JKT wrote:
1. This was true of earlier releases as well - on launch, the NO/J splash screen takes a long time (tens of seconds) to appear, thus potentially giving an impression that the app is failing to launch.
I think this is related to the same performance bottlenecks that are found throughout NeoJ.
JKT wrote:
2. Is there any way to alter the default window size on launch/of new documents - I like to have mine at fullscreen (1024x768 resolution) and new windows currently appear to be 800x600 and centred on the screen.
Not that I know of.
JKT wrote:
3. The interface seems even slower compared to the previous patch. Menus take a long time to appear and alterations to charts take a long time to get reflected in the window. Screen redraws take longer to occur as well.
Hmmm. After I posted the new patch yesterday, I did some simple experiments to see if I could identify the general area where the performance bottlenecks are occurring. I know that the problem is not a "Java is slow" problem because when I move the mouse the lines on the rulers immediately update. This is good news as it means the performance bottlenecks are likely in my code (and are therefore probably fixable).
Anyway, in my experiments, I basically disabled all text, shape, and line drawing and opened Jim Laurent's floor plan document (which is really, really slow to open and edit) to see if things were faster. Surprisingly, performance did not change. Since the drawing code itself does not appear to be slow, I suspect that some OOo code is blocking and waiting for something to happen before it proceeds. Now I have to figure out a way to test that theory.
JKT wrote:
P.S. I suffered a crash when highlighting a .psd file in an Insert Graphic>From File dialogue in Writer - should I post a crash log here or is there somewhere more appropriate?
Why don't you open a bug in our new bug tracking site http://bugzilla.neooffice.org. It supports attachments for posting your crash log.
Joined: Sep 18, 2003 Posts: 434 Location: London, UK
Posted: Wed Oct 01, 2003 9:47 am Post subject:
pluby wrote:
I have noticed that, in general, NeoJ runs 50% slower on my wife's G3 machine than on my G4 and both have similar amounts of memory and disk. I think performance is important. However, I know it will be very timeconsuming finding and fixing the bottlenecks. So, in the meantime, I think I will put a warning on download for G3 users when I post the next release.
I think this is sensible until NO/J can be sped up a bit for us low-enders.
pluby wrote:
Why don't you open a bug in our new bug tracking site http://bugzilla.neooffice.org. It supports attachments for posting your crash log.
Patrick
Done, but I forgot to add that this is with the printtest7 patch added and I can't see a way to edit my submission??
P.S. Thanks for the comments. Btw, I didn't mean to imply that 1.0 is a relatively short stride away - definitely wait until it is ready before making that leap
P.P.S. Re: the splash screen. If it could be made to appear sooner (and perhaps include some visual feedback to indicate what is going on) it would get rid of the "is it launching or isn't it" sensation. _________________ PBG4, 1.5GHz, SuperDrive, 1GB RAM, 128MB VRAM, 5400rpm 80GB HD, MacOS X 10.4.5
Joined: Sep 18, 2003 Posts: 434 Location: London, UK
Posted: Wed Oct 01, 2003 1:42 pm Post subject:
OK, I've managed to run a few more tests on my printing with this patch:
1. The Calc chart that I sent you Patrick isn't printing at all well - very fuzzy... it looks like a jpeg scaled up to 500% its original size. I tried playing around with my settings to get a decent image and also trying different printers and printing protocols, but couldn't improve it at all. Anyway, to cut a long story short, I tested a newly created chart and it prints extremely well, so perhaps it is an issue of using a document saved under a previous patch version?
Do you experience the same problem with the copy of my document I sent you?
Btw, this is just the chart/chart text (on page 2 = "Heading" chart) , the sheet 1 spreadsheet text prints very well.
2. From a few very provisional tests, images inserted into Writer print well, but only if you use them at their original size. Altering the dimensions of the image to scale it down leads to fuzzy printing. That is, images don't scale very nicely (perhaps this is a problem with OOo rather than NO/J per se? I haven't time to test OOo) and don't appear to get anti-aliased at all.
Anyway, may get the time to do some more tests, but can't promise anything... I see OOo 1.1 has just been released today. _________________ PBG4, 1.5GHz, SuperDrive, 1GB RAM, 128MB VRAM, 5400rpm 80GB HD, MacOS X 10.4.5
I don't think it has to do with which patch the file was saved in as NeoJ uses the OOo file import and export code without modification. This fuzzy printing has caused me a great deal of trouble. I ran into it on many of the documents that contain images and text in the same page. I thought that I had finally found a way to reduce its occurrence to nearly zero, but that does not appear to be the case.
Here is what I think is happening: Java translates all image, shape, and line drawing operations into PDF. However, when text is drawn on top of an image, it seems to cause the Java PDF translator to sometimes mangle the image. Most likely, in these cases the Java PDF translator is still not finished processing the drawn image or test when Java flushes the PDF to the printer or PDF file.
This image mangling happened quite often with your spreadsheet. Specifically, page 4 seemed to be affected most often. However, in the latest print patch, the image mangling no longer occurs when I print it to a PDF file.
Does it print OK if you select "Preview" in the print dialog? If so, this probably means that the image mangling has something to do with how fast a device can handle to the PDF that Java is spooling. Preview is very fast since it only writes PDF to a file whereas a printer processes PDF much slower.
Since the image mangling seems to only occur when there are images intermixed with text, I have a solution that might finally solve this problem. I planned on implementing it today and tomorrow. Since you have real printers to work with (my old printer died and I haven't bought a new one yet), can I send you a mini-patch to try when I get it implemented?
I forgot to ask you something. When you say "fuzzy", do you mean that the images look "snowy". In other words, is there just a bunch of random colored dots or lines where your image should be?
Or, is the image recognizable but scaled too big?
The first is the "mangled image" problem that I described in my last post. The second would probably be a bug in my page resolution calculation.
Joined: Sep 18, 2003 Posts: 434 Location: London, UK
Posted: Thu Oct 02, 2003 1:52 am Post subject:
pluby wrote:
I forgot to ask you something. When you say "fuzzy", do you mean that the images look "snowy". In other words, is there just a bunch of random colored dots or lines where your image should be?
Or, is the image recognizable but scaled too big?
No snow - the image is recognisable, but scaled too large - the best way I can describe the result is that it looks like the chart was exported as a bitmap, scaled to 10% of its original size, saved and then that saved image was re-enlarged to be 500% its original size. In other words, it looks like a blurry version of the OS X "Zoom" feature, only without the anti-aliasing.
I'll give the "Preview" technique a go and post back the results. Feel free to send me a patch, but I may not get a chance to try it before the weekend. _________________ PBG4, 1.5GHz, SuperDrive, 1GB RAM, 128MB VRAM, 5400rpm 80GB HD, MacOS X 10.4.5
I sounds like images are printing at 72 dpi. Right now, the code asks the printer what its current resolution is. However, from what I have read, it seems Mac OS X may default all printing to 72 dpi until the application requests a higher resolution (if one is available).
Most likely, I would need to probe the printer, ask it what its highest resolution is, and set the resolution to that. I will send you a mini-patch that you can try today or tomorrow.
Joined: Sep 18, 2003 Posts: 434 Location: London, UK
Posted: Thu Oct 02, 2003 4:10 am Post subject:
Hi Patrick,
I tried the Preview route to similar effect - blurry edges.
My previous post overdid the hyperbole a bit... it looks like an image scaled to 75% its original and then enlarged to 150%, so yes, it is probably printing at 72dpi (note - the printer settings I have tried are 600dpi for colour, 1200dpi for B+W, so evidently it isn't picking up the printer settings on this particular graph).
Cheers,
Jonathan _________________ PBG4, 1.5GHz, SuperDrive, 1GB RAM, 128MB VRAM, 5400rpm 80GB HD, MacOS X 10.4.5
Joined: Sep 18, 2003 Posts: 46 Location: Atlanta, Georgia, USA
Posted: Sat Oct 04, 2003 3:06 pm Post subject: Observations
Dear pluby:
You wrote:
Quote:
6. Kerning (i.e. condensing and expanding) text is now supported.
I think that printing is getting solid enough that it might be worth releasing a new NeoOffice/J version.
I believe I have installed the latest patches correctly (would you believe it's the first time I've ever used a terminal window for anything), but
NeoOffice still won't display the true italics, bold, or bold italics of a font. It will merely take the regular font and slant it or fatten it, which is no good. Word spacing and line breaks in existing documents I import from other programs is going to be thrown way off, because it's not using the correct versions of the typefaces.
Since the main thing I use OOo for is word processing, real font typefaces is a very important feature to implement. Is this on the agenda?
Also, I want to report that the speed of your latest patched NeoOffice is just fine on my G4 (Sawtooth) 400 MHz with no graphics acceleration. I don't notice any difference between using NeoOffice and OOo under X11.
Thanks for the good work. I'm going to try using this latest patched version instead of OOo under X11 and see how it works! _________________ Wheat Williams
Atlanta, Georgia, USA
This was a trivial change to make. For some reason (I cannot remember why I implemented it), the code was filtering out all fonts that ended with "bold" or "italic" in their names.
I just removed this 6 line filter and now all of the fonts like "Helvetica Bold" and "Helvetica CY Bold" show up.
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
The other problem with using the straight Ximian icons is that this would require translating the alpha bitmap support into Java code...probably painful.
