Created attachment 70165 [details] ODS file containing exemplification of this bug. In Calc, I created a single ODS file containing several spreadsheets (thus several sheet tabs: Sheet1, Sheet2, Sheet3...). Every sheet was filled with a data table with a dozen of columns and some tens of lines, each. Those tables have different widths. I then clicked Format => Page => Sheet => Scaling mode => Fit print range(s) to width/height, and configured it to 1/100: 1 page in width, 100 pages in height. So all the tables will be resized to fit 1 page, in terms of width. I also clicked Format => Page => Header/Footer => Edit => Custom header/footer => Text Attributes => Font, and then configured the font size to 16, for both headers and footers, thus I expect all headers and footers to have the same font sizes, despite of the different tables/sheets they belong to. However, because of the different sizes of the tables (different printing areas), each table was resized to fit the width of 1 page. It's ok, this is exactly what I need. The problem is: on the headers and footers, the font size is being changed aswell! So the most shrinked tables/sheets have headers and footers with smaller font sizes (sizes below 16), and the less shrinked tables/sheets have headers and footers with bigger font sizes. This is a problem, since I expected all headers and footers to have the _same_ font size: the tables must be resized to fit the preset width (fit to 1 page), but headers and footers must not. I consider this a bug, since I set the font size to 16 but it's being resized.
Created attachment 70166 [details] PDF version of the uploaded ODS file.
I agree, this menu 'Format -> Page -> Sheet -> Scale - Scaling mode = "Fit print range(s) to iwdth/height" should only "zoom" cells content, but not header and footer. This is nothing new, I also see this effect in more early versions, even back to OOo 1.1.5. I also think it's a bug, and it's an accepted very old AOOo issue. @Spreadsheet Team: Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf (and remove others in team from CC)
@yuri: mind if I mark this as 'enhancement' ?
(In reply to comment #3) > @yuri: mind if I mark this as 'enhancement' ? If doing it raises the possibility of this "issue" to be solved, then yes, please! =]
It would appear that changing it to "enhancement" did not make it any more likely to happen sooner. This bug is 8 years old, and I just discovered it, to my annoyance. I am going to change it back to "bug," and see who gets mad at me.
I am not sure if this is a bug (or a feature), but a solution would be good. For example, I have a file where the print size needs to be scaled down to about 35% and the headers and footers are currently scaled down accordingly. It would be helpful to fix the size of the header and footer at 100%.
To me it's pretty clear and obvious that it's a bug. I agreed that this bug report was marked as a desired feature instead of a bug report so developers could have more time to dedicate to fixing other (more critical) bugs and take the time to fix this. But 8 years is too long. I'm very impressed by such delay. Here's the most obvious reason why this is a bug: a spreadsheet contains information, but its headers and footers contain METAINFORMATION (i.e. information about the spreadsheet's information). E.g. the page numbers placed in the headers or footers pretty much inform us how many pages (i.e. how much space) the spreadsheet's information takes up. Another clear reason why resizing a spreadsheet shouldn't resize its headers and footers along is because international standardization organizations like ISO specify fixed font types and sizes for headers and footers in different document types (e.g. dissertations and other technical and academic documents). Therefore, by default LibreOffice should NOT resize headers and footers: the actual "desired feature" or "enhancement" is precisely providing the end-user the ability to change such default behavior, in order to cause LibreOffice to resize headers' and footers' font sizes along with their corresponding pages. But for some weird reason LibreOffice by default behaves in such non-standard, undesired way.
(In reply to Yuri from comment #7) > To me it's pretty clear and obvious that it's a bug. I agreed that this bug > report was marked as a desired feature instead of a bug report so developers > could have more time to dedicate to fixing other (more critical) bugs and > take the time to fix this. But 8 years is too long. I'm very impressed by > such delay. > > Here's the most obvious reason why this is a bug: a spreadsheet contains > information, but its headers and footers contain METAINFORMATION (i.e. > information about the spreadsheet's information). E.g. the page numbers > placed in the headers or footers pretty much inform us how many pages (i.e. > how much space) the spreadsheet's information takes up. > > Another clear reason why resizing a spreadsheet shouldn't resize its headers > and footers along is because international standardization organizations > like ISO specify fixed font types and sizes for headers and footers in > different document types (e.g. dissertations and other technical and > academic documents). > > Therefore, by default LibreOffice should NOT resize headers and footers: the > actual "desired feature" or "enhancement" is precisely providing the > end-user the ability to change such default behavior, in order to cause > LibreOffice to resize headers' and footers' font sizes along with their > corresponding pages. But for some weird reason LibreOffice by default > behaves in such non-standard, undesired way. I agree. This should be fixed, if possible.
Dear Yuri, 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
(In reply to QA Administrators from comment #9) > Dear Yuri, > > 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 I am currently using LibreOffice version 7.5.7.1 for Linux (64-bit XUbuntu 22.04, kernel version 6.2.0-35-generic) and the bug is still present exactly as it was reported, back in 2012.
This is definitely not a bug, since e.g. in MS Excel, there is an *option* named "Scale with document" (*enabled by default*); so definitely there is a use case for the current implementation as well. However, the lack of a similar option in Calc is an *interoperability* bug, and a missing feature.
Stating that an interoperability -bug- is "not a bug" looks contradictory: how a type of bug is not a bug? This is a self-debunking statement. Well, I made my case on comment #7 and I stand by it: metainformation shouldn't be resized when the user resizes its corresponding information because these are two separate entities, and the authoritative norms about it agree with me, which means that the default LibreOffice behaviour should be to -not- resize metainformation (i.e. headers and footers) along with its corresponding information (i.e. the "body" data of the e.g. spreadsheet). If I were a developer, I would've definitely contributed to fixing this bug. Since I'm not a developer, I can only contribute with reporting the bug and financially supporting the project through financial donations. However, even though I did use to donate to the Document Foundation, and despite the fact that I still appreciate and thank the efforts of the true developers who still do actual work on this project, since this bug came out and spent more than a decade without any fixing, I've been gradually moving to other solutions and currently don't make financial donations to this project anymore. If something as (apparently) minor as this can't be fixed in 10+ years, then there's no reason why I should take LibreOffice, it's development and financial donations to its project as seriously as this bug has so far been taken by those who have the power to fix it.
(In reply to Yuri from comment #12) > Stating that an interoperability -bug- is "not a bug" looks contradictory: > how a type of bug is not a bug? This is a self-debunking statement. > > Well, I made my case on comment #7 and I stand by it: metainformation > shouldn't be resized when the user resizes its corresponding information > because these are two separate entities, and the authoritative norms about > it agree with me, which means that the default LibreOffice behaviour should > be to -not- resize metainformation (i.e. headers and footers) along with its > corresponding information (i.e. the "body" data of the e.g. spreadsheet). > > If I were a developer, I would've definitely contributed to fixing this bug. > Since I'm not a developer, I can only contribute with reporting the bug and > financially supporting the project through financial donations. However, > even though I did use to donate to the Document Foundation, and despite the > fact that I still appreciate and thank the efforts of the true developers > who still do actual work on this project, since this bug came out and spent > more than a decade without any fixing, I've been gradually moving to other > solutions and currently don't make financial donations to this project > anymore. > > If something as (apparently) minor as this can't be fixed in 10+ years, then > there's no reason why I should take LibreOffice, it's development and > financial donations to its project as seriously as this bug has so far been > taken by those who have the power to fix it. While this is not exactly the place for discussing this, I agree with the sentiment above. After enormous amounts of time fighting bugs in LibreOffice for years, I finally realized that I had better things to do. While it's nice to be able to report bugs, it's infuriating that bug reviewers invariably ignore the bug or claim it isn't a bug, and even if they do, the bug is never fixed. I even have looked at the code in case I might be able to fix something myself, but there is no documentation I could find that would help me understand the architecture of the code.