Apache OpenOffice (AOO) Bugzilla – Issue 5274
Zoom reset to 100% after dialog
Last modified: 2013-08-07 14:41:36 UTC
Steps to reproduce: 1. Create a new Writer document 2. Set Zoom to 100% 3. Paste the some text in it. (e.g. readme.txt) 4. Set Zoom to Page Width 5. Menu: Format Character... 6. Close dialog with ESC 7. Start scrolling Bug: Every part of the document that is redrawn is displayed with a 100% scale. Some areas on the screen will not get updated any more. Zoom display in status line is still at 126%. (I'll provide a more detailed description with screen-shots, if you are unable to reproduce the problem.)
I can't get this to reproduce, though I have seen numerous other display funnies involving zoom and changing from page view to online view: see issue 6069
Created attachment 2123 [details] Screen shot after step 3
Created attachment 2124 [details] Screen shot step 4
Created attachment 2125 [details] Screen shot after step 6
Created attachment 2126 [details] Screen shot after step 4
Created attachment 2127 [details] Screen shot step 5
Created attachment 2128 [details] Screen shot after step 7
Patrick, thanks for all the effort in posting the screenshots. Maybe it's my image viewer but step_7.gif and step_4b.gif both look more "zoomed" in than step_1.gif. Do you have a particular text file that causes the problem consistently? If you do, it would be great if you could post it. Tried duplicating the issue on RedHat 7.3 workstation install, Gnome, OO 1.0. Will be testing on a Windows box later.
> Maybe it's my image viewer but step_7.gif and step_4b.gif both look > more "zoomed" in than step_1.gif. Step 4a is setting Zoom from 100% to Page Width (126%) > Do you have a particular text file that causes the problem > consistently? If you do, it would be great if you could post it. I had the problem with all files. For the screen shots, I've copy&pasted the oo readme-file from notepad to oo. > Tried duplicating the issue on RedHat 7.3 workstation install, Gnome, > OO 1.0. Will be testing on a Windows box later. I could not reproduce the problem on linux either. I think it's windows specific.
Thanks for the update Patrick. I'll run a test on a Windows box soon. Unable to duplicate issue on Solaris 8, latest SunSolve patches for core and J2SE, CDE.
Unable to duplicate issue on Win NT 4.0, OO 1.0.
I've just tried to reproduce the problem on NT4 WS and Win2k Server. The problem is the same as on my first Win2k Prof installation which means that I now have 3 'different' installations that show the problem. However, all installations have 2 things in common: - They are virtual PCs created within vmWare. (I'm sure this is not the problem.) - The OS is freshly installed - no other software is installed - not even Java. Could this be the cause? I can offer you the following two possibilities: - I could send you the vmWare files (zip 50 MB) which you could load into vmWare (30 day free demo) to reproduce the problem. - I could provide you with Terminal Server access to the Win2k Server installation for a limited time. (Logon to my system over my 64kb line would be slow...) Please contact me at support@gautschi.net for either choice.
Thanks for the update Patrick.
I've just installed OO 1.0.1 on a new machine running Windows .NET Standard Server RC1 English. I even installed Java 1.4.0 before OO. The Result: The bug is still there as it ever was. I've now done the test on 2 dirrerent machines useing 3 different operating systems and 2 different versions of OO. The problem was visible on all combinations. (I - as a software developer - would call this reproducible!) Note: This bug makes OO completely unusable. ... and an ohther observation: the bug occurs with Format/Character but not with Format/Paragraph.
FYI: I could not reproduce the bug on Win XP Pro, OOo 1.0.1. Could also be a grafics card driver problem...
Created attachment 2523 [details] Video (Windows Media 7 Screen Capture) showing steps to reproduce the bug
It's not the grafics card driver. (I've tested on two completely different machines.) I believe it's not your installation/machine that is different from mine, but what you do to reproduce the problem. I've just posted a video (screen capture 1024x768) showing what I do to reproduce. Could you try again, doing exactly the same as I did?
Thanks for all the work Patrick.
I tried to recreate this bug, but was unable to. My configuration is a PIII733 (or maybe a 766), with 128meg RAM, running Win2k SP2. I've got OOo 1.0.1 and already had the 1.4.0 version of the jdk installed on my machine when I installed OOo. My video card is an ATI Rage 128 GL AGP, with 16meg of onboard memory. I did have a few lines of thought that popped into my head for Patrick. I don't know if any of these are the "right" path or not, but they were things that might prove helpful. 1) What video card are you running, and how much video memory does it have? 2) From the video, it looks like you scrolled back to the top of the document after pasting the text in. Did you do this with the scroll bar, or with Ctrl-Home, or some other way? I tried both ways on my machine and neither worked, but this may still prove to be useful... 3) What resolution/refresh rate/color depth do you usually run at? I tried all the resolutions on my video card (640x480, 800x600, 1024x768, 1152x864, 1280x1024, 1600x1200) and didn't see it, but some of the other settings might be involved as well. Do the two machines you've seen the problem on have the same display settings?
Andy, the key thing to note is that Patrick encounters this problem inside VMware on a Windows box. I don't have the resources at this point in time to setup VMware and run a test. Sorry Patrick.
I also could not reproduce this issue on WinNT 4, SP6, OO v1.0.1
Thank you all for following up on this issue. To answer your questions and to clarify some information, I would like to summarize some facts: - The problem occurs on NT4 SP5, Win2k SP2 and .NET Server RC1 - The problem occurs within VMware as well as on an 'real' PC. (see posting 2002-08-01) This proves that the problem is NOT RELATED TO VMware. - The problem occurs with 4 different graphic drives. (VMware for NT4, VMware for Win2k, Microsoft RDP driver when run in a terminal session, ATI Rage on my notebook). -> The bug is NOT RELATED to a particular driver. - It occurs with or without Java installed - It occurs with 1024x786 and 1280x1024. (I think I used the 'small font' (96 dpi) settings; all tests done with 24 or 32 bit/pixel) - I used Ctrl-Home to go to the top of the document. Developing software for about 20 years and after all these tests, I'm sure it's not the graphic driver or VMware. One thing that was common on all test environments I used, was that all were freshly set up with only Windows, the Service Pack and OO installed. Could you try to reproduce the problem in such an environment?
(Parag Mujumadar , 09/12/02) Hello Everybody , I successfully replicated the bug mentioned in the report , on PIII system , with win2000 operating system. I have some doubts , which I will like to put forward : 1.I could not replicate the last sentence “Zoom display in status line is still at 126%.” 2.Why it happens with opening and closing of “menu : character…” dilog box only …and not with other dilog boxes? Thank you for presenting nice report. Removing this bug will definitely help people in editing business as well as other regular users.
I've got good news for you - I could find the reason why it was so difficult for you to reproduce the problem. I was thinking all day long what could be different on my machine. It's installed from scratch - only Windows and OO installed. What could you have on your machine that I have not? IE with it's Common Controls? Additional fonts? Printers? --- Printers?! --- Bingo! I don't have any printers installed. ... and believe it or not - after installing a printer the problem was gone. After deleting the printer it reappeared. I think it should now be possible to reproduce the problem on 'any' Windows system. If i had to guess what really causes the problem, I would say that the DC of the window is manipulated instead of the (not existing) printer DC. (just a thought) The second good news is that there is a simple work around - just install a printer. I think I'm going to update from StarOffice 5.2 to OO 1.0.1 now...
I can confirm that it is, in fact, the absence of printers that makes the bug reproducible. I deleted the printer from my machine, and performed the steps as Patrick described. My txt file this time was short enough so that I didn't have to type Ctrl-Home to see the top of the document again. However, I did have enough that I could scroll and saw the same problem that Patrick described. Good thinking, Patrick!
A repaint error with such an easy Workaround is Prio 4.
Funny variation that I found: Set Zoom to optimal and toy with the window width: The font changes and therefore sometimes the words hop from one line to another due to reformatting with different font spacing. SBA->FME: As discussed: Another display/repaint problem when the formatting depends on the graphic output, see internal #102559.
FME->SBA: Can you still reproduce this.
I think that this one vanished with the "printer independant layout" feature. - Not reproducible in Build 645.
Closed.