Description: Enabling AutoFilter and then selecting some filter parameters sets what appears to be a random page break both in the on-screen print preview and the actual printed document. I suspect the false page break is related to where it should have been if the data had not been filtered. When the filtration is applied, the "valid" page breaks become anchored to the new on-screen virtual row locations of the filtered data. When the filter is removed, the page breaks remain anchored in the wrong locations, resulting in variable depth pages. The effect can then be seen by switching to print preview mode and scrolling through the pages. Printed output is similarly erroneous. Additionally, if a filter is applied, the line numbers are adjusted to reflect the true line positions in the table but if a contiguous block of data elements is selected by cursor marquee then the count of rows indicated at the foot of the display identifies the number of rows in the table between the first and last element as opposed to the number of visible rows physically selected. Steps to Reproduce: Build a data table and view it in print preview to ensure the page breaks are correctly located. Physically printing will confirm the integrity Select top row of the data table and AutoFilter Apply any filtration on any column(s) that will change the order of the data Observe that the physical table line numbers are still reproduced in the row numbers alongside the table. eg 1,3,7,11,99,125,156,175, etc,. Select contiguous columnar cells in the visible table and verify that the indicated count of rows is the number of rows between all the records in the table NOT the selected group. The above example would produce 175 as opposed to 8. Nullify the filter by whatever method best pleases you - re-sort on column one, cancel all filtration in the menu, select the filtered column and "undo" the filter. I have attached a CALC sheet with the same data table replicated on two tabs. The first tab has had the filter applied and removed and demonstrates the false anchoring. The second tab shows the data in never filtered form. Print preview will demonstrate the effect. Interestingly if the source data on the affected tab is cut and pasted to a new tab then the filter anomaly is expunged. This permits the easy replication of a "clean" table for experimentation. Actual Results: The page breaks become inconsistent with the actual number of lines on a page and are variable - presumably based upon the relocation of the original correct row page breaks Expected Results: Print preview to show properly configured pages. Physical print to produce properly configured pages Selection of contiguous rows to show the count of rows selected NOT the count of rows between first and last record number in the selection Reproducible: Always User Profile Reset: Yes Additional Info: Version: 6.0.3.2 (x64) Build ID: 8f48d515416608e3a835360314dac7e47fd0b821 CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: sv-SE (en_GB); Calc: group User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Created attachment 142077 [details] two page spreadsheet demonstrating the effect and a clean control
possibly related to 64703
Just discovered another aspect of the issue. My source data normally comes from a downloaded Excel format spreadsheet. If I open it and process it in Libre as an excel sheet the filter seems to work as anticipated - it only seems to go wrong after I perform a few initial adjustments prior to saving it as a Libre Document. Then, when the Libre document is opened in Libre:) - it's producing the anomalies.
I tried to reproduce it, but it seems you have to give more exact steps. In the Unpaid@May9 sheet I did Data - Autofilter. I unticked several names in the Efternamn column, OK. I reset the filter in the Efternamn column by ticking All, OK The print preview looked the same as before any of my actions. NEEDINFO while we wait for exact steps. Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: 8447d31e529985ef7fc71933f0e55685530f9fc9 CPU threads: 8; OS: Linux 4.16; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded Built on June 14th 2018
(In reply to Buovjaga from comment #4) > I tried to reproduce it, but it seems you have to give more exact steps. > > In the Unpaid@May9 sheet I did Data - Autofilter. > I unticked several names in the Efternamn column, OK. > I reset the filter in the Efternamn column by ticking All, OK > > The print preview looked the same as before any of my actions. > > NEEDINFO while we wait for exact steps. > > Arch Linux 64-bit > Version: 6.2.0.0.alpha0+ > Build ID: 8447d31e529985ef7fc71933f0e55685530f9fc9 > CPU threads: 8; OS: Linux 4.16; UI render: default; VCL: kde4; > Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded > Built on June 14th 2018 I'm using WIN 10 x64 not Linux. Could this be a contributory factor? Also, removing a name only removes 1 item so removing three may not produce immediately noticeable anomalous results. If it's the first three, one page short three lines might not seem to be an error. If it's three random names occurring on their own discrete pages then also, one line short may not be noticeable. Try removing one (or more) of the other items where there are multiple lines for each "event" - date groups are a good target - and then after sorting on the significantly reduced sample, sort on a different column. Also, removing a more significant sample will also make it easier to verify that perhaps eight visible contiguous cells have been selected but the statistical count at the bottom may indicate 157 selected. If the first sheet in the sample provided did not reproduce the effect simply by opening it then I think there must be an OS related variance because the condition survives closing and reopening the document in WIN 10.
The first sheet shows the effect, but I think it only makes sense to consider this a bug, if we can reproduce it reliably. I still was not able to reproduce it. If you can reproduce it with clear steps, please enumerate them. What I tried in Unpaid@May9 after Data - Autofilter 1. Unticked 2017 December in ExpDate 2. Sorted ExpDate descending 3. Sorted Efternamn descending 4. Set ExpDate to All again
(In reply to Buovjaga from comment #6) > The first sheet shows the effect, but I think it only makes sense to > consider this a bug, if we can reproduce it reliably. > > I still was not able to reproduce it. If you can reproduce it with clear > steps, please enumerate them. > > What I tried in Unpaid@May9 after Data - Autofilter > 1. Unticked 2017 December in ExpDate > 2. Sorted ExpDate descending > 3. Sorted Efternamn descending > 4. Set ExpDate to All again I think it is probably worth considering the other aspect of the anomaly which may actually provide more analysable results. If the anomaly is present in the test it could confirm the bug's existence. 1) Filter the data in any manner that produces "clusters" of non-contiguous data. 2) visually verify that the data elements are not sequential item 3) select a visible block of say 10 records 4) compare the number of records selected with the "statistical" data count presented at the bottom of the sheet. If that is not also 10 it will probably be a verifiable symptom of the reported anomaly. Is it worth considering that I only use a virtual pdf printer (Bullzip)? Could there be a conflict between Bullzip's interpretation of what is the page compared with Librecalc's? In the meantime, I shall run a step by step simulation and produce the appropriate documentation but I'm a little over-committed to other issues at present so I doubt I can compete on delivery against the "cluster count" test suggested above.
Created attachment 146280 [details] Simple calc with pre-filtered status three additional screen images will be submitted individually as I can't seem to find a facility for multiple document upload
Created attachment 146281 [details] self explanatory screen image
Created attachment 146282 [details] self explanatory screen image
Created attachment 146283 [details] self explanatory screen image
Note; there is an error in the text overlay on the first image where I have inadvertently identified the count as between elements 1 & 2 as opposed to the correct elements 1 & 3. More haste less speed :(
Just noticed that I never saved the text overlay to the third image. It simply identifies that an ascending sort on the pre-filtered column whilst not changing anything visibly, does accrue the correct selection summary statistics.
Further experiments on the latest submitted sheet clearly demonstrate that if the three filtered data elements are sorted on any column and subsequently marquee selected then, with the exception of the column which has been "filtered", they all produce different summaries. The success rate clearly drops dramatically depending upon how many autofilter columns exist in the sheet.
@Colin - I'm sorry but this bug report is a disaster - you have violated several bug reporting etiquettes that make this VERY hard to follow. Also, you did not clearly answer Buovjaga's request for SIMPLE delineated steps to follow. [QUOTE] 1) Filter the data in any manner that produces "clusters" of non-contiguous data. 2) visually verify that the data elements are not sequential item 3) select a visible block of say 10 records 4) compare the number of records selected with the "statistical" data count presented at the bottom of the sheet. [/QUOTE] That is almost entirely useless. This bug report is now invalid as it's impossible to follow. Please create a new bug report that sticks to the point, avoids multiple multi-paragraph answers, and, most importantly, answers questions that are posed. Do not assume that triagers: (1) have the time to guess at what you're doing; and (2) know all about all the features that our millions of users use. Closing as INVALID. Please do not reopen this bug as it's not a useful bug report for our devs to actually do something with.