Created attachment 82243 [details] problem demonstration file, including replication instructions Equation frames contain the equation/formula and the caption. When the equation/formula is created, the frame and caption are created with the width of the containing frame the same (or close to the same) size as the width of the equation. If the equation is small, say "x+3", then that width is imposed on the caption. The resultion caption is rendered as a column of text about 5 characters wide with all the words broken to fit the narrow width. If you use the frame handles to scale the frame to a better width, then the caption looks okay, but the equation font is scaled to be enormous. Neither option is viable for a professional document, and there doesn't seem to be any way around this problem. This bug has serios ramifications because it makes the tech-writer look incompetent.
Yes, I made a typo ... should be "serious".
and "resultion" => "resulting". Arrgh...no spell-checking in web forms.-(
This has been a bug against OpenOffice: https://issues.apache.org/ooo/show_bug.cgi?id=51453 since 2005! 6 people, plus me, have found this annoying enough to take the time to report.
Thanks for the report Steve. Confirmed. Status set to NEW. Version set to Inherited From OOo. As indicated in the related AOO bug: https://issues.apache.org/ooo/show_bug.cgi?id=51453#c7 ... the problem appears to stem from the setting of the style:rel-width="100%" attribute of the Object once a caption is inserted. This is the code indicated in the Apache issue: http://opengrok.libreoffice.org/xref/core/sw/source/core/doc/doclay.cxx#1309 ... and it has been that way since the beginning according to the OpenGrok history. By way of example, here is the x+3 formula in v4.1.3.2 XML: > <draw:frame draw:style-name="fr2" draw:name="Object1" text:anchor-type="as-char" svg:y="-0.377cm" svg:width="0.947cm" svg:height="0.467cm" draw:z-index="0"> ... and here is the captioned version: > <draw:frame draw:style-name="fr3" draw:name="Object2" text:anchor-type="paragraph" svg:width="0.947cm" style:rel-width="100%" svg:height="0.467cm" style:rel-height="scale" draw:z-index="2">
Might be fixed? http://cgit.freedesktop.org/libreoffice/core/commit/?id=235c790fdb04c27487de4510a0d51323f5442e70
(In reply to comment #5) > Might be fixed? > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=235c790fdb04c27487de4510a0d51323f5442e70 That fix seems to be for wrapping the equation rather than expanding the frame to cater for a lengthy caption against a short equation. Problem still present under GNU/Linux using v4.4.0.0.alpha0+ Build ID: 37b9ea92ba81d74764a2345a9c75c65bfd272d2b TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-08-26_09:48:30
(In reply to comment #6) > That fix seems to be for wrapping the equation rather than expanding the > frame to cater for a lengthy caption against a short equation. Apologies Joren, that fix /does/ look like it should fix the issue. Has this commit made it to LO yet? The problem is certainly still evident in the daily I indicated.
(In reply to comment #7) > (In reply to comment #6) > > That fix seems to be for wrapping the equation rather than expanding the > > frame to cater for a lengthy caption against a short equation. > > Apologies Joren, that fix /does/ look like it should fix the issue. Has this > commit made it to LO yet? The problem is certainly still evident in the > daily I indicated. Ugh. Please disregard comment 7. The problem persists.
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.0.0.5 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-09-03
Still repro. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 66d2b72667792cb18b25805387824d636e2a455c TinderBox: Win-x86@39, Branch:master, Time: 2015-11-18_02:35:53 Locale: fi-FI (fi_FI)
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
hm... If i resize frame to big and then undo it, I make right click to Math object and selecting item Properties from context menu -> opens dialogue Frame! In dialogue Frame i uncheck option "Relative to", then push OK And now i can resize frame to big without changing of size of Math object. But! If i open file from attach and try right click on Math object, then i cannot unchek option "Relative to" -> opens dialogue Object!, and checkbox "Relative to" is unactive! there is a bug, but this bug should be about opening wrong (?) dialogue when using item Properties from context menu? I checked this behavior in 6.1.0.1 on Windows
Created attachment 143525 [details] Result of experiment with resize frame
Created attachment 143526 [details] screencast with workaround
Actually #i51453 is fixed in bug 88443. Since then, math objects aren't assigned 100% width when label is inserted. Should this be closed duplicate of that? As to existing objects, the (optimized) workaround by Kompilainenn works: first, select the outer frame; then, select the formula object, and call its context menu, that will bring (unexpectedly!) a different options dialog compared to case when the formula object is selected when current selection is not its outer frame.
(In reply to Mike Kaganski from comment #15) > Actually #i51453 is fixed in bug 88443. Since then, math objects aren't > assigned 100% width when label is inserted. Should this be closed duplicate > of that? I was not strictly correct. The commit mentioned in comment 5 had fixed creation of auto-sizing objects in caption frames anew. Commits from bug 88443 were follow-ups that restored auto-sizing of objects except for math formulas. SO this bug is fixed since comment 5 (no idea what comment 8 meant; supposedly, comment 10 deals with the attachment with already-auto-sizing object, but new objects are, as mentioned, created OK).
The Formula creator in LibreOffice 6.3.4.2 does not create the formula frame relative to the paragraph area, as it did in earlier versions Thank you, Roman Kuznetsov, for the excellent workaround, which exposed what the underlying problem was!
(In reply to Steve Kelem from comment #17) > The Formula creator in LibreOffice 6.3.4.2 does not create the formula frame > relative to the paragraph area, as it did in earlier versions > > Thank you, Roman Kuznetsov, for the excellent workaround, which exposed what > the underlying problem was! Thanks for retesting the issue with the latest version. Setting to RESOLVED WORKSFORME since the commit fixing this issue hasn't been identified.