[Libreoffice-bugs] [Bug 150966] FILESAVE Editing this MSO file in LO Writer causes the header and footer contents to be corrupted
https://bugs.documentfoundation.org/show_bug.cgi?id=150966 --- Comment #2 from tom1willi...@yandex.com --- Created attachment 182458 --> https://bugs.documentfoundation.org/attachment.cgi?id=182458=edit before and after .DOCX files showing the problem -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150966] FILESAVE Editing this MSO file in LO Writer causes the header and footer contents to be corrupted
https://bugs.documentfoundation.org/show_bug.cgi?id=150966 --- Comment #1 from tom1willi...@yandex.com --- Created attachment 182457 --> https://bugs.documentfoundation.org/attachment.cgi?id=182457=edit before and after .DOCX files demonstrating the problem -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150966] New: FILESAVE Editing this MSO file in LO Writer causes the header and footer contents to be corrupted
https://bugs.documentfoundation.org/show_bug.cgi?id=150966 Bug ID: 150966 Summary: FILESAVE Editing this MSO file in LO Writer causes the header and footer contents to be corrupted Product: LibreOffice Version: 7.3.5.2 release Hardware: x86-64 (AMD64) OS: Linux (All) Status: UNCONFIRMED Severity: normal Priority: medium Component: Writer Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: tom1willi...@yandex.com Description: Editing this MSO file in LO Writer causes the header and footer contents to be corrupted having zero height. Before and after example files are attached. Steps to Reproduce: 1.I open the file labeled BEFORE 2.I deleted one character of text in the main body, not the header or footer, then type that same character again. 3.I save the file as a docx file 4.After reopening the text in the header and footer has zero height and appears to be "gone" to my MSO using colleagues who then get upset. Actual Results: After reopening the text in the header and footer has zero height and appears to be "gone" to my MSO using colleagues who then get upset. Expected Results: After reopening the text in the header and footer should look as they do in the file labeled BEFORE opening in LO Writer. Reproducible: Always User Profile Reset: No Additional Info: This problem has only started happening in the last couple of weeks. So something has changed recently. The colleagues use MSO365 and can be assumed to be up to date. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 148511] Dragging top handle of the table border to increase the size of table refuses
https://bugs.documentfoundation.org/show_bug.cgi?id=148511 QA Administrators changed: What|Removed |Added Whiteboard| QA:needsComment| -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150734] Filter to exclude empty cells on Pivot Table still shows empty cells when deselected
https://bugs.documentfoundation.org/show_bug.cgi?id=150734 QA Administrators changed: What|Removed |Added Whiteboard|| QA:needsComment -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147882] Asking for the "original size" of a PDF inserted image delivers weird results
https://bugs.documentfoundation.org/show_bug.cgi?id=147882 QA Administrators changed: What|Removed |Added Status|NEEDINFO|UNCONFIRMED Ever confirmed|1 |0 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147882] Asking for the "original size" of a PDF inserted image delivers weird results
https://bugs.documentfoundation.org/show_bug.cgi?id=147882 --- Comment #4 from QA Administrators --- [Automated Action] NeedInfo-To-Unconfirmed -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147120] Repairs document to old version and no clue about new document.
https://bugs.documentfoundation.org/show_bug.cgi?id=147120 QA Administrators changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |INSUFFICIENTDATA -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147120] Repairs document to old version and no clue about new document.
https://bugs.documentfoundation.org/show_bug.cgi?id=147120 --- Comment #3 from QA Administrators --- Dear rackaitis, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 135932] Open File option in front screen does nothing
https://bugs.documentfoundation.org/show_bug.cgi?id=135932 QA Administrators changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |INSUFFICIENTDATA -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 135932] Open File option in front screen does nothing
https://bugs.documentfoundation.org/show_bug.cgi?id=135932 --- Comment #6 from QA Administrators --- Dear Dan Essin, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 148064] Crash in: libgobject-2.0.so.0.5000.3
https://bugs.documentfoundation.org/show_bug.cgi?id=148064 --- Comment #3 from QA Administrators --- Dear iusa...@gmail.com, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 49641] Fileopen DOC: Tables lost in a frame (per Comment 6)
https://bugs.documentfoundation.org/show_bug.cgi?id=49641 --- Comment #9 from QA Administrators --- Dear Andries van Tonder, 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 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 119803] FILEOPEN Table in frame in DOC not displayed in Writer
https://bugs.documentfoundation.org/show_bug.cgi?id=119803 --- Comment #5 from QA Administrators --- Dear Aron Budea, 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 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 113404] ODF: wrong element after reducing symbol size in chart
https://bugs.documentfoundation.org/show_bug.cgi?id=113404 --- Comment #5 from QA Administrators --- Dear Regina Henschel, 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 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 112246] Global changes of text attributes not work correctly
https://bugs.documentfoundation.org/show_bug.cgi?id=112246 --- Comment #10 from QA Administrators --- Dear Zbynek Burget, 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 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150910] [EDITING] Protected status only is pasted if the source cells belong to one row.
https://bugs.documentfoundation.org/show_bug.cgi?id=150910 --- Comment #10 from n gibson --- (In reply to Timur from comment #8) > n gibson, thanks for commenting. > Please do not change the status set by a member of QA team, and that was > wrong change, see > https://bugs.documentfoundation.org/page.cgi?id=fields.html#bug_status. > > *** This bug has been marked as a duplicate of bug 123974 *** Apologies for wrong protocol. I'm quite unfamiliar with the process. > Note that you didn't write exact expected results, with regard to already > defined bug 123974. > Please do. Not sure where to add expected results, other than right here, so in case this helps: IN regards to bug 123974, the expected behavior is the same as the current behavior of Calc as described -- in other words, the behavior is not a bug. It requires no correction. IN regards to *this* bug 150910, the expected behavior is that when any cell or cell range is copied, then its protected status is fully retained when it is pasted into another valid cell or cell range regardless of the protection status of the sheet as a whole. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 45884] LibreOffice does not understand "scale" value with style:rel-width and style:rel-height
https://bugs.documentfoundation.org/show_bug.cgi?id=45884 --- Comment #19 from João Vidal --- It's still present on LO 7.2.7 (my Linux distribution uses pacman, I can't install latest 7.4 with rpm or deb). Using style:rel-width="scale" svg:height="1.499cm" the images have a very small width. See attachment 'test_with_scale.odt'. Using something like svg:width="1.438cm" svg:height="1.499cm" the images have the expected size.. See attachment 'test_with_dimensions.odt'. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 45884] LibreOffice does not understand "scale" value with style:rel-width and style:rel-height
https://bugs.documentfoundation.org/show_bug.cgi?id=45884 --- Comment #18 from João Vidal --- Created attachment 182456 --> https://bugs.documentfoundation.org/attachment.cgi?id=182456=edit odt with dimensions, showing no problems on image sizes -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 45884] LibreOffice does not understand "scale" value with style:rel-width and style:rel-height
https://bugs.documentfoundation.org/show_bug.cgi?id=45884 --- Comment #17 from João Vidal --- Created attachment 182455 --> https://bugs.documentfoundation.org/attachment.cgi?id=182455=edit odt with scale, showing the effects of the bug -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 143557] docx 16-color char highlight lost in round trip through odt format
https://bugs.documentfoundation.org/show_bug.cgi?id=143557 --- Comment #11 from Luke Deller --- (In reply to Justin L from comment #7) > ODF doesn't (and hopefully never will) have a concept of a 16-color > highlight character property. So not much can be done here unless someone > does that evil thing. Which element did you feel was evil: supporting the concept of character highlighting as distinct from background shading, or the fact that Word only offers 16 choices for the highlight colour? I agree the limitation of colour choice is quite evil, probably a relic of the past. The same limitation used to exist elsewhere, eg table border colour was limited to 16 colours until MS Word 2000. However the concept of highlighting might have merit: I have seen it employed by Word users differently than background shading, with semantics matching a physical highlighter pen. Indeed the online Word documentation says: > Word contains many highlighters to make your text pop off the screen just > as if you were highlighting paper with a fluorescent marker ( from https://support.microsoft.com/en-us/office/apply-or-remove-highlighting-1747d808-6db7-4d49-86ac-1f0c3cc87e2e ) What do you think of adding a loext: (extension) attribute to persist the highlighting information that LibreOffice currently holds in memory in this case? I could maybe look at a patch for that if the concept sounds reasonable. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150965] CALC sort by one column changes cell numbers in formulae not involved in the sort range
https://bugs.documentfoundation.org/show_bug.cgi?id=150965 --- Comment #1 from van.sny...@sbcglobal.net --- Created attachment 182454 --> https://bugs.documentfoundation.org/attachment.cgi?id=182454=edit Test case. Sort rows 4-23 on column G to demonstrate the problem described in the report. Examine the formulae in rows 4-23 of columns D and F before and after sorting. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150965] New: CALC sort by one column changes cell numbers in formulae not involved in the sort range
https://bugs.documentfoundation.org/show_bug.cgi?id=150965 Bug ID: 150965 Summary: CALC sort by one column changes cell numbers in formulae not involved in the sort range Product: LibreOffice Version: 7.0.4.2 release Hardware: All OS: Linux (All) Status: UNCONFIRMED Severity: normal Priority: medium Component: Calc Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: van.sny...@sbcglobal.net Description: References to cells that are not included within the range of rows being sorted are changed but should not be. The results of the calculations become incorrect. Steps to Reproduce: 1.In the first column of a spreadsheet, enter identifiers, such as chemical compound names. For example, use ten rows. 2.In the second column, enter a property of the name in the first column, such as amount 3.After all the rows are entered, compute the sum of the second column in a new row, for example row 11. 4.In the third column, compute the percentage that the second column accounts for, for example, compute C1 as =$B1/$B11*100, C2 as $B2/B11*100, etc. 5.Enter a fourth column, such as a melting point. 6. Sort a subset of the rows, definitely not including the total row (B11 in the example), on the fourth column in either ascending or descending order. Actual Results: The references to cells in the denominators of the formulae in the third column are changed, even though the rows specified by those references are outside the range to be sorted. Expected Results: References to cells within the range of rows being sorted should be changed according to the sorting result. References to cells not within the range of rows being sorted should not be changed. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.4.2 Environment: CPU threads 4; OS: Linux 5.1.10 User Interface: UI render; default; VCL; kf5 Locale: en-US (en_US.UTF-8); UI: en-US Misc: Debian package version: 1:7.004-4+deb11u1 Calc: threaded -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150804] The strings "Top of baseline" and "Bottom of baseline" should be changed
https://bugs.documentfoundation.org/show_bug.cgi?id=150804 Regina Henschel changed: What|Removed |Added CC||rb.hensc...@t-online.de --- Comment #5 from Regina Henschel --- When trying to find better wording please keep in mind, that the file format has no wording "From bottom". The setting "From bottom by -10mm to Base line" is written in file markup as style:vertical-pos="from-top" together with svg:y="10mm". It moves the object so, that the top edge of the object is 10mm below the baseline. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150964] New: FILEOPEN: HTM file with extension XLS partially imported using default filter by Calc
https://bugs.documentfoundation.org/show_bug.cgi?id=150964 Bug ID: 150964 Summary: FILEOPEN: HTM file with extension XLS partially imported using default filter by Calc Product: LibreOffice Version: 7.4.0.0 beta1+ Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: medium Component: Calc Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: saywel...@gmail.com Created attachment 182453 --> https://bugs.documentfoundation.org/attachment.cgi?id=182453=edit HTML Excel Workbook An HTML file (labelled internally as ExcelWorksheet) with an xls extension opened in Calc does not import all the table data unless the filter "HTML Document (Calc) (.html, .xhtml, .htm)" is explicitly chosen. Double-clicking the file opens in Calc with only one cell visible. If the extension is renamed .odt it opens in Writer with all data visible. The same file opens correctly in Excel 2010 although with warning about incorrect extensions; apparently later versions of Excel open it without complaint. This problem arises in Ask.LibreOffice https://ask.libreoffice.org/t/xls-file-does-not-open-in-libre-calc-but-opens-in-google-sheets/81770 An average user is unlikely to investigate every filter option, especially not to the 70th filter in the list. The original questioner in Ask.LibreOffice appears to have not found the filter although it is explicitly mentioned in one comment and in one answer. Can the filter selection be made easier? Or made automatic as the name Excel Worksheet is included inside the file? -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 32950] FORMATTING Cell height and word wrapping can be wrong (when changing) xls-files because 'Optimal height" of rows is not set (automatically?)
https://bugs.documentfoundation.org/show_bug.cgi?id=32950 --- Comment #27 from Justin L --- repro 7.5+ Based on comment 5, I'd guess this is the XLS version bug 62268 and needs something like the controversial patch 693953dd4699887bd3f5bca2c3582b5fae1d6992 that explicitly called Calc to re-calculate rows after ODS load. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 123026] LibreOffice ignore xlsxwriter 'text_wrap' formatting option, seems optimal height for row is not being set to hold cells with wrapped text
https://bugs.documentfoundation.org/show_bug.cgi?id=123026 --- Comment #5 from Justin L --- repro 7.5+ See bug 62268 and the controversial patch 693953dd4699887bd3f5bca2c3582b5fae1d6992 that explicitly called Calc to re-calculate rows after ODS load. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 145951] Image anchored as 'as character' moves to different spot on DOCX/DOC/RTF export
https://bugs.documentfoundation.org/show_bug.cgi?id=145951 Regina Henschel changed: What|Removed |Added CC||rb.hensc...@t-online.de --- Comment #5 from Regina Henschel --- (In reply to Justin L from comment #3) > > Please provide proof that MS formats can specify a similar anchor setting. > Assuming DOCX-Limitations. The UI of Word has no setting for the vertical position of the shape in case it is anchored 'inline'. But Word treats such image as character and you can use the character properties of subscript and superscript to set the image to the desired vertical position. So a solution could be to convert vertical position to character subscript/superscript on export and the other way round on import. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 45147] right-to-left words appear in the wrong order in the CSV import dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=45147 Eyal Rozenberg changed: What|Removed |Added CC||eyalr...@gmx.com Severity|major |normal --- Comment #15 from Eyal Rozenberg --- Bug still manifests with: Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 6c81a09e3ef239a2d7a991d00fe3620a67298b99 CPU threads: 4; OS: Linux 5.18; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US Calc: threaded -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150950] line numbering ON/OFF indication in Tools menu
https://bugs.documentfoundation.org/show_bug.cgi?id=150950 Hossein changed: What|Removed |Added Keywords||needsUXEval --- Comment #1 from Hossein --- Heiko, what do you think? The menu item that is discussed here is: "Tools > Line Numbering...". The difference between this item and the "Automatic Spell Checking" in the "Tools" menu is that this one opens a dialog box. I searched for the menu bar items that end with "...", which shows they are going to open a dialog box, and also check-able. I could not find any. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 144583] Blurry icon on HiDPI
https://bugs.documentfoundation.org/show_bug.cgi?id=144583 --- Comment #13 from Hossein --- (In reply to Caolán McNamara from comment #10) > https://gerrit.libreoffice.org/c/core/+/139944 + > https://gerrit.libreoffice.org/c/core/+/139945 > give me good results Thank you for the quick fix, Caolán! It worked fine for me on HiDPI and 2x integer scaling, after you have merged the above two patches: Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: d480af79c6d67341e650a5b920bf66c2865309e0 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Note: I haven't tested the fixes extensively with fractional scaling. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 50044] FILEOPEN partiular .xls shows too small row height
https://bugs.documentfoundation.org/show_bug.cgi?id=50044 --- Comment #5 from Justin L --- If I first round-trip the file with MS Word 2003, it opens fine in LO. It is calling XclImpColRowSettings::SetRowSettings twice - first for rows 1-627 and then again for rows 1-116. I don't know how to stop that because ImportExcel8::Read() is really generic. I'd guess you would have to understand xls internals pretty good to figure out where to identify and stop a duplicate. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 90796] [META] HiDPI / Retina bugs
https://bugs.documentfoundation.org/show_bug.cgi?id=90796 Hossein changed: What|Removed |Added Depends on||150960 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=150960 [Bug 150960] Use platform look and feel (plaf) and scaling for Java windows -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150960] Use platform look and feel (plaf) and scaling for Java windows
https://bugs.documentfoundation.org/show_bug.cgi?id=150960 Hossein changed: What|Removed |Added Blocks||90796 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=90796 [Bug 90796] [META] HiDPI / Retina bugs -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150403] Inconsistency in dynamically applying font substitutions
https://bugs.documentfoundation.org/show_bug.cgi?id=150403 Eyal Rozenberg changed: What|Removed |Added Summary|Font substitutions |Inconsistency in |dynamically-apply |dynamically applying font |inconsistently |substitutions -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 90796] [META] HiDPI / Retina bugs
https://bugs.documentfoundation.org/show_bug.cgi?id=90796 Hossein changed: What|Removed |Added Depends on||144583 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=144583 [Bug 144583] Blurry icon on HiDPI -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 144583] Blurry icon on HiDPI
https://bugs.documentfoundation.org/show_bug.cgi?id=144583 Hossein changed: What|Removed |Added Blocks||90796 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=90796 [Bug 90796] [META] HiDPI / Retina bugs -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 143547] LO Writer: navigator should stand still on promoting and demoting
https://bugs.documentfoundation.org/show_bug.cgi?id=143547 Jim Raykowski changed: What|Removed |Added Assignee|libreoffice-b...@lists.free |rayk...@gmail.com |desktop.org | -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150963] "Freeze Rows and Columns" should be accessible not just through the view menu
https://bugs.documentfoundation.org/show_bug.cgi?id=150963 m.a.riosv changed: What|Removed |Added CC||miguelangelrv@libreoffice.o ||rg Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 --- Comment #1 from m.a.riosv --- Have you tried customizing the right-click?, Menu/Tools/Customize - Context Menu -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150804] The strings "Top of baseline" and "Bottom of baseline" should be changed
https://bugs.documentfoundation.org/show_bug.cgi?id=150804 --- Comment #4 from Telesto --- (In reply to Tuomas Hietala from comment #2) > Well, 99% of users probably wouldn't notice if these options were removed > altogether. But since they exist, I thought the texts could be improved a > bit. Slightly off-topic I want to mention a compatibility issue. Apply: Bottom of baseline and export the file to DOCX and File-> Reload. Apparently the feature is unsupported by Word. Bug 145951 comment 3. Another argument to drop those settings, IMHO. However those are used on multiple dialogs, and actually used.. Insert in image. Anchor it to character, drag it somewhere else.. Bottom of baseline will be set. See again bug 145951 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150963] New: "Freeze Rows and Columns" should be accessible not just through the view menu
https://bugs.documentfoundation.org/show_bug.cgi?id=150963 Bug ID: 150963 Summary: "Freeze Rows and Columns" should be accessible not just through the view menu Product: LibreOffice Version: 7.5.0.0 alpha0+ Master Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: medium Component: Calc Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: eyalr...@gmx.com One can split the view in Calc by dragging the top of the scroll bar - without using the menus. I believe it should then be possible somehow - e.g. by a right-click context menu or some other way - to freeze the resulting split, without going through the view menu. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 133942] Crash ucrtbase!abort+0x4b: after Reject All tracked changes
https://bugs.documentfoundation.org/show_bug.cgi?id=133942 Telesto changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||7507 --- Comment #8 from Telesto --- (In reply to Julien Nabet from comment #6) > Created attachment 182450 [details] > bt with debug symbols BT is the same as for bug 147507. This bug apparently didn't crash at step 6 in the past; so might be different, might be the same thing.. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147507] Crash swlo!SwRedlineExtraData_FormatColl::Reject+0x1b6 (comment 7)
https://bugs.documentfoundation.org/show_bug.cgi?id=147507 Telesto changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=13 ||3942 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150909] Regression: HTML entities badly rendered
https://bugs.documentfoundation.org/show_bug.cgi?id=150909 --- Comment #1 from Commit Notification --- Olivier Hallot committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/dfa442b3d862539a7b10af5281a080acaef7e73d tdf#150909 workaround for bad renderring of help page -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150909] Regression: HTML entities badly rendered
https://bugs.documentfoundation.org/show_bug.cgi?id=150909 Commit Notification changed: What|Removed |Added Whiteboard||target:7.5.0 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 144583] Blurry icon on HiDPI
https://bugs.documentfoundation.org/show_bug.cgi?id=144583 --- Comment #12 from Commit Notification --- Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ce4e3d6f39cb4db138ff2445b27d7af7ad01ff33 Resolves: tdf#144583 reuse lok hidpi icon scheme for gtk It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 50044] FILEOPEN partiular .xls shows too small row height
https://bugs.documentfoundation.org/show_bug.cgi?id=50044 --- Comment #4 from Justin L --- (In reply to Justin L from comment #2) > A1: not sure why this row was so small. Bad testing. It actually seems fine in master. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150804] The strings "Top of baseline" and "Bottom of baseline" should be changed
https://bugs.documentfoundation.org/show_bug.cgi?id=150804 --- Comment #3 from Eyal Rozenberg --- With that drop-down we actually select two different parameters: What entity to align with, and how the entities are aligned. So, it may make sense to split this into two selections. This should make it easier to have options in the drop down lists which are both exact and easy to understand. As I've said in the design meeting today - the way things stand now, I would want the list items to be clearer and easier to understand at the expense of brevity. So, w.r.t. the baseline, I would hope to see: "Align top with baseline", "Align center with baseline", "Align bottom with baseline". With other entities, it might be something like "Align bottoms with line", "Align centers with line" etc. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 133942] Crash ucrtbase!abort+0x4b: after Reject All tracked changes
https://bugs.documentfoundation.org/show_bug.cgi?id=133942 Julien Nabet changed: What|Removed |Added CC||nem...@numbertext.org --- Comment #7 from Julien Nabet --- László: thought you might be interested in this one since it's related to tracked changes -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 133942] Crash ucrtbase!abort+0x4b: after Reject All tracked changes
https://bugs.documentfoundation.org/show_bug.cgi?id=133942 Julien Nabet changed: What|Removed |Added Keywords||haveBacktrace -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 133942] Crash ucrtbase!abort+0x4b: after Reject All tracked changes
https://bugs.documentfoundation.org/show_bug.cgi?id=133942 Julien Nabet changed: What|Removed |Added CC||serval2...@yahoo.fr --- Comment #6 from Julien Nabet --- Created attachment 182450 --> https://bugs.documentfoundation.org/attachment.cgi?id=182450=edit bt with debug symbols On pc Debian x86-64 with master sources updated today (3592c2e1af98b3fad00c43a4e886c29f3a4bb934) + gen rendering, I got a crash at the step "Reject all". I attached bt with some info from gdb. Also, there are still a lot of: warn:legacy.osl:274315:274315:sw/source/core/doc/DocumentRedlineManager.cxx:94: redline table corrupted: empty redline So either it's a real pb and it should be fixed or it's a false positive and we should remove this log. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 115449] Add Tooltips to the Horizontal Ruler in Writer
https://bugs.documentfoundation.org/show_bug.cgi?id=115449 --- Comment #10 from Stephen Leibowitz --- Collabora has partially departed from the LO monochrome ruler by coloring the indents blue. Adopting this for LO would not require changing the location, size, or shape of ruler elements. This limited use of color on the LO ruler need not delay an implementation of ruler tooltips. And it would not close the door to a more extensive use of color on the ruler in the future. I think that the specific color is not very important if coloring is limited to the indents. But giving users a choice of color would be desirable if coloring is extended to other ruler elements. In the latter case, an option might be added for the ruler here: Tools > Options > LibreOffice > Application Colors It has been 4½ years since I reported this issue, which initially was limited to ruler tooltips. Is there anything that can be done to advance it? -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 125205] Spreadsheet cell Horizontal alignment (Left) indent is not saved/preserved round trip to OOXML
https://bugs.documentfoundation.org/show_bug.cgi?id=125205 --- Comment #7 from stde...@gmail.com --- I know you'll hate my response - but add a converting function maybe? Libre opens X file, converts it (if needed) to a "standard" format in-memory, and, if needed, writing it in Excel units on save? -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 108392] [META] Master slide bugs and enhancements
https://bugs.documentfoundation.org/show_bug.cgi?id=108392 Bug 108392 depends on bug 135060, which changed state. Bug 135060 Summary: Clicking a template in Master Slide Sidebar changes color https://bugs.documentfoundation.org/show_bug.cgi?id=135060 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 144583] Blurry icon on HiDPI
https://bugs.documentfoundation.org/show_bug.cgi?id=144583 --- Comment #11 from Commit Notification --- Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cc2a6787446f1ae6492a41c405f45a9cc8cc7d4e Related: tdf#144583 move current lok hidpi icon thing into SalGraphics It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 144583] Blurry icon on HiDPI
https://bugs.documentfoundation.org/show_bug.cgi?id=144583 Commit Notification changed: What|Removed |Added Whiteboard||target:7.5.0 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150961] Pivot table sorting option is gone after resaving in LO in xlsx format
https://bugs.documentfoundation.org/show_bug.cgi?id=150961 --- Comment #2 from Thomas Jiang --- Created attachment 182449 --> https://bugs.documentfoundation.org/attachment.cgi?id=182449=edit The xlsx file resaved using LO In this file, even though in the pivot table is still there, but sorting option is gone. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150961] Pivot table sorting option is gone after resaving in LO in xlsx format
https://bugs.documentfoundation.org/show_bug.cgi?id=150961 --- Comment #1 from Thomas Jiang --- Created attachment 182448 --> https://bugs.documentfoundation.org/attachment.cgi?id=182448=edit The xlsx file with pivot table option created by Office Excel -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 95247] Borders accesibility
https://bugs.documentfoundation.org/show_bug.cgi?id=95247 --- Comment #6 from MichelleHernandez --- Glad to find the help about the coding on your blog is quite useful and wise. I’m sure numerous people are getting great help on https://www.flokii.com/questions/view/113/what-are-the-effects-of-kala-sarpa-yoga your blog that would work to everyone. I admire your helping material please continue sharing the trusted updates. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 144583] Blurry icon on HiDPI
https://bugs.documentfoundation.org/show_bug.cgi?id=144583 Adolfo Jayme Barrientos changed: What|Removed |Added Component|LibreOffice |UI -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150962] LibreOffice CALC hangs or crashes on different standard situations without any message ( sorting, saving, fill out fields )
https://bugs.documentfoundation.org/show_bug.cgi?id=150962 --- Comment #1 from Rainer Primosch --- It crashed 80-90%, so unfortunately i had to work on the documents with an other application. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 80467] UI: "Element anchor" appears RTL aligned, with bad bidi braces in Hebrew UI version and possibly other RTL languages.
https://bugs.documentfoundation.org/show_bug.cgi?id=80467 Eyal Rozenberg changed: What|Removed |Added Blocks||43808 CC||eyalr...@gmx.com --- Comment #8 from Eyal Rozenberg --- Seeing this with build: Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 6c81a09e3ef239a2d7a991d00fe3620a67298b99 CPU threads: 4; OS: Linux 5.18; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: he-IL but - inconsistently. First, the examples seem laid out properly for me, despite the rest of the elements having their direction RTL'ed. Also, after seeing the what Avishay described, when I resize the window, and re-dock the undocked formula elements region - the rendering seems to be corrected, i.e. an LTRed equation; and the font size which seemed smaller than it should be (not something Avishay described) grows to match the text next to the formula I've created. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=43808 [Bug 43808] [META] Right-To-Left and Complex Text Layout language issues (RTL/CTL) -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 43808] [META] Right-To-Left and Complex Text Layout language issues (RTL/CTL)
https://bugs.documentfoundation.org/show_bug.cgi?id=43808 Eyal Rozenberg changed: What|Removed |Added Depends on||80467 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=80467 [Bug 80467] UI: "Element anchor" appears RTL aligned, with bad bidi braces in Hebrew UI version and possibly other RTL languages. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150962] New: LibreOffice CALC hangs or crashes on different standard situations without any message ( sorting, saving, fill out fields )
https://bugs.documentfoundation.org/show_bug.cgi?id=150962 Bug ID: 150962 Summary: LibreOffice CALC hangs or crashes on different standard situations without any message ( sorting, saving, fill out fields ) Product: LibreOffice Version: 7.4.0.3 release Hardware: All OS: macOS (All) Status: UNCONFIRMED Severity: normal Priority: medium Component: Calc Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: rainer.primo...@aon.at Description: I work with LibreOffice Calc with a sheet. If i make changes, add a new row odr change a field and i klick save the document, LibreOffice crashes and try to save changes. Also if i try to sort the data in alphabetical order, LibreOffice also crash often. The sav data tialog, newer is finished. Si i have to stop LibreOffice immediate. With the same document i can work on Windows10 without any problem! The document is a sheet with names, mail adresses and some additional fields. Only 40 rows of data The problem occures on 80% of tryes! Had to install OpenOffice again that i can handle that document. Steps to Reproduce: 1. open a CALC document 2. add some new data in an empty row 3. save the document or 1. open a CALC document 2. sort the list in alphabetical order Actual Results: LibreOffice crashes and is closing. LibreOffice try to save the changes, but never will finished. So had to close the application immidiate. Expected Results: Save the file without crashing! Sorting the file without a crash! Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.4.0.3 / LibreOffice Community Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a CPU threads: 20; OS: Mac OS X 12.5.1; UI render: default; VCL: osx Locale: de-AT (de_AT.UTF-8); UI: de-DE Calc: threaded -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150961] New: Pivot table sorting option is gone after resaving in LO in xlsx format
https://bugs.documentfoundation.org/show_bug.cgi?id=150961 Bug ID: 150961 Summary: Pivot table sorting option is gone after resaving in LO in xlsx format Product: LibreOffice Version: 7.4.0.3 release Hardware: All OS: Linux (All) Status: UNCONFIRMED Severity: normal Priority: medium Component: Calc Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: thomasji...@geotab.com Description: The pivot table sorting option that was setup in Office Excel is gone after the file is resaved by LO. Steps to Reproduce: 1. Create a spreadsheet in Office Excel, and create a pivot table. 2. In the pivot table, set one of the row to be sort by desc, and only show top 5 items. Save the Excel file in Office Excel in the format of xlsx. 3. Open the file in LO calc, save it in xlsx format, and close LO calc. 4. Reopen the file using LO calc, one will find that the sorting option/show top option is gone. Actual Results: The pivot table sorting option that was setup in Office Excel is gone after the file is resaved by LO, following the above steps. Expected Results: We expect that LO calc can save the sorting option in pivot table even when it saves the file in xlsx file format. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 7.4.0.3 / LibreOffice Community Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a CPU threads: 32; OS: Linux 5.14; UI render: default; VCL: gtk3 Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 140202] [META] Issues with files in MS Office formats created by external producers (not MS Office)
https://bugs.documentfoundation.org/show_bug.cgi?id=140202 Justin L changed: What|Removed |Added Depends on||34717 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=34717 [Bug 34717] FILEOPEN FORMATTING: automatic row height is too small in particular .xls -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 140202] [META] Issues with files in MS Office formats created by external producers (not MS Office)
https://bugs.documentfoundation.org/show_bug.cgi?id=140202 Bug 140202 depends on bug 34717, which changed state. Bug 34717 Summary: FILEOPEN FORMATTING: automatic row height is too small in particular .xls https://bugs.documentfoundation.org/show_bug.cgi?id=34717 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 34717] FILEOPEN FORMATTING: automatic row height is too small in particular .xls
https://bugs.documentfoundation.org/show_bug.cgi?id=34717 Justin L changed: What|Removed |Added CC||jl...@mail.com Blocks||140202 Resolution|--- |NOTOURBUG Status|NEW |RESOLVED --- Comment #33 from Justin L --- This document only sets default height (160) when the normal height (for 10pt font) is 255. So that explains the small row height. None of the rows are flagged as having content. They are all NOT ExcColRowFlags::Used, and therefore the row just gets mnDefHeight. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=140202 [Bug 140202] [META] Issues with files in MS Office formats created by external producers (not MS Office) -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 108252] [META] Cell-related bugs and enhancements
https://bugs.documentfoundation.org/show_bug.cgi?id=108252 Bug 108252 depends on bug 34717, which changed state. Bug 34717 Summary: FILEOPEN FORMATTING: automatic row height is too small in particular .xls https://bugs.documentfoundation.org/show_bug.cgi?id=34717 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 50044] FILEOPEN partiular .xls shows too small row height
https://bugs.documentfoundation.org/show_bug.cgi?id=50044 Justin L changed: What|Removed |Added Hardware|Other |All --- Comment #3 from Justin L --- (In reply to Justin L from comment #2) > A1: not sure why this row was so small. Fixed when I change the font. Sounds like bug 39486 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 109072] [META] XLS (binary) format bug tracker
https://bugs.documentfoundation.org/show_bug.cgi?id=109072 Justin L changed: What|Removed |Added Depends on||39486 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=39486 [Bug 39486] FILEOPEN particular .xls with wrong FORMATTING, row height too small -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 109072] [META] XLS (binary) format bug tracker
https://bugs.documentfoundation.org/show_bug.cgi?id=109072 Bug 109072 depends on bug 39486, which changed state. Bug 39486 Summary: FILEOPEN particular .xls with wrong FORMATTING, row height too small https://bugs.documentfoundation.org/show_bug.cgi?id=39486 What|Removed |Added Status|RESOLVED|NEW Resolution|DUPLICATE |--- -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 39486] FILEOPEN particular .xls with wrong FORMATTING, row height too small
https://bugs.documentfoundation.org/show_bug.cgi?id=39486 Justin L changed: What|Removed |Added Blocks||109072 Keywords||filter:xls CC||jl...@mail.com Status|RESOLVED|NEW Resolution|DUPLICATE |--- --- Comment #7 from Justin L --- I didn't notice anything strange with the import. It sets row height 255 (pretty standard for 10pt font) and all the rows are optimal height. Seems to be a failure to recalculate optimal size, since this 16pt content is too large for the initial suggested height. Any change automatically corrects the row. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=109072 [Bug 109072] [META] XLS (binary) format bug tracker -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150177] macOS Wildly blinking cursor and non-visible selection issues
https://bugs.documentfoundation.org/show_bug.cgi?id=150177
Telesto changed:
What|Removed |Added
CC||xiscofa...@libreoffice.org
--- Comment #14 from Telesto ---
@Xisco
(In reply to will.brokenbourgh2877 from comment #13)
> Okay LO devs, it appears the issue is here:
>
> vcl/osx/salframe.cxx on line 103 in function
> AquaSalFrame::AquaSalFrame( SalFrame* pParent, SalFrameStyleFlags
> salFrameStyle )
>
> The code seems to just be blindly accepting whatever is in the defaults
> instead of validating it. I recommend adding sanity checks before assigning
> something as important as the blink time.
>
> (Sorry, don't know how to add code tags to these reports)
>
> - - - - -
> mpParent = dynamic_cast(pParent);
>
> initWindowAndView();
>
> SalData* pSalData = GetSalData();
> pSalData->mpInstance->insertFrame( this );
> NSUserDefaults *userDefaults = [NSUserDefaults standardUserDefaults];
> if (userDefaults != nil)
> {
> id setting = [userDefaults objectForKey:
> @"NSTextInsertionPointBlinkPeriodOn"];
> if (setting)
> mnBlinkCursorDelay = [setting intValue];
> else
> {
> setting = [userDefaults objectForKey:
> @"NSTextInsertionPointBlinkPeriodOff"];
> if (setting)
> mnBlinkCursorDelay = [setting intValue];
> }
> }
> - - - - -
--
You are receiving this mail because:
You are the assignee for the bug.
[Libreoffice-bugs] [Bug 109072] [META] XLS (binary) format bug tracker
https://bugs.documentfoundation.org/show_bug.cgi?id=109072 Justin L changed: What|Removed |Added Depends on||50044 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=50044 [Bug 50044] FILEOPEN partiular .xls shows too small row height -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 109072] [META] XLS (binary) format bug tracker
https://bugs.documentfoundation.org/show_bug.cgi?id=109072 Bug 109072 depends on bug 50044, which changed state. Bug 50044 Summary: FILEOPEN partiular .xls shows too small row height https://bugs.documentfoundation.org/show_bug.cgi?id=50044 What|Removed |Added Status|RESOLVED|NEW Resolution|DUPLICATE |--- -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 50044] FILEOPEN partiular .xls shows too small row height
https://bugs.documentfoundation.org/show_bug.cgi?id=50044 Justin L changed: What|Removed |Added Ever confirmed|0 |1 Status|RESOLVED|NEW Resolution|DUPLICATE |--- CC||jl...@mail.com Keywords||filter:xls OS|Windows (All) |All Blocks||109072 --- Comment #2 from Justin L --- The focus of this bug report is the first 4 rows I think. It looks like the rows are defined twice. The first time the values look sane, but the second time around they are tiny. A1: not sure why this row was so small. Fixed when I change the font. A2-A4: redefined from 255 to 32. These are set to manual height, so they honor that last tiny size. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=109072 [Bug 109072] [META] XLS (binary) format bug tracker -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150953] Row and column headers do not zoom in and out
https://bugs.documentfoundation.org/show_bug.cgi?id=150953 Rainer Bielefeld Retired changed: What|Removed |Added CC||LibreOffice@bielefeldundbus ||s.de Version|7.4.0.3 release |Inherited From OOo --- Comment #4 from Rainer Bielefeld Retired --- The current behavior is also visible in OOo. Softmaker Planmaker 2021 behaves different to LibO, zooms column and row headers. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150177] macOS Wildly blinking cursor and non-visible selection issues
https://bugs.documentfoundation.org/show_bug.cgi?id=150177
--- Comment #13 from will.brokenbourgh2...@gmail.com ---
Okay LO devs, it appears the issue is here:
vcl/osx/salframe.cxx on line 103 in function
AquaSalFrame::AquaSalFrame( SalFrame* pParent, SalFrameStyleFlags salFrameStyle
)
The code seems to just be blindly accepting whatever is in the defaults instead
of validating it. I recommend adding sanity checks before assigning something
as important as the blink time.
(Sorry, don't know how to add code tags to these reports)
- - - - -
mpParent = dynamic_cast(pParent);
initWindowAndView();
SalData* pSalData = GetSalData();
pSalData->mpInstance->insertFrame( this );
NSUserDefaults *userDefaults = [NSUserDefaults standardUserDefaults];
if (userDefaults != nil)
{
id setting = [userDefaults objectForKey:
@"NSTextInsertionPointBlinkPeriodOn"];
if (setting)
mnBlinkCursorDelay = [setting intValue];
else
{
setting = [userDefaults objectForKey:
@"NSTextInsertionPointBlinkPeriodOff"];
if (setting)
mnBlinkCursorDelay = [setting intValue];
}
}
- - - - -
--
You are receiving this mail because:
You are the assignee for the bug.
[Libreoffice-bugs] [Bug 124959] The formatting of the target paragraph should remain intact upon pasting content from another paragraph
https://bugs.documentfoundation.org/show_bug.cgi?id=124959 --- Comment #33 from Christian Lehmann --- Since nothing has been changed about the above in LO 7.3, I may add: The document contains - a bullet list, formatted by clicking the 'unordered list' button on the sidebar - a paragraph indented by clicking the 'indent' button on the sidebar - a table whose cells are formatted as 'Table content' by default. I copy a word from the list and paste it into an empty table cell. Table content format is preserved. Fine. I copy a word from the indented paragraph and paste it into an empty table cell. The table content is indented. Unexpected. This is just to back the principle suggested by me before: If a _substring_ of a block element (be it a paragraph, a list element, a table cell or what not) is copied, properties of the source block must _not_ be included with the copy operation; so there is no chance of pasting them into the target. Things are, of course, different if an entire block is copied. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 79944] VIEWING: SmartChart displayed incorrectly
https://bugs.documentfoundation.org/show_bug.cgi?id=79944 --- Comment #9 from Regina Henschel --- The SmartArt is no longer stretched in Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 4ba4b14e8101c6e025375b7d671bbb699f2dd23a CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: threaded But the object is right aligned and not centered. So bug is not fixed. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 139617] Optimal height isn't applied when shrinking word-wrapped cell (nor after entering the cell), only when content changes
https://bugs.documentfoundation.org/show_bug.cgi?id=139617 Justin L changed: What|Removed |Added Summary|Word wrap isn't applied |Optimal height isn't |when shrinking cell (nor|applied when shrinking |after entering the cell)|word-wrapped cell (nor ||after entering the cell), ||only when content changes Status|RESOLVED|NEW Resolution|DUPLICATE |--- Ever confirmed|0 |1 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 108252] [META] Cell-related bugs and enhancements
https://bugs.documentfoundation.org/show_bug.cgi?id=108252 Bug 108252 depends on bug 55433, which changed state. Bug 55433 Summary: EDITING, FORMATTING: Row Height fails to expand automatically after editing cell content in particular .ods https://bugs.documentfoundation.org/show_bug.cgi?id=55433 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 55433] EDITING, FORMATTING: Row Height fails to expand automatically after editing cell content in particular .ods
https://bugs.documentfoundation.org/show_bug.cgi?id=55433 Justin L changed: What|Removed |Added Resolution|--- |NOTABUG Status|NEW |RESOLVED --- Comment #17 from Justin L --- No surprise that "No Automatic Row heigth expansion.ods" doesn't expand cell A2. The document.xml defines So this style (which applies to both A1 and A2) sets a specific height and says to not use auto-height. [A round-trip of the file after setting optimal height worked fine.] -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 132532] FILEOPEN: DOCX: Smartart: Flowchart shows empty boxes
https://bugs.documentfoundation.org/show_bug.cgi?id=132532 Regina Henschel changed: What|Removed |Added CC||rb.hensc...@t-online.de --- Comment #14 from Regina Henschel --- (In reply to jake.weilhammer from comment #13) > Hello, > > Is there any updates on the priority or status of this ticket? Was just > wondering if there was any timeframe that I could expect for a bugfix > related to these cases. Bugs are fixed if a developer is paid for fixing it or if a developer enjoys fixing it in his spare time. In case a bug has a lot of duplicates or has a lot of people in CC, then such bug is proposed to be included in a tender from TDF, but that is not the case here. In case of the flowchart, the text boxes are not empty but have white font color on white background. The "automatic" setting does not work. You can workaround the problem, if in Word use a dedicated color other than pure white or black for the font. Other bug reports with font color problems in SmartArt are bug 54095 and bug 150065. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 141399] 'Update all' repositions text cursor
https://bugs.documentfoundation.org/show_bug.cgi?id=141399 --- Comment #4 from Christian Lehmann --- This bug has not gone away over the years (LO 7.3). I guess it should not be hard to fix: Before updating, just remember the position of the document on the screen and show it again after updating. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 141792] VIEW: Keep position of document in second LO window still
https://bugs.documentfoundation.org/show_bug.cgi?id=141792 Buovjaga changed: What|Removed |Added OS|Linux (All) |All Summary|VIEW: Keep position of |VIEW: Keep position of |document in second LO |document in second LO |window still (Linux-only) |window still --- Comment #8 from Buovjaga --- (In reply to Christian Lehmann from comment #7) > Sorry, I forgot to add that the behavior is observed in the LO Writer > running in the Windows 10 VM. Thus, the addition "Linux only" on the bug > title may be mistaken. Well, that was my own testing result on Win vs. Linux, but let's adjust per your findings. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 141792] VIEW: Keep position of document in second LO window still (Linux-only)
https://bugs.documentfoundation.org/show_bug.cgi?id=141792 --- Comment #7 from Christian Lehmann --- Sorry, I forgot to add that the behavior is observed in the LO Writer running in the Windows 10 VM. Thus, the addition "Linux only" on the bug title may be mistaken. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150942] Missing Hyphenation Data en-us
https://bugs.documentfoundation.org/show_bug.cgi?id=150942 --- Comment #3 from amab8...@protonmail.com --- thanks! Now it works. Maybe you can let the page behind "Read More" button lead to `hyphen-en` package? Would be helpful for future users -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 129661] [META] Right-To-Left (RTL) user interface issues
https://bugs.documentfoundation.org/show_bug.cgi?id=129661 Eyal Rozenberg changed: What|Removed |Added Depends on||124956 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=124956 [Bug 124956] [META] Icon theme language support -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 43808] [META] Right-To-Left and Complex Text Layout language issues (RTL/CTL)
https://bugs.documentfoundation.org/show_bug.cgi?id=43808 Eyal Rozenberg changed: What|Removed |Added Depends on|124956 | Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=124956 [Bug 124956] [META] Icon theme language support -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 124956] [META] Icon theme language support
https://bugs.documentfoundation.org/show_bug.cgi?id=124956 Eyal Rozenberg changed: What|Removed |Added Blocks|43808 |129661 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=43808 [Bug 43808] [META] Right-To-Left and Complex Text Layout language issues (RTL/CTL) https://bugs.documentfoundation.org/show_bug.cgi?id=129661 [Bug 129661] [META] Right-To-Left (RTL) user interface issues -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 109072] [META] XLS (binary) format bug tracker
https://bugs.documentfoundation.org/show_bug.cgi?id=109072 Justin L changed: What|Removed |Added Depends on||32950 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=32950 [Bug 32950] FORMATTING Cell height and word wrapping can be wrong (when changing) xls-files because 'Optimal height" of rows is not set (automatically?) -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 32950] FORMATTING Cell height and word wrapping can be wrong (when changing) xls-files because 'Optimal height" of rows is not set (automatically?)
https://bugs.documentfoundation.org/show_bug.cgi?id=32950 Justin L changed: What|Removed |Added Blocks||109072 CC||jl...@mail.com Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=109072 [Bug 109072] [META] XLS (binary) format bug tracker -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 143352] [META] XLSX (OOXML) Opening files from external generators
https://bugs.documentfoundation.org/show_bug.cgi?id=143352 Justin L changed: What|Removed |Added Depends on||123026 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=123026 [Bug 123026] LibreOffice ignore xlsxwriter 'text_wrap' formatting option, seems optimal height for row is not being set to hold cells with wrapped text -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 123026] LibreOffice ignore xlsxwriter 'text_wrap' formatting option, seems optimal height for row is not being set to hold cells with wrapped text
https://bugs.documentfoundation.org/show_bug.cgi?id=123026 Justin L changed: What|Removed |Added CC||jl...@mail.com Blocks||143352 Hardware|x86-64 (AMD64) |All Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=143352 [Bug 143352] [META] XLSX (OOXML) Opening files from external generators -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 148333] EDITING: Slow to edit paragraphs with fields in them (Linux-only)
https://bugs.documentfoundation.org/show_bug.cgi?id=148333 --- Comment #16 from Christian Lehmann --- A brief update on the earlier observation: In order to avoid turning thumbs until my keystrokes appear on the screen, I now work on that document in the Windows 10 virtual machine mentioned before. Although it runs in a virtual machine, it is perceptibly faster than LO running on the Linux host. However, even on Windows, the large document is clumsy. Summarizing, there appear to be two issues here: - LO cannot satisfactorily manage large documents. (I had some unsuccessful discussion in a different bug report on redundant markup in LO Writer documents and the necessity to offer the user a purge function.) - LO is slower on OpenSuse Linux than it is on Windows. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 75305] FORMATTING, FILEOPEN: Automatic row height doesn't work always .xls
https://bugs.documentfoundation.org/show_bug.cgi?id=75305 Justin L changed: What|Removed |Added See Also||https://bz.apache.org/ooo/s ||how_bug.cgi?id=93609 Priority|medium |low Severity|normal |minor -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 142966] With o margins and full-page image, text box disappears in RTL page, appears with LTR
https://bugs.documentfoundation.org/show_bug.cgi?id=142966 Eyal Rozenberg changed: What|Removed |Added Summary|File->New text doc, |With o margins and |Format->Page Style->Text|full-page image, text box |direction Right to Left + |disappears in RTL page, |Right margin set to 0, |appears with LTR |Inserted text box will | |disappear | -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 75305] FORMATTING, FILEOPEN: Automatic row height doesn't work always .xls
https://bugs.documentfoundation.org/show_bug.cgi?id=75305 --- Comment #13 from Justin L --- Created attachment 182447 --> https://bugs.documentfoundation.org/attachment.cgi?id=182447=edit i93609_auto_row_height.xlsb: from OpenOffice.org bug 93609 (In reply to Justin L from comment #12) > LibreOffice reports that a manual height has been set on row 3. Wrong. LO is reading in non-manual height, but it specifically calls SetManualHeight for merged horizontal cells because of https://bz.apache.org/ooo/show_bug.cgi?id=93609 if( bTextWrap ) GetOldRoot().pColRowBuff->SetManualRowHeight( rStart.Row() ); Bottom line: There is so much monkey business going on here, it isn't worth fixing this particular bug report. -- You are receiving this mail because: You are the assignee for the bug.
