Description: The "rows/columns to repeat" does not conform to the specification as you can see in the attached file, generated with openpyxl. Steps to Reproduce: 1. generate an xlsx (for example with python and openpyxl) file using rows or columns to repeat when printing (print range in calc) Actual Results: open the file in calc, click on print preview, rows or columns do not get repeated Expected Results: open the file in calc, click on print preview, rows or columns get repeated Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Created attachment 139756 [details] example file with first row repeated for printing xlsx file generated with openpyxl, conforming to the specification
You can't confirm your own bugs. Moving it back to UNCONFIRMED until someone else confirms it.
(In reply to Christian from comment #0) > Expected Results: > open the file in calc, click on print preview, rows or columns get repeated I don't understand, it looks the same in MSO 2013. Please explain better, preferably with a screenshot from MSO showing how it should look like.
Created attachment 140448 [details] 2nd page print preview screen-shot You either have to print it or open the print preview and look at page 2. The first row is not repeated in OO, but it should be. 2nd page print preview screen-shot is attached.
Created attachment 140449 [details] 2nd page print preview screen-shot in LibreOffice Same 2nd page print preview in LO: the first row is not repeated, but should be.
Ah, right, so the row with the numbers does not appear on the second print preview page. Arch Linux 64-bit Version: 6.1.0.0.alpha0+ Build ID: 856c57f20f9b07c686a854e0ccbb6ee3b0ee4791 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on March 7th 2018 Arch Linux 64-bit LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
(In reply to Buovjaga from comment #6) > Ah, right, so the row with the numbers does not appear on the second print > preview page. > > Arch Linux 64-bit > Version: 6.1.0.0.alpha0+ > Build ID: 856c57f20f9b07c686a854e0ccbb6ee3b0ee4791 > CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; > Locale: fi-FI (fi_FI.UTF-8); Calc: group > Built on March 7th 2018 > > Arch Linux 64-bit > LibreOffice 3.3.0 > OOO330m19 (Build:6) > tag libreoffice-3.3.0.4 Correct. ps: I wrote OO but meant LO
Could you please confirm the bug since I'm not allowed to? thanks in advance :-)
(In reply to Christian from comment #8) > Could you please confirm the bug since I'm not allowed to? > > thanks in advance :-) The bug was confirmed in March as you can see from the history: https://bugs.documentfoundation.org/show_activity.cgi?id=115610
Created attachment 166076 [details] The example file in Excel 13 and LO7.1 nightly Still happens in: Version: 7.1.0.0.alpha0+ (x64) Build ID: dda71436b8594fb0669b3ac06c02a3997a0674be CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-US (hu_HU); UI: en-US Calc: CL The Edit Print Ranges dialog is empty and the Manage Names dialog gives this (false) information.
Created attachment 173537 [details] The example file resaved in Excel 2019 and opened in Calc Resaving it in Excel fixes the print range import in: Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 0fc020fb73c86a20608e8dff12af607e60327379 CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: CL while the original is still broken.
Dear Christian, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from https://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: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Imho, openpyxl writes Sheet!1:2 whereas Excel saves Sheet!$1:$2. Maybe generating it using the following line does the trick? ws.print_title_rows = '$1:$1' # the first row Should we add the missing absolute reference to the values delievered by openpyxl or close it with NOTOURBUG?