| Summary: | Scaling equation frame scales equation font | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Steve Kelem <steve> |
| Component: | Formula Editor | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | rb.henschel |
| Version: | Inherited From OOo | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://issues.apache.org/ooo/show_bug.cgi?id=51453 | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | problem demonstration file, including replication instructions | ||
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. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
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.