Bug 32362 - Bad behavior of scalable brackets with large objects (comment 18)
Summary: Bad behavior of scalable brackets with large objects (comment 18)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Formula Editor (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyInteresting, needsDevEval, skillCpp
: 40998 42812 154892 155534 (view as bug list)
Depends on: hb_ot_math 101174
Blocks: Formula-Editor
  Show dependency treegraph
 
Reported: 2010-12-13 14:37 UTC by RGB
Modified: 2024-02-23 20:23 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


Attachments
Example of bad behavior for scalable brackets (15.86 KB, application/vnd.oasis.opendocument.text)
2010-12-13 14:37 UTC, RGB
Details
updated example of bad bracket behaviour (45.59 KB, application/vnd.oasis.opendocument.text)
2011-11-28 23:18 UTC, Forest Johnson
Details
Image showing how bracket characters need to be mutated (34.89 KB, image/jpeg)
2011-11-28 23:21 UTC, Forest Johnson
Details
Example of scalable brackets (30.04 KB, application/pdf)
2015-06-25 08:48 UTC, Peter Nicol
Details
Comparision between version 2015_08_04 and 2015_08_12 (15.33 KB, application/vnd.oasis.opendocument.text)
2016-01-13 21:06 UTC, Regina Henschel
Details
Announced attachment (115.55 KB, application/vnd.oasis.opendocument.text)
2020-06-17 10:11 UTC, Wolfgang Jäger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description RGB 2010-12-13 14:37:49 UTC
Created attachment 41094 [details]
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.
Comment 1 Rainer Bielefeld Retired 2010-12-14 01:13:42 UTC
[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
Comment 2 Jean-Baptiste Faure 2010-12-18 10:57:09 UTC
Old known bug in OOo : http://www.openoffice.org/issues/show_bug.cgi?id=66848

Best regards. JBF
Comment 3 rfvuhbtg 2011-08-03 08:06:05 UTC
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?
Comment 4 rfvuhbtg 2011-08-16 15:41:00 UTC
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.
Comment 5 Rainer Bielefeld Retired 2011-08-23 23:21:09 UTC
@rfvuhbtg
<http://wiki.documentfoundation.org/BugReport_Details#Version>
Comment 6 Rainer Bielefeld Retired 2011-09-18 22:16:51 UTC Comment hidden (obsolete)
Comment 7 peter 2011-10-24 15:17:59 UTC
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.
Comment 8 rfvuhbtg 2011-11-11 07:31:11 UTC
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.
Comment 9 peter 2011-11-20 19:23:54 UTC
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.
Comment 10 Jean-Baptiste Faure 2011-11-20 21:05:27 UTC
*** Bug 42812 has been marked as a duplicate of this bug. ***
Comment 11 Jean-Baptiste Faure 2011-11-20 21:10:17 UTC
@Peter: please have a look at TexMathts extension (http://extensions.libreoffice.org/extension-center/texmaths-1)

Best regards. JBF
Comment 12 peter 2011-11-20 22:03:04 UTC
@Jean-Baptiste Faure - thanks very much for this. I'll have to redo my diagrams, but at least I get to keep using libreoffice :)
Comment 13 Forest Johnson 2011-11-28 23:18:48 UTC
Created attachment 53928 [details]
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.
Comment 14 Forest Johnson 2011-11-28 23:21:15 UTC
Created attachment 53929 [details]
Image showing how bracket characters need to be mutated
Comment 15 Björn Michaelsen 2011-12-23 11:35:36 UTC Comment hidden (obsolete)
Comment 16 RGB 2011-12-23 16:51:54 UTC
The problem is present on 3.5 beta2.
Comment 17 Rainer Bielefeld Retired 2011-12-31 00:10:03 UTC
@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.
Comment 18 Frédéric Wang 2013-06-23 19:19:57 UTC
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.
Comment 19 ⁨خالد حسني⁩ 2013-06-23 23:11:12 UTC
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.
Comment 20 peter 2013-06-24 01:18:03 UTC
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.
Comment 21 Frédéric Wang 2013-06-24 06:29:00 UTC
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
Comment 22 Joel Madero 2014-02-27 23:17:56 UTC
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
Comment 23 Jean-Baptiste Faure 2014-06-09 17:12:27 UTC
Changed version to Inherited from OOo due to comment #2.

Best regards. JBF
Comment 24 QA Administrators 2014-10-23 17:32:22 UTC Comment hidden (obsolete)
Comment 25 Chris Peñalver 2014-10-23 23:45:46 UTC
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
Comment 26 peter 2014-10-24 00:08:20 UTC
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.
Comment 27 Peter Nicol 2015-06-25 08:48:48 UTC
Created attachment 116818 [details]
Example of scalable brackets

Bug still present in 4.3.7.2 (but not in previous version)
Input:  left(5 over x right)
Comment 28 Wolfgang Jäger 2015-10-28 16:02:04 UTC
The bug is still present in Version 5.0.2.
There is a recent thread in ask.libreoffice concerning the issue: https://ask.libreoffice.org/en/question/60133/how-to-get-better-scalable-bracket/

It is containing a new offer of inducement.
Comment 29 Robinson Tryon (qubit) 2015-12-14 06:12:23 UTC Comment hidden (obsolete)
Comment 30 Regina Henschel 2016-01-13 21:06:05 UTC
Created attachment 121908 [details]
Comparision between version 2015_08_04 and 2015_08_12

It is not the old bug, but a newly introduced regression

The rendering is OK till
Version: 5.1.0.0.alpha1+
Build ID: a933e01a54f08132c2d8699f7c6851a8b493d5dc
TinderBox: Win-x86@39, Branch:master, Time: 2015-08-04_06:10:12
Locale: de-DE (de_DE)

The rendering is bad since
Version: 5.1.0.0.alpha1+
Build ID: c614e711136205252ac2c72f9772c718dafc471e
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-08-12_20:36:06
Locale: de-DE (de_DE)
Comment 31 Joel Madero 2016-01-13 21:07:13 UTC
If it's the same issue then we should mark as regression, request a bibisect, and update the version field....else new bug is appropriate
Comment 32 Regina Henschel 2016-01-13 21:28:08 UTC
It was correct in-between, so it is not the old bug. I have written a new report bug 97111.
Comment 33 Volga 2016-11-24 03:17:44 UTC
Since LibreOffice have intergrated HarfBuzz, this can be resolved via using ot-math APIs (bug 103680).
Comment 34 Volga 2016-11-29 08:36:43 UTC
Also, you can try to combine some Miscellaneous Technical characters together to get expected output. 
See: https://graphemica.com/blocks/miscellaneous-technical/page/3
Comment 35 Frédéric Wang 2016-11-29 08:43:03 UTC
(In reply to Volga from comment #34)
> Also, you can try to combine some Miscellaneous Technical characters
> together to get expected output. 
> See: https://graphemica.com/blocks/miscellaneous-technical/page/3

Note that these constructions should already be integrated into the MathVariant subtable of the OpenType MATH table accessible via the new HarfBuzz API.
Comment 36 Volga 2016-12-03 03:39:58 UTC Comment hidden (obsolete)
Comment 37 Volga 2017-01-08 21:01:34 UTC
(In reply to Frédéric Wang from comment #35)
> Note that these constructions should already be integrated into the
> MathVariant subtable of the OpenType MATH table accessible via the new
> HarfBuzz API.

Wow, it seems to me we can get an all-in-one solution for this bug.
Comment 38 Volga 2017-08-11 18:25:50 UTC
With attachment 53928 [details] the squared brackts [] still bad scaled in LO 5.4.0, they looks the same as embedded screenshot.
Version: 5.4.0.3 (x64)
Build ID:7556cbc6811c9d992f4064ab9287069087d7f62c
CPU 线程:4; 操作系统:Windows 6.19; UI 渲染:默认; 
Locale: zh-CN (zh_CN); Calc: CL

Additionaly, LO Math does not allow to set font face for symbols, so we have no way to use several fonts as Asana Math, Cambria Math, XITS etc. to test and judge whether LO can make use of OT MATH extension to present scaled such objects.
Comment 39 QA Administrators 2018-08-12 02:35:25 UTC Comment hidden (obsolete)
Comment 40 RGB 2018-08-12 06:48:44 UTC
Problem still present in 6.1.0.3
Comment 41 Roman Kuznetsov 2018-11-20 11:29:43 UTC
scalable brackets look fine for me in

Версия: 6.2.0.0.beta1
ID сборки: d1b41307be3f8c19fe6f1938cf056e7ff1eb1d18
Потоков ЦП: 4; ОС:Windows 6.1; Отрисовка ИП: по умолчанию; VCL: win; 
Локаль: ru-RU (ru_RU); UI-Language: ru-RU
Calc: threaded

people, please retest this in latest dev build 6.2
Comment 42 V Stuart Foote 2018-11-20 14:28:12 UTC
(In reply to Roman Kuznetsov from comment #41)
> scalable brackets look fine for me in
> 
> Версия: 6.2.0.0.beta1
> ID сборки: d1b41307be3f8c19fe6f1938cf056e7ff1eb1d18
> Потоков ЦП: 4; ОС:Windows 6.1; Отрисовка ИП: по умолчанию; VCL: win; 
> Локаль: ru-RU (ru_RU); UI-Language: ru-RU
> Calc: threaded
> 
> people, please retest this in latest dev build 6.2

No. Attachment 53928 [details] shows scalable brackets still being "stretched" vertically to fit the node. Although precision of glyph scaling for stamping into node frame has improved in Windows builds at 6.2. A proper resolution requires implementation of multi-glyph 3 element (eg. 0x239b-0x23b3) and 2 element (e.g. 0x2320, 0x2321) composition.

=-testing-=
Windows 10 Home 64-bit en-US (1803) with
Version: 6.2.0.0.alpha1+ (x64)
Build ID: 525ed5d1fcb89412f0b80be0b1e35410b048c337
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-15_23:08:09
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 43 Volga 2019-07-14 14:00:25 UTC
Wikipedia has an article documented these characters for bracket extension:
https://en.wikipedia.org/wiki/Bracket#Encoding_in_digital_media
Comment 44 Wolfgang Jäger 2019-12-10 12:28:02 UTC
(In reply to Regina Henschel from comment #32 of 2016-01-13)
> It was correct in-between, so it is not the old bug. ...

What version(s) did it correctly? May the quoted statement have been an error?

Will the issue be addressed one day? 

Despite the fact that there isn't much mention of the 'Math' component in forums I would assume that afflicted users (teachers e.g.) might be relevant "agents" concerning the standing of free and open software.
Comment 45 Wolfgang Jäger 2019-12-10 12:29:26 UTC
The bug is still present in V6.4.0.0.beta1.
Comment 46 V Stuart Foote 2019-12-10 12:56:28 UTC
(In reply to Wolfgang Jäger from comment #44)
> (In reply to Regina Henschel from comment #32 of 2016-01-13)
> > It was correct in-between, so it is not the old bug. ...
> 
> What version(s) did it correctly? May the quoted statement have been an
> error?
> 

See comment 30 and bug 97111, after that back to staus quo inherited from OOo-- with some intervening improvements to accuracy of fitting the stretched bracketing glyphs into their node bounds.

> Will the issue be addressed one day? 

Possibly, and you get notice of it here.

> 
> Despite the fact that there isn't much mention of the 'Math' component in
> forums I would assume that afflicted users (teachers e.g.) might be relevant
> "agents" concerning the standing of free and open software.

And?  Teachers also are welcome to contribute source (as Regina does regularly) ;-)
Comment 47 Wolfgang Jäger 2019-12-10 20:28:07 UTC
(In reply to V Stuart Foote from comment #46)
> (In reply to Wolfgang Jäger from comment #44)
> > (In reply to Regina Henschel from comment #32 of 2016-01-13)
> > > It was correct in-between, so it is not the old bug. ...
> > ...

> See comment 30 and bug 97111, after that back to staus quo inherited from
> OOo-- with some intervening improvements to accuracy of fitting the
> stretched bracketing glyphs into their node bounds.
> 
Seems you wouldn't call the status quo ante "good rendering" without a blink.
> > Will the issue be addressed one day? 
> 
> Possibly, and you get notice of it here.
Great.

SORRY. I had forgotten about a former visit to this thread, and had missed the mentioned comment by Regina. 
Anyway I couldn't test with the two builds she mentioned, and my test with 
V5.0.2.2.release (32 bit PortableApp on Win 10; version before the claimed change) showed the issue in exactly the same way as the "Bad  rendering since 2015_08_12" in Regina's comparison did.

> > Despite the fact that there isn't much mention of the 'Math' component in
> > forums I would assume that afflicted users (teachers e.g.) might be relevant
> > "agents" concerning the standing of free and open software.
> 
> And?  Teachers also are welcome to contribute source (as Regina does
> regularly) ;-)

I appreciate Regina's contributions, of course. I'm also glad that contributions by the teacher I am would be welcome. Unfortunately I completely lack the needed knowledge about fonts and many related topics. Being 75 now I also cannot expect to find my way inside the labyrinth which C-code in general and the code base of a huge project like LibreOffice in specific is to me during the time left.
Comment 48 dante19031999 2020-06-17 02:26:48 UTC
Hello,
This comment is going to be post on the bugs: bug 32362 bug 133081 bug 92373 bug 127483
All those bugs seem to be related.
In my humble opinion as begginer programmer they seem to be related with a disfunction with OpenGL in windows.
Tested on linux (LO 6.4), no problem.
Tested with beta 7 on windows, no problem (does not use OpenGL any more).
So the bug happened to correct by itself.
So I suggest marking as duplicated bug 32362 bug 133081 bug 127483 and close them all.
Comment 49 Wolfgang Jäger 2020-06-17 10:11:15 UTC
Created attachment 162107 [details]
Announced attachment

(In reply to dante19031999 from comment #48)
> ...
> In my humble opinion as begginer programmer they seem to be related with a
> disfunction with OpenGL in windows.
> ...

Either misunderstood completely or cannot confirm:  
With LibO 7.0.0.0.beta1 under Win 10 I got exactly the behavior previously described independent of whether 'skia' was enabled or not. 

See new attachment.
Comment 50 RGB 2020-06-17 11:04:51 UTC
@dante19031999 this is NOT an OpenGL or OS related problem. Indeed, this problem predates the whole introduction of OpenGL support into the suite. 

Insert a Math object into Writer and type this code

left[ stack{1#2#3#4#5#6#7#8} right]

you'll immediately see how wrong square brackets are, independently of OpenGL, OS or anything: just print or export to PDF to see that's NOT a display problem, but something deeper.
Comment 51 dante19031999 2020-06-17 15:14:25 UTC
(In reply to RGB from comment #50)
> @dante19031999 this is NOT an OpenGL or OS related problem. Indeed, this
> problem predates the whole introduction of OpenGL support into the suite. 
> 
> Insert a Math object into Writer and type this code
> 
> left[ stack{1#2#3#4#5#6#7#8} right]
> 
> you'll immediately see how wrong square brackets are, independently of
> OpenGL, OS or anything: just print or export to PDF to see that's NOT a
> display problem, but something deeper.

Sorry. My bad.
Comment 52 ⁨خالد حسني⁩ 2023-04-19 14:34:07 UTC
*** Bug 154892 has been marked as a duplicate of this bug. ***
Comment 53 ⁨خالد حسني⁩ 2023-08-25 07:06:43 UTC
*** Bug 155534 has been marked as a duplicate of this bug. ***
Comment 54 RGB 2024-02-23 20:23:08 UTC
*** Bug 40998 has been marked as a duplicate of this bug. ***