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

Download or installation problems? Try these steps
Problems after upgrading to NeoOffice 2017? Try these steps


Support
· NeoOffice Support
· NeoWiki


Announcements
· Twitter @NeoOffice


Downloads
· Download NeoOffice


RSS Feeds
· Announcements Only
· All Posts


  
NeoOffice :: View topic - NeoOffice/J 0.7 patch available
NeoOffice/J 0.7 patch available
 
Post new topic   Reply to topic    NeoOffice Forum Index -> NeoOffice Testing
View previous topic :: View next topic  
Author Message
Max_Barel
Oracle


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

PostPosted: Wed Nov 26, 2003 12:01 pm    Post subject: Reply with quote

pluby wrote:
Is printing messed up with patch5v2?
No. Not in this way in fact. The previous bug does not show up, but as you can't set the printer destination without crashing, the print is not correctly scaled (margin stuff). But no kerning issue.
pluby wrote:
If so, does this problem going away with the above patch?
The kerning issue is back. As soon as I change the printer destination to get the correct page size and minimun margins. This is mandatory to be able to print without scaling nor clipping.
It usable but tricky to print what you want.
Do you want me to post at bugzilla on this an attach the file to reproduce the bug?
The overall speed seems to be correct again. The patch 5 is really SLOW.
Back to top
View user's profile Send private message Visit poster's website AIM Address
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11911
Location: California, USA

PostPosted: Wed Nov 26, 2003 1:42 pm    Post subject: Reply with quote

Yes. Please log a bug in Bugzilla.

FYI. The speed was faster in the last few patches because I replaced Java 1.3.1's thread locking functions with my own to enable running an event loop in the main thread (Java runs its event loop in a separate thread which causes the keyboard layout changing problem).

Patrick
Back to top
View user's profile Send private message Visit poster's website
Apricot
Pure-blooded Human


Joined: May 31, 2003
Posts: 38

PostPosted: Thu Nov 27, 2003 10:16 am    Post subject: Reply with quote

Printing seems okay in p6. I've only notice two oddities so far.

I posted to Bugzilla a weird spreadsheet sluggishness.

Also, somehow a document full of OO Formulas got partly messed up. Formulas of the form [ a_1, a_2, a_3 ] were displaying with the brackets super-low. I can't reproduce it so far, but I'll be on the lookout since I'm using Formulas now a lot more now that I've discovered how elegant they are.

Great work and happy thanksgiving!
Back to top
View user's profile Send private message
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11911
Location: California, USA

PostPosted: Thu Dec 04, 2003 9:22 pm    Post subject: Reply with quote

After many dark days cursing Panther, I think that I have a stable fix for the Panther keyboard layout menu problem without the weird side effects that occurred in previous patches.

I have posted a new patch that contains this fix at:

http://www.planamesa.com/neojava/downloads/temp/NeoOfficeJ-0.7-patch-7.tar.gz

This patch also contains fixes for the "windows are blank after unhiding" problem and the "font kerning is messed up after displaying the printer setup dialog" problem.

I must say that Apple really broke some of their own code in Panther. Panther requires that an event loop be running in the main thread. However, they didn't bother to up Java 1.3.1 to conform to this new requirement. Hence, all Java 1.3.1 applications are affected by this keyboard layout menu problem and the "windows are blank after unhiding an application".

Fortunately, I have found ways to work around these problems. Too bad it required 3 solid weeks of reverse engineering to find workarounds for their bugs. It makes me wonder if Apple even bothers to anything more than cursory testing for many of the libraries that it ships as part of the OS.

One other note: many of you mentioned that some of the earlier patches made NeoJ a lot faster. I found out why. Most of the slowness is due to Apple's code that prevents more than one thread from drawing at the same like. In the fast patches, I had replaced this locking code with really simple locking functions.

Unfortunately, my simple locking code only works about 90% of the time. 10% of the time events are missed or the application seizes up. So, for now, we are stuck with Apple's slower locking code. Sad

Anyway, please post any bugs you find in http://bugzilla.neooffice.org. If there aren't very many bugs, I will push out a 0.7.1 release in a week or two.

Patrick
Back to top
View user's profile Send private message Visit poster's website
Apricot
Pure-blooded Human


Joined: May 31, 2003
Posts: 38

PostPosted: Mon Dec 08, 2003 10:51 am    Post subject: Reply with quote

hi Patrick,

I thought I'd post a brief update. I've used p7 a little less than usual (I've been traveling), but just today I experienced the dreaded 'soffice.bin has quit'. I'm not sure what triggered it. I was in the middle of a drag, but it was in another document. It's possible it crossed over a NeoJ window... I'll try to reproduce it...

On the good side, the printing dialogs seem okay.

- A

ps. I didn't have any crashing problems with p5v1, but I suppose it had the keyboard issue?
Back to top
View user's profile Send private message
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11911
Location: California, USA

PostPosted: Mon Dec 08, 2003 10:55 pm    Post subject: Reply with quote

Apricot,

Can you try using "patch-8" that I just uploaded? I don't think it will make much difference, but maybe the crash will be more reproducible.

When you have a crash, can you post your crash soffice.bin crash log in Bugzilla? That will help tell me what is going on.

Also, one thing that might cause crashing is that in the last few patches I removed the printer resolution limit. So, if you have a 1200 DPI printer with lots of images, you are much more likely to see a crash than if you had a 300 DPI printer. If this is the case for you, maybe I should consider adding back the 300 DPI limit.

Patrick
Back to top
View user's profile Send private message Visit poster's website
Apricot
Pure-blooded Human


Joined: May 31, 2003
Posts: 38

PostPosted: Tue Dec 09, 2003 1:27 am    Post subject: Reply with quote

Hi Patrick,

I've got p8 installed now. The printing is not working now, I'm afraid. Only the top left corner of each page prints. I have a Brother HL-1470N which I print to using IP Printing. However, it happens even if you Preview.

No crashes in brief use. I'll post the console next crash.

- A
Back to top
View user's profile Send private message
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11911
Location: California, USA

PostPosted: Tue Dec 09, 2003 2:19 am    Post subject: Reply with quote

Apricot,

I deleted "patch-8" and reuploaded "patch-7" so that you can revert back to "patch-7".

I was able to replicate your problem by changing the "Reduce Bitmap Resolution" setting in Tools->Options->Print. Apparently, my post-"patch-7" printing enhancements broke my code that sets the printer page resolution.

I will look at the bug tomorrow and post a new "patch-8" when I fix it.

Thanks for testing this,

Patrick
Back to top
View user's profile Send private message Visit poster's website
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11911
Location: California, USA

PostPosted: Tue Dec 09, 2003 11:35 pm    Post subject: Reply with quote

After last night's problems, I have fixed and reuploaded "patch-8". The patch is available at the following URL:

http://www.planamesa.com/neojava/downloads/temp/NeoOfficeJ-0.7-patch-8.tar.gz

"patch-8" has the following changes from "patch-7":

1. Printing a range of pages no longer causes NeoJ to prepare all pages for printing. So, if you print pages 10 through 12, NeoJ will start printing page 10 and will stop after page 12. Before this change, NeoJ would prepare all pages for printing starting at page 1 through the last page of the document.

2. If you select the "Reversed" check box in the "Print Options" dialog and a range of pages is specified in the native "Print" dialog, the correct pages will be printed.

3. The native "Print" dialog is now displayed before the "Print Options" dialog. This is similar to the order of dialog display in the OOo X11 code.

4. The "Print Options" dialog is now a modal dialog like in the OOo X11 code.

Let me know if you find any problems. If there are no major problems reported in the next week or so, I will put this patch into a NeoJ 0.7.1 release later this month.

Patrick
Back to top
View user's profile Send private message Visit poster's website
Max_Barel
Oracle


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

PostPosted: Wed Dec 10, 2003 6:55 pm    Post subject: print resolution again and again Reply with quote

Patrick,
I tried very hard those last few days to find out why my graphic intensive "press review" (.sxd) file do not print with NeoJ. I found that it's due to the fact I used a hatch pattern for the background of pages. Nevertheless I didn't succeed in my attempt to reduce the problem to one simple observation. Therefore, it's difficult to submit a bug to bugzilla and I prefer to tell my observations here. Maybe you can find out.

The problem is related to printing resolution. I used a file with only the first page of the problematic file.

- with the "reduce bitmap" option set, and "optimal quality" (300 dpi) selected, the file prints.

- with the "reduce bitmap" option set, and "standard quality" (200 dpi) selected, the file prints.

- with the "reduce bitmap" option unset:
- if I suppress the background hatching, the page prints (preview) correctly.
- if I keep the background hatching and only one image, the file prints also.
- with all images (6), and a few captions and lines, the pdf produced and displayed only show a part (a quarter) of the whole page, as if it has been clipped at mid width and height.

- with a custom resolution set to 600 dpi the result is the same.

All images are jpeg scanned at 300 dpi.

Other test I made show that the "automatic" resolution ("reduce bitmap" unset) of a simple page with only one image on it, is printed at 300 dpi. A PDF file at 200 dpi is approximately half the size of a 300 dpi which is correct.

I also made an other observation which may or may not be related: when inserting an image in a page, if you choose to copy the picture rather than linking to the file, the dimensions of the inserted image is calculated on 72 dpi. The same image inserted with a link is scaled on 101 dpi, close to my screen resolution. This is because I set the display to 106% to match my hardware. At 100% display resolution the image size is calculated at 96 dpi. After saving-closing-reopening the file, both linked and copied image are sized on the correct 96*display ratio. But as I set a 33% display factor to the picture when inserting it, trying to match its original size, the copied image is now bigger than the linked one and its scale factor must now be reset from 45 to 33%. This is a true bug, minor thought, if does not lead to other effects.

Abstract:
I have a suspicion that there might be a bug in calculation of the size/resolution of the rendered image and its components, maybe a few 72dpi constants spread over the sources.

The good new is that setting "reduce bitmap" and "optimal resolution" options allow the printing of my pages, with all components, good quality, in a time I can bear.

Final note: I verified all this stuff with the last patch-8.

Max
Back to top
View user's profile Send private message Visit poster's website AIM Address
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11911
Location: California, USA

PostPosted: Thu Dec 11, 2003 12:01 am    Post subject: Reply with quote

Max,

From your description of the problem, it was very easy for me to find the cause.

The problem that you are seeing is due to a last minute change that I made before I uploaded "patch-8". The change is that I added back the 300 DPI resolution limit that is in NeoJ 0.7 but was not in some of the previous patches.

The problem was that, in my haste to add it back, I added back the limiting code in a different place than where it was in NeoJ 0.7. Since my printer has a maximum resolution of only 300 DPI, I did not notice any problems. So, earlier this evening, I changed the code to limit resolution to 150 DPI just to see what happens and, sure enough, I got the "half page by half page blown up to a full page" effect that you described.

Anyway, I have put the 300 DPI limiting code in the same place as where it
was in the NeoJ 0.7 release and uploaded a new patch. "patch-9" is available here:

http://www.planamesa.com/neojava/downloads/temp/NeoOfficeJ-0.7-patch-9.tar.gz

Please let me know if you still have any problems with the resolution.

Patrick
Back to top
View user's profile Send private message Visit poster's website
Max_Barel
Oracle


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

PostPosted: Thu Dec 11, 2003 5:47 pm    Post subject: Well, not yet. Reply with quote

With patch 9 :
- at 200 dpi everything is fine. PDF size 4Mo.
- at 300 dpi (either explicitly or "optimal") pictures are ok but background and texts are "morphed" by a factor of 2 in width. PDF size is 16Mo, twice as expected. The kerning of fonts is ok, only the characters width is double, so characters overlap.
- with "reduce bitmap" unset. Pictures still are ok and printed with better resolution (600 presumably). Text still double width (at 600dpi). Background still has a 2:1 ratio but now it's half height rather than double width. PDF size is 18Mo.

In the process I noticed that text printing is bitmaped rather than using vectorized fonts.

The 72 dpi sizing of copied images is still there.
Max
Back to top
View user's profile Send private message Visit poster's website AIM Address
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11911
Location: California, USA

PostPosted: Thu Dec 11, 2003 10:12 pm    Post subject: Re: Well, not yet. Reply with quote

Max,

Max_Barel wrote:
- at 300 dpi (either explicitly or "optimal") pictures are ok but background and texts are "morphed" by a factor of 2 in width. PDF size is 16Mo, twice as expected. The kerning of fonts is ok, only the characters width is double, so characters overlap.
- with "reduce bitmap" unset. Pictures still are ok and printed with better resolution (600 presumably). Text still double width (at 600dpi). Background still has a 2:1 ratio but now it's half height rather than double width. PDF size is 18Mo.


Interesting, I don't know why, but I suspect this behavior is due to the page range limiting code. I will look at this tomorrow.

Max_Barel wrote:
In the process I noticed that text printing is bitmaped rather than using vectorized fonts.


If you print with transparency enabled, the OOo code draws the page to a bitmap (including text) and then prints the bitmap to the printer page. Although PDF can handle transparent images, OOo cannot. As a result, OOo uses this technique.

Max_Barel wrote:
The 72 dpi sizing of copied images is still there.
Max


In Java, the default printer resolution is 72 DPI. Since my NeoJ code does not reset it until after the print dialog is displayed, my guess is that the OOo code is pre-scaling some images based on the default printer resolution. IIRC, the OOo code probes the default printer at startup which might be the source of the problem.

I will also look at this problem tomorrow.

Patrick
Back to top
View user's profile Send private message Visit poster's website
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11911
Location: California, USA

PostPosted: Fri Dec 12, 2003 6:24 pm    Post subject: Reply with quote

Max,

I think that I found the source of the problem. From what I could see, it appears that my code was setting the printer resolution to a resolution that is not explicitly supported by the printer. Then, when Java printing code handles text drawing operations, this causes Java to mismatch the font size.

I could not replicate your 72 DPI problem. However, I didn't try to until after I made fix for the stretched text problem. In any case, I have uploaded "patch-10" so that you can test my fixes. Let me know what, if anything, is still broken with this patch:

http://www.planamesa.com/neojava/downloads/temp/NeoOfficeJ-0.7-patch-10.tar.gz

One note: when you preview printed documents with the hash background, it might appear that the hash lines are too far apart. This is actually due to Preview and Adobe Acrobat smoothing the lines. If you zoom the document to more than 400% in Preview or Adobe Acrobat, the hash lines should appear. This smoothing behavior usually happens when you print with transparency support enabled since the OOo code print the lines to an image and then prints the image.

Jim,

This patch contains the bug #40 fix.

Patrick
Back to top
View user's profile Send private message Visit poster's website
Max_Barel
Oracle


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

PostPosted: Sat Dec 13, 2003 6:54 am    Post subject: Almost Reply with quote

pluby wrote:
I think that I found the source of the problem.
...
Let me know what, if anything, is still broken with this patch:
This patch do solve the morphing bug. Page prints correclty at 200 or 300 dpi, with transparency reduced or not.
With "reduce bitmap" unset, this patch generate a 300 dpi resolution PDF. This is ok for my printer, I don't know if it could handle correclty a true 600 dpi color printer.
The bad news is that this patch introduce a bug with printer selection. All files, new untitled or saved before now open with "any printer" selected. Trying to select the real printer destination (to get settings, as usal) cause Neo to crash. This is easy to replicate since it happens on a new blank file, drawing or text. Nevertheless, I noticed that if I print the file, clipping it to default margin, and then try to set the printer, this sometimes succeed, after quite a long response time. I post a crash log in a private mail, not to mess this topic.
pluby wrote:
I could not replicate your 72 DPI problem.
To replicate:
- open a blank drawing.
- insert an image, without checking the "link" chekbox. Use one which is bigger than can display on the page to get it automatically scaled.
- click on the "clip" button of the toolbar.
- watch the "full size" figures and the display ratio percentage. They are calculated on 72 dpi resolution.
- save the file, close it and reopen: now the same dialog show figures according to 96 dpi (with display ration applied).
When linking the image rather than copying, the 72 dpi step does not happens.
Max
Back to top
View user's profile Send private message Visit poster's website AIM Address
Display posts from previous:   
Post new topic   Reply to topic    NeoOffice Forum Index -> NeoOffice Testing All times are GMT - 7 Hours
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Page 4 of 6

 
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.
Page Generation: 0.02 Seconds