Created attachment 142433 [details] sample file with 32 characters in sheet name Steps to reproduce: 1. Open the attached file in MSO Excel -> Excel complains about unreadable content. If we edit the document in LibreOffice and we remove the last 'd' from the sheet name, it's open correctly in Excel. Limitation: https://support.office.com/en-us/article/Rename-a-worksheet-3F1F7148-EE83-404D-8EF0-9FF99FBAD1F9 If the file is saved to .XLS, Excel doesn't complain and only the first 31 characters are used. Excel limits the number of characters to 31 when editing the name Reproduced in Version: 6.1.0.0.beta1+ Build ID: 2a0d8106a558845357d39648656e08ec6f091cf8 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded
*** Bug 117606 has been marked as a duplicate of this bug. ***
@Regina, @Eike, Do you have any opinion here? Should we limit the sheet name to 31 to avoid incompatibility issues?
Artificially limiting doesn't make much sense, though we could limit to 31 characters when manually renaming a sheet. ODF doesn't limit the length, so any file opened as ODF and saved as Excel could suffer the same. Also importing CSV creates a sheet name from the file name, which may be longer. When saving to Excel maybe the name could be truncated, but care would have to be taken that no duplicate names would be created that way. Writing references all would have to use an extra mapping, also structures and functions using sheet names as literal strings like INDIRECT() addressing would then break. I'd avoid fiddling with sheet names when exporting. We should rather warn or even refuse to save the file in alien formats that are known to have this limit, so the user can rename the sheet as appropriate.
I approve any solution that warns or disallow renaming sheet names > MAX chars, e.g. by set the max sheet char field length to this same limit in "edit"/rename mode to avoid any such "user" problems. It would also be a good idea to issue a save file warning when saving file in MS office supported primary formats like .xlsx - as it is more or less impossible to know what is repaired or removed from file (here sheet names are truncated). Or even better to introduce some general compatibility function that includes several known problems/checks with other office products - as it seems to be hard for users to know what is repaired or broken - when compatibility issues are encountered. By using a general compatibility or sanity check it lets the users themselves control what do do - instead of seeing a warning on every save (which some users may do not approve).
Created attachment 142440 [details] Possible design of file checker design - from MS office I attach design of how files could be checked in the office family (word, excel, etc). Sorry about the native language. It is just an illustration how such a sanity report could be designed as an alternative to implementing warnings to say the save/save as functions suggested
Setting this bug to NEW according to Eike's suggestion in the last paragraph of comment 3. To avoid problems with renaming procedures, functions and references a warning would be the easiest solution when the user tries to save the file in formats that have a length limitation of sheet names. sverre48, we should keep this bug as short and focused as possible. Therefore any ideas for checking a file (structure) should be handled in another bug. It's highly possible that there is already an existing one.
Dear Xisco Faulí, 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 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This looks like a duplicate. *** This bug has been marked as a duplicate of bug 79998 ***