[Upstream] bug in displaying scalable square brackets in math object

Bug #827695 reported by rfvuhbtg on 2011-08-16
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
LibreOffice
Confirmed
Medium
OpenOffice
Confirmed
Low
libreoffice (Ubuntu)
Medium
Unassigned
openoffice.org (Ubuntu)
Undecided
Unassigned

Bug Description

1) lsb_release -rd
Description: Ubuntu 11.04
Release: 11.04

2) apt-cache policy libreoffice-writer
libreoffice-writer:
  Installed: 1:3.3.3-1ubuntu2
  Candidate: 1:3.3.3-1ubuntu2
  Version table:
 *** 1:3.3.3-1ubuntu2 0
        100 /var/lib/dpkg/status
     1:3.3.2-1ubuntu5 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty-updates/main i386 Packages
     1:3.3.2-1ubuntu4 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty/main i386 Packages

3) When is expected to happen in LibreOffice Writer via a terminal:
cd ~/Desktop && wget https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/827695/+attachment/2284273/+files/bracket_example.odt && lowriter --nologo bracket_example.odt

is the scalable square brackets look as they would in Word. Latex also shows the desired bracket shape as per https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/827695/+attachment/2287347/+files/latex_brackets.pdf .

4) What happens instead is the top and bottom part of the bracket look like a square instead of a line pointing inwards towards the equation.

Created attachment 41094
Example of bad behavior for scalable brackets

As shown on attached document (which includes a Math object and a screenshot with the problem highlighted), if you use scalable brackets for a big object like a matrix, they became more and more "bold", something should not happen.

[Reproducible] with "brackets.odt" and "LibreOffice 3.3.0 RC1 - WIN XP German UI [OOO330m17 (build 3.3.0.1"

Also visible with sample document and OOo 3.1.1, OOo 3.4.-dev

A workaround is to make the scalable brackets as usual, then make two more brackets (left and right) by themselves--two additional math objects, then use the Position and Size window to scale these up to the proper size, then position them on top of the bad brackets and use the align tool to make sure the good brackets and the math formula are properly aligned vertically.

But it seems like LibreOffice should be smart enough to properly scale the brackets by itself. How does LaTeX do things like that? Would its techniques in any way be transferable to LibreOffice?

Turns out the workaround I proposed is only possible in Impress. In Writer, it is impossible to have two math objects overlap.

So, can anyone do something about this? Kinda makes LibreOffice a non-starter when it comes to putting math formulas in documents.

rfvuhbtg (rfvuhbtg) wrote :

rfvuhbtg, thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at http://wiki.documentfoundation.org/BugReport . If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

description: updated
tags: added: lo33
Changed in libreoffice (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
rfvuhbtg (rfvuhbtg) wrote :

There's already a bug report about this, I think, here:

https://bugs.freedesktop.org/show_bug.cgi?id=32362

which also points back to an older bug from OpenOffice.org here:

http://openoffice.org/bugzilla/show_bug.cgi?id=66848

But it doesn't look like there's been any activity on it for long time. I only recently stumbled on this bug while putting together a document/presentation in LibreOffice. You can kind of work around it in Impress in a roundabout way by making a big font non-scalable bracket and putting it on top of the bad one, but there's no working around it in Writer. For any kind of stuff where you might use big brackets in math formulas, it makes Impress more difficult to use and Writer impossible to use compared to MS Office.

summary: - bug in displaying scalable brackets in math object
+ [Upstream] bug in displaying scalable square brackets in math object
Changed in openoffice:
importance: Unknown → Low
status: Unknown → Confirmed
rfvuhbtg (rfvuhbtg) wrote :

I guess I should also add, here is an example of a large math formula with scalable brackets rendered in LaTeX, to give an example of how it should look.

Changed in df-libreoffice:
importance: Unknown → Medium
status: Unknown → Confirmed
Changed in openoffice.org (Ubuntu):
status: New → Won't Fix

[This is an automated message.]
There are no new official OpenOffice.org releases in Ubuntu packaging anymore => Won't Fix

If the problem persists, please mark this bug as "also affects project Libreoffice" or "also affects distribution Libreoffice (Ubuntu)" if that has not happened already.

Please leave references to upstream OpenOffice.org bugs in place to allow cross pollination.

*** Bug 40998 has been marked as a duplicate of this bug. ***

Hi there - I need this bug fixed or I'll have export my thesis to word. Is there any system at libreoffice whereby I can put a bounty on this bug (say $100) and have someone else (like an admin or something) determine when its fixed, who fixed it and award the money accordingly?

Thanks,
peter.

I'd just like to add that the problem shows up for parentheses and braces as well as brackets.

I hope the developers get this bug fixed soon. I've had to switch away from LibreOffice until this is fixed.

This bug truly makes LibreOffice a non-starter for any kind of technical/scientific document or presentation--and those are the types of users who would tend to be most inclined to use LibreOffice over proprietary competitors as long as the quality is comparable.

Sorry, I have to retract the offer above as I am now slowly converting my thesis to word. I agree with rfvuhbtg above - the most likely professional users of libreoffice are people who are likely to use this functionality. Because of this bug, we can't use libreoffice to produce professional looking work.

*** Bug 42812 has been marked as a duplicate of this bug. ***

@Peter: please have a look at TexMathts extension (http://extensions.libreoffice.org/extension-center/texmaths-1)

Best regards. JBF

@Jean-Baptiste Faure - thanks very much for this. I'll have to redo my diagrams, but at least I get to keep using libreoffice :)

Created attachment 53928
updated example of bad bracket behaviour

I made a new example document that shows more problems with the brackets.

Right now there are two kinds of brackets. Normal and Scalable.

Normal Brackets just draw the Unicode character normally. It scales in the same way all the other characters scale and lines up just like a normal characer.

Scalable Brackets do something else. I am not sure what. They scale linearly to be the same hight as the object they inclose. They are not just normal brackets that get stretched up and down. they look different from the normal brackets even when the object they enclose is one character tall.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  Fixing this _The Right Way_ is NOT an easy hack
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

It would require actual mutations of the vector (bezier) curves inside the bracket characters that are drawn. Or a custom implementation of the bracket characters.

If this was done properly there would be only one kind of bracket, which would make them easier to use and fit the sort of "just works" standard that we all aspire to have in our software.

There isn't a solution that looks good and ONLY involves scaling.

Assuming that the bracket characters don't have a lot of unnessecary bezier curve endpoints along thier curves, the solution is to:

1. design a system so that arbitrary offsets can be applied to the positions of arbitrary curve endpoints. A demo of this system would be a character that fits inline and looks just like other characters, but can have a sine wave distortion applied to the positions of its curve endpoints so that it wobbles like a skrillex song.

2. design a new scaling system based on the previous step. The character is placed in front of the object to inclose, and looks just like how the Normal brackets look now. Then, the curve endpoints that lie in the top third of the character are moved until thier top edge lines up with the top edge of the object to be enclosed, and the bottom third moved down in a similar fasion.

It is possible that this would produce bad curves on something like the curly brace, but in theory the curve tangents could be adjusted algorithmically based on the distance that the endpoints were moved, to compensate.

Created attachment 53929
Image showing how bracket characters need to be mutated

[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html

Changed in df-libreoffice:
status: Confirmed → Incomplete

The problem is present on 3.5 beta2.

Changed in df-libreoffice:
status: Incomplete → Confirmed

@András:
Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.

The right way to fix this bug is to use several glyphs to draw the brace e.g. one glyph for the top, one for the middle and one for the bottom. The rest of the brace are two vertical lines that can easily be extended to arbitrary size (e.g. by repeating a glyph for vertical bar or drawing a line). In general, you need to use some specific mathematical fonts that contain the glyphs for the most important stretchy operators e.g. the STIX fonts.

There have been discussion on the LibreOffice mailing list about using STIX fonts as well as supporting the Open Type Math table (here, at least the stretchy variants/constructions would help).

CC'ing Khaled Hosny.

I had a cursory look at Math while ago, and my impression is that it is a hopeless case, it has to be rewritten from scratch (at least the math renderer) if any sane math rendering is to be achieved.

A year or two ago I asked about this bug because I needed it fixed for my thesis. Someone suggested using the TexMaths Equations editor instead (it embeds LaTeX into LibreOffice). This worked perfectly and saved me from having to convert my work to word. Is there any way we could just use this instead? It properly scales brackets with large objects. I'd recommend it, because I think this bug is about a decade old.

Thanks for the replies. I have to say that I studied LibreOffice Math after some reports from MathJax users about issues with mathematical formulas. So I'm mainly concerned about getting a good MathML export at the moment so that LibreOffice users can publish their content on the Web. (Of course, I also realize it is important to have an open-source office productivity software suite with good math rendering but that's not my personal priority).

I've just posted some thoughts on what could be done in the future:
http://lists.freedesktop.org/archives/libreoffice/2013-June/053727.html

In order to limit the confusion between ProposedEasyHack and EasyHack and to make queries much easier we are changing ProposedEasyHack to NeedsDevEval.

Thank you and apologies for the noise

Changed version to Inherited from OOo due to comment #2.

Best regards. JBF

Peter K Nicol (pknicol) wrote :

Maybe this is a new bug - see attached. First seen In Libreoffice version 4.2.6.3. Scalable brackets now appear as bold. It makes maths look ugly. Peter

Please read this message in its entirety before responding.

Your bug was confirmed at least 1 year ago and has not had any activity on it for over a year. Your bug is still set to NEW which means that it is open and confirmed. It would be nice to have the bug confirmed on a newer version than the version reported in the original report to know that the bug is still present -- sometimes a bug is inadvertently fixed over time and just never closed.

If you have time please do the following:
1) Test to see if the bug is still present on a currently supported version of LibreOffice (preferably 4.2 or newer).
2) If it is present please leave a comment telling us what version of LibreOffice and your operating system.
3) If it is NOT present please set the bug to RESOLVED-WORKSFORME and leave a short comment telling us your version and Operating System

Please DO NOT
1) Update the version field
2) Reply via email (please reply directly on the bug tracker)
3) Set the bug to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link:
https://wiki.documentfoundation.org/QA/BugTriage

There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/.

Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material

Peter K Nicol, this bug report is scoped only to the problem and the document the original reporter attached, not yours. Hence, please follow https://wiki.ubuntu.com/LibreOfficeBugWrangling when filing a new bug report to have your issue addressed via a terminal:
ubuntu-bug libreoffice-writer

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

tags: added: amd64 trusty
description: updated

Reproducibe in MASTER:
Version: 4.4.0.0.alpha1+
Build ID: a6b01d01f77f84517d267bdfe31de91b9050a70c
TinderBox: Win-x86@39, Branch:master, Time: 2014-10-23_07:22:13

Reproducible on Version: 4.2.3.3, OS X (I tested it using the sample document above).
Reading the comments above, it is clear this bug is not going to magically go away without a substantial rewrite.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.