Problem description: It is not possible to use Writer to read a long document properly because it does not align pages properly when page down pressed. Steps to reproduce: 1. Open a large document in Writer under Windows 7. 2. Select "Entire Page" from View/Zoom 3. Press page down. Current behavior: Page down will align the document so that the interpage break is roughly in the middle of the viewing area. The top of the area will show the end of the previous page and the bottom of the area will show the start of the current page. Continued pressing of page down will continue to align the page break in the approximate centre of the viewing area. Expected behavior: Page down should align the document so that the top of the page is at the top of the viewing area and only that page should be visible. Continued pressing of page down should display each successive page taking up the entire viewing area. Further information: This is the same bug that was listed earlier as FDO#65885 and wrongly closed by James a year ago with WORKSFORME when he used LO 4.1.0.1 on OS X 10.8.4. This is a Windows Bug and should not be closed by an Apple user. Operating System: Windows 7 Version: 4.2.5.2 release
hi Warren, James said: > Setting to WORKSFORME. > > If this problem persists with the latest release, please re-open this bug. so my suggestion is to close this bug as a duplicate of Bug 65885 and reopen that one as well. was it you that opened the original report or another user?
I think it best to use this thread and leave the other closed for now. The other was opened by mangled_us@yahoo.com, not by me. Now if someone is interested in fixing this bug that would be great!
@Warren ok. post a screenshot showing exactly the page down issue. @mangled_us@yahoo.com I put you on CC list. are you still reproducing this issue?
Created attachment 103661 [details] Bad alignment in "Entire Page" mode Here is the symptom. If you want any more screen shots just ask.
I confirm issue under Win7x64 using 4.2.5.2, 4.0.6.2 and 4.4.0.0.alpha0+ Build ID: 9f803ee4b64e11e481ae9bf92ffac7cbf568675a TinderBox: Win-x86@42, Branch:master, Time: 2014-07-28_06:27:11 same issue in AOO 4.1. hence bug is inherited from OOo
Also confirmed under GNU/Linux for v3.5.7.2 through v4.3.0.3. Platform set to All/All. Summary edited to remove Windows reference.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.0.5 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-09-03
Bug remains. This doesn't surprise me as it is clear that no one much is doing any work on this project. I'm giving up on LibreOffice and looking for something that works properly. Libre Office v5.0.1.2 Windows 7
@Warren please read this: https://joelmadero.wordpress.com/2014/10/11/user-expectations-and-the-reality-of-our-community/
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Bug remains under v5.2.1.2. This does not surprise me as virtually no bugs are ever fixed here. It's a shame that there is no such thing as a good word processor anymore but that's the idiot world that we have built for ourselves. As for Libre Office: "If you pay peanuts you get monkeys."
You are looking for a different function. Page up/down was never meant to scroll to a particular position. You may either use the Navigator (F5) with its 'previous/next page' buttons, or you assign shortcuts to the function "to beginning of next/previous page" (tools > customize: category Navigate), where you may also choose Page up/down. (See also bug 101211.) WORKSFORME, but feel free to reopen again.
I think we can do without pests like you Heiko, coming along and removing bugs with a simple "works for me". It doesn't work, it IS a bug, and kindly mind your own business next time.
@Warren Heiko was polite. He expressed his opinion about the bug. right or wrong? I don't care... he even told that you were free to reopen if you did not agree. so your reaction seems completely out of place and offensive. this attitude is 10% wrong and not tolerated here. think about it.
May I please ask to keep the tone polite. Heiko has the right (like everybody else) to have an opinion, which he expressed rather politely. Furthermore (which you Warren) might not be aware of, Heiko has UI as his prime responsibility in his work for TDF. We both close/change bugs everyday as part of our job, if you disagree with Heiko and sees this a bug, then contact the UI team, who have the final say about how the UI works (Heiko is part of that team).
(In reply to tommy27 from comment #14) > @Warren > ... > > this attitude is 10% wrong and not tolerated here. > > ... I meant 100% wrong and also comment 11 was unrespectful and offensive towards the LibO project.
Let me make this perfectly clear for anyone who happens to come across this thread. Libre Office is a bloated, bug-ridden piece of crap. Whole sections don't work properly. Bug are reported but never fixed. The only people that do anything are the little clerks who wander around and tut-tut when anybody complains. As you can see here the favourite way that this organisation has of solving bugs is to simply close a bug report with a "works for me". Problem solved! Unless all you tin-pot little pests get a right royal kick up your arse, and start actually solving problems instead of pretending that they don't exist there is no conceivable way that Libre Office will ever be a viable alternative to the hated MS Office. Not that I care, I gave up expecting anything from you dropkicks years ago.
you are a troll.
*** Bug 141249 has been marked as a duplicate of this bug. ***
V Suart Foote marked my report 141249 as a duplicate of this, which, although it is related, it is not. He said "Specific scope of the movement is os/DE dependent, and current zoom level of document canvas. And as with dupe, this remains => WF and would waste dev effort for "taming" the variability by os." First, the exact same behaviour occurs on a Macbook Pro running Mojave 10.14.6 (18G8022), so this is NOT OS dependent, it is inherent in LO Writer. It is a LO bug which should at least be investigated. If it is not reasonably possible to put it right that is a different matter, but this issue can be found referred to many times across the internet (though often poorly described). This is behaviour which a reasonable user should not expect to experience, and is not found in other comparable pieces of software, which behave as expected. Second, making the software behave in the way which experienced IT users reasonably expect is not, and cannot be, a waste of 'dev effort'. But I appreciate the huge amount of resources which have been invested over many years by many IT professionals in developing LO and its predecessors and constituent parts - thank you to all of you.
There is a distinction to be made between "scrolling" actions of PgDn/PgUp and the full page cursor focus movements implemented for bug 105776 PgDn/PgUp will reposition the document canvas view port based on os/DE configuration, similar to the single line scroll movments of the Down/Up cursors. There is no need to touch that as for bug 105776 (and dupes) we've provided functional full page focus movements without disrupting the PgDn/PgUp scroll controls which vary widely depending on os/DE, and which correcting by LO is of questionable utility.
Forgive me, Mr Foote, but you seem to have closed your mind to the possibility of this being a bug and are therefore refusing to engage properly with the problem. The solutions you have offered are mere workarounds. A workaround is a temporary measure for achieving a necessary or desired function which is not available in the software, which can be used, though not fully satisfactory, until the useability issue is addressed in the programming. It is not a solution to the problem in itself. And in this case, the workaround you suggest does not even address my issue. The resolution I am working at does not display a whole page of text; I can see about half a page on the screen. Therefore, moving to the top of the next document page does nothing to help - I need to go to the next section of the page, which begins on the next line below the one currently displayed on the screen. In other word processing programmes I can do this easily. I press pg-dn and my view of the page moves so that the line which is currently the last line on the screen becomes the first or second line, enabling me to read on, uninterrupted by the need find my place. You have again repeated a clearly inaccurate statement; you say "the PgDn/PgUp scroll controls which vary widely depending on os/DE," I explained that I can reproduce the issue on both Windows 10 and Mac Mojave; another post on this thread states that the issue on which this thread is based - which is different but obviously has its roots in the same bug - can be reproduced in Linux too! Your thesis that this is an OS issue is therefore unfounded. You state "correcting by LO is of questionable utility". I disagree. For me and for many others this is a fundamental useability issue which should be addressed. While I am pretty computer literate (my first job in computing was in 1967, programming an IBM 1130 in Fortran using punched cards - look it up!) I have not followed a career in IT. I am therefore not familiar with modern coding, but identifying why this renegade behaviour occurs should be fairly straightforward, requiring just a few step-by-step executions of the relevant piece of code. I would be grateful if you would either acknowledge that this needs to be addressed, or direct me to some contact point where I can take it further. Please understand that I do appreciate what you do!
(In reply to tommy27 from comment #3) > @Warren > ok. post a screenshot showing exactly the page down issue. > > @mangled_us@yahoo.com > I put you on CC list. are you still reproducing this issue? Hi Warren, Thanks for troubling to CC me with this. Yes, I still see the issue on LO Writer V7.1.0.3. It is particularly irritating that when a document is opened in single page mode the first page is initially paginated to occupy one screen space but then paging down moves the page upwards by about 1/3rd of a page and then further presses of <page down> *do* succeed in moving the pages down by 1 whole page worth so after the first miss-location Writer seems to remain perfectly in sync but 1/3 of a page out :-) It's definitely a bug. I am coming to the conclusion wrt open source programs like this and eg FireFox that when a program develops to the point that it is a threat to commercial interests it seems to be the case that specifically the bug-reporting and user-facing elements of the project become increasingly hostile to the description of bugs *as* bugs and very trigger happy about closing them with seemingly *any* behaviour accepted as "intended". Anyone else see this ? Certainly anyone using the hand-wringing association that FF laughingly calls "support" pages these days must feel that John Cale's live act from 1979 plays a part ;-) Boo
Apologies, I see it was tommy27 who CC'd me, not Warren. Boo
(In reply to mangled_us from comment #23) > Thanks for troubling to CC me with this. Yes, I still see the issue on LO > Writer V7.1.0.3. ... Just checked on V7.1.1.2 and the issue still occurs there too, but I guess we all knew that in advance... Boo
(In reply to mangled_us from comment #25) > (In reply to mangled_us from comment #23) > > Thanks for troubling to CC me with this. Yes, I still see the issue on LO > > Writer V7.1.0.3. > ... > > Just checked on V7.1.1.2 and the issue still occurs there too, but I guess > we all knew that in advance... > > Boo And again, the pgDn/pgUp controls will *never* page at full screen increments--they adapt at the current canvas zoom to move the view port an os/DE managed amount. There may be dev effort to adjust those movements for more consistency cross platform--but probably not and it will remains => WF. Otherwise, full page movements were implemented for bug 105776 with full page movements via <Alt>+<pgDn> or <Alt>+<pgUp>, while adding <Shift> will do it with selection.
And again, Mr Foote, there IS consistency cross-platform - the programme behaves consistently in exactly the same unacceptable way, on Windows, on OS X and on Linux. This is not a bug that can be shuffled off to the OS, it is within LibreOffice. It behaves in an unacceptable, illogical manner which is not what a reasonable user should expect and is in line with neither reasonable user expectations nor programming best practice. pg-dn and pg-up keys, as you put it, *always* page at full screen increments (with a 2 or 3 line overlap) on *all other* word processors. Therefore I deduce that it is *possible* for the same behaviour to be achieved in LibreOffice. Good software is developed to maximise user satisfaction, not to pander to the preconceptions of coders (or programmers, as I prefer). The programmer's job is to find ways to fulfil legitimate user expectations. This is an entirely reasonable and legitimate user expectation which deserves to be explored. If other software development teams can achieve the proper functioning of these keys, then so can the LibreOffice team. But if they are blocked by a random decision not to proceed with a sensible and desirable improvement in the user experience, that will result in a further loss of credibility and users for LibreOffice. Please do not stand in the way of progress.
@UX-advise, question of reopening to normalize the editshell calculation of "view port" Y-height for consistent canvas movements down or up in document with the PgDn and PgUP (.uno:PageDown / .uno:PageUp) controls. I think they're here [1] if I'm reading the editshell right. =-ref-= [1] https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit2.cxx?r=dc37866f&mo=53745&fi=1411#1398
(In reply to V Stuart Foote from comment #28) > @UX-advise, question of reopening to normalize the editshell calculation of > "view port" Y-height for consistent canvas movements down or up in document > with the PgDn and PgUP (.uno:PageDown / .uno:PageUp) controls. > > I think they're here [1] if I'm reading the editshell right. > > =-ref-= > [1] > https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit2. > cxx?r=dc37866f&mo=53745&fi=1411#1398 I would say here is a good place to start looking how the .uno:PageDown and .uno:PageUp commands do what they do in the edit view: https://opengrok.libreoffice.org/xref/core/sw/source/uibase/uiview/view2.cxx?r=5262a9e8#569
How about switching shortcuts of .uno:PageDown and .uno:GoToStartOfNextPage when zoom is at entire page level? Might be confusing for users who have customized it, so maybe only if assigned to alt + pg+up/dn.
(In reply to Heiko Tietze from comment #30) > How about switching shortcuts of .uno:PageDown and .uno:GoToStartOfNextPage > when zoom is at entire page level? Might be confusing for users who have > customized it, so maybe only if assigned to alt + pg+up/dn. That wouldn't help in my case. It would be yet another workaround instead of getting to the cause. Having explored LO Writer bugs a bit over the past weeks I think there is a fundamental issue with the implementation of scrolling which is probably related to this bug. Since moving through documents is maybe the most common user interface action I can't understand why these issues have been allowed to go on for so long without being properly investigated. Not being a dev team member I don't feel qualified to change the status of this bug from 'WONTFIX', but as a long-term user I urge a re-think on the importance of this.
*** Bug 141666 has been marked as a duplicate of this bug. ***
I assume VERIFIED WONTFIX being accident? Putting it to UNCONFIRMED (as my bug landed here as duplicate; without the impression this being totally OK) Hope UX taking a look again
Adding al20878@gmail.com from bug 105776 too
We shouldn't mess with OS/DE settings but no objection from UX POV to make pg dn/up scroll exactly the whole page when zoom is at entire page level.
(In reply to Heiko Tietze from comment #35) > We shouldn't mess with OS/DE settings but no objection from UX POV to make > pg dn/up scroll exactly the whole page when zoom is at entire page level. This would only help a very few of the people suffering from this issue. Again you talk about 'messing with the OS/DE settings', but the bug (and it *is* a bug) is OS independent. It should be possible - actually, it needs to be easy - to move the user's view down through a document at any zoom level, so that the user experience is that (s)he is able to read the whole document without having to think about the process of moving to the next area of text. The pg-dn key is the simplest and most obvious way to do this, and in other word processors it works exactly as expected. Why can this not be reproduced in LO? It is *fundamental* to the user experience.
No the reason for reopening this is only to review the calculation of the viewport(s) and why repositioning of the view port is not consistent--either when positioned at the top of the document canvas and first use of .uno:pageDown, or with subsequent scrolling movements up or down with the UNO controls. The viewport height and width is static as set by the current zoom scale of the VCL canvas. And movements of the viewport with UNO controls linked to pgUp or pgDn buttons should be in consistent amounts relative to the zoom scale. Ideally the movement range would consistently reposition the viewport some fixed percentage of the VCL canvas and the zoom scale--and I thought that was being calculated at 9/10's in the edit shell at: https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit2.cxx?r=dc37866f&mo=53745&fi=1411#1398 and that the viewport not moving in that increment needs attention. The new (for bug 105776) <Alt>+<pgDn>/<pgUp> UNO controls ( .uno:GoToStartOfNextPage / .uno:GoToStartOfPrevPage ) do not work against the viewport, they are movements against the document structure. They inherently work in full page increments at any zoom scale. And they were long overdue. But here we need to figure out why the viewport scrolling movements are not well constrained--there could be differences by os/DE, but seems like it should be consistent. Viewport scrolling should depend just on the VCL zoom scale, the current view port Y-height and X-width, and what ever advance percentage is used to calculate the top left and bottom right of the current viewport--and then the values for the following. Consistent either scrolling up or down. IIUC the Smooth scroll function in Writer comes into play about here as well.