Bug 53472 - FORMATTING: Integral Symbols too small for some integrands
Summary: FORMATTING: Integral Symbols too small for some integrands
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Formula Editor (show other bugs)
Version:
(earliest affected)
3.6.0.4 release
Hardware: Other All
: medium minor
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: target:5.2.0 target:5.3.0
Keywords: difficultyInteresting, easyHack, skillCpp, topicUI
Depends on:
Blocks:
 
Reported: 2012-08-14 03:01 UTC by Roberto
Modified: 2017-02-14 08:57 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
An example where the default integral symbol doesn't look ok. (1.07 KB, image/png)
2012-08-14 03:01 UTC, Roberto
Details
Change in the SmOperNode::Arrange (438.14 KB, application/x-zip)
2012-11-08 11:44 UTC, Véghelyi András
Details
before in hxx file (103.14 KB, image/png)
2012-11-08 11:51 UTC, Véghelyi András
Details
after hxx-file (101.20 KB, image/png)
2012-11-08 11:53 UTC, Véghelyi András
Details
int-sum-prod (49.66 KB, image/png)
2012-11-08 12:00 UTC, Véghelyi András
Details
Size of the Sum,Prod,Int Symbol (54.00 KB, image/png)
2012-11-20 11:33 UTC, Véghelyi András
Details
Collection operators with large body (44.32 KB, application/vnd.oasis.opendocument.presentation)
2016-05-12 10:32 UTC, Regina Henschel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roberto 2012-08-14 03:01:35 UTC
Created attachment 65525 [details]
An example where the default integral symbol doesn't look ok.

Problem description: default integral symbol doesn't look good with two or more lines height integrands.

Steps to reproduce:
1. Open L.O. Math.
2. Write any integral which integrand has more than a line height, for example:
 int {{{sum from{1} to{n} {f_k(z)}} over e^z} dz} 

Current behavior: default integral symbol looks 'out placed'. Too small for such a high integrand. 

Expected behavior: as in the case of brackets, include a scalable integral symbol that can adjust to two-or-more-line-height integrands.

Please, note that this was required for OpenOffice.org long time ago: https://issues.apache.org/ooo/show_bug.cgi?id=45511 

Platform (if different from the browser): 
              
Browser: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20100101 Firefox/14.0.1
Comment 1 leighman 2012-10-02 11:40:33 UTC
Still a problem in master e4080dc (1 Oct, 16.50)
Confirming.
Comment 2 Andras Timar 2012-10-05 11:51:49 UTC
See e.g. resizing of root sign at http://opengrok.libreoffice.org/xref/core/starmath/source/visitors.cxx#657
void SmDrawingVisitor::Visit( SmRootSymbolNode* pNode )
Something similar should be done with integral, product, sum, etc. signs.
Comment 3 Véghelyi András 2012-11-08 11:44:56 UTC
Created attachment 69690 [details]
Change in the SmOperNode::Arrange
Comment 4 Véghelyi András 2012-11-08 11:51:15 UTC
Created attachment 69692 [details]
before in hxx file
Comment 5 Véghelyi András 2012-11-08 11:53:35 UTC
Created attachment 69693 [details]
after hxx-file
Comment 6 Véghelyi András 2012-11-08 12:00:01 UTC
Created attachment 69694 [details]
int-sum-prod
Comment 7 Roberto 2012-11-17 23:20:06 UTC
(In reply to comment #6)
> Created attachment 69694 [details]
> int-sum-prod

Hi, Véghelyi.

I think the behaviour showed in your last attachment is in the right direction. I only have three questions. 

1) Have you done a modification to the code, or it is only a mockup?

2) Some people have argued that, in professional documents, mathematical operators should always have the same size. So, they think these operators shouldn't be adjustable to the respective operand size. For those that think this way, is there a method to leave the operator size unchanged?

3) If you look at the adjusted product operand, don't you think that it sholud be wider? It's only a personal appreciation, but I feel it too 'narrow'.

Finally, thank you very much for your efforts. Mockup or a real intervention to the code, it's the first time I see somebody working to improve this feature in Math. I hope to see good news in a future release.

Kind regards.

Roberto.
Comment 8 Véghelyi András 2012-11-19 11:07:02 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > Created attachment 69694 [details]
> > int-sum-prod
> 
> Hi, Véghelyi.
> 
> I think the behaviour showed in your last attachment is in the right
> direction. I only have three questions. 
> 
> 1) Have you done a modification to the code, or it is only a mockup?
> 
> 2) Some people have argued that, in professional documents, mathematical
> operators should always have the same size. So, they think these operators
> shouldn't be adjustable to the respective operand size. For those that think
> this way, is there a method to leave the operator size unchanged?
> 
> 3) If you look at the adjusted product operand, don't you think that it
> sholud be wider? It's only a personal appreciation, but I feel it too
> 'narrow'.
> 
> Finally, thank you very much for your efforts. Mockup or a real intervention
> to the code, it's the first time I see somebody working to improve this
> feature in Math. I hope to see good news in a future release.
> 
> Kind regards.
> 
> Roberto.

Hi, Roberto

First of all, sorry my bad english.

1) Yes, I have modified the code, and I have uploaded to the gerrit.libreoffice.org.

2) I have not thought this question yet, but I think we can modify the code to do, what you aks.

3)Not just the product the 'narrow', just you can see better in this symbol the narrow.

pSymbol->SetSize(Fraction(CalcSymbolHeight(*pSymbol, rFormat),
                         pSymbol->GetFont().GetSize().Height()));

This function is the responsible for the size. But I commented it, because with this we can not do the height. Also it was responsible for the wide too.

( This function is in starmath/source/node.cxx in SmOperNode::Arrange operation, line 1960 )

Kind regards.

Véghelyi
Comment 9 Véghelyi András 2012-11-20 11:33:31 UTC
Created attachment 70305 [details]
Size of the Sum,Prod,Int Symbol
Comment 10 Roberto 2012-11-22 02:18:07 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > Created attachment 69694 [details]
> > > int-sum-prod
> > 
> > Hi, Véghelyi.
> > 
> > I think the behaviour showed in your last attachment is in the right
> > direction. I only have three questions. 
> > 
> > 1) Have you done a modification to the code, or it is only a mockup?
> > 
> > 2) Some people have argued that, in professional documents, mathematical
> > operators should always have the same size. So, they think these operators
> > shouldn't be adjustable to the respective operand size. For those that think
> > this way, is there a method to leave the operator size unchanged?
> > 
> > 3) If you look at the adjusted product operand, don't you think that it
> > sholud be wider? It's only a personal appreciation, but I feel it too
> > 'narrow'.
> > 
> > Finally, thank you very much for your efforts. Mockup or a real intervention
> > to the code, it's the first time I see somebody working to improve this
> > feature in Math. I hope to see good news in a future release.
> > 
> > Kind regards.
> > 
> > Roberto.
> 
> Hi, Roberto
> 
> First of all, sorry my bad english.
> 
> 1) Yes, I have modified the code, and I have uploaded to the
> gerrit.libreoffice.org.
> 
> 2) I have not thought this question yet, but I think we can modify the code
> to do, what you aks.
> 
> 3)Not just the product the 'narrow', just you can see better in this symbol
> the narrow.
> 
> pSymbol->SetSize(Fraction(CalcSymbolHeight(*pSymbol, rFormat),
>                          pSymbol->GetFont().GetSize().Height()));
> 
> This function is the responsible for the size. But I commented it, because
> with this we can not do the height. Also it was responsible for the wide too.
> 
> ( This function is in starmath/source/node.cxx in SmOperNode::Arrange
> operation, line 1960 )
> 
> Kind regards.
> 
> Véghelyi

Hi again, Véghelyi.

First of all, don't worry about your english. I'm from Chile, so I'm not a native English-speaker, and (therefore) probably will make mistakes too.

1) It's amazing. It means that we'll probably see another Math improvement. It's great!

2) Last time, I didn't remember where I read that observation, but today I found the place: https://issues.apache.org/ooo/show_bug.cgi?id=26048 (comment number 2, by thomas.lange). This is the reason for which I think that providing a way to leave the operator size unchanged, would be a good idea (the more flexible the tool is, the best it will be for L.O Math). Maybe, a nice idea would be to create a specific command for a 'scalable' operator, and keep using the current 'int', 'sum', 'prod' commands for 'non-scalable' operators (just like L.O. Math currently handles 'scalable' and 'non-scalable' parentheses/brackets).

3) Sorry, but I did'n understand what you meant by 'not just the product the narrow'. Maybe it's my fault, I probably didn't express my idea in a right way. I only want to clarify something: when I told that the product operator seems a little bit 'narrow' to me, I didn't express my opinion about the thikness of the 'stroke/line' that is being used to draw the operator. Instead, I was talking about the 'horizontal space' that the whole operator takes up in the resulting formula.

4) Why the integral symbol in your last attachment is so 'fat'?

Finally, thank you very (really, VERY) much for spending your time working on this issue. 

Kind regards.

Roberto.
Comment 11 Björn Michaelsen 2013-10-04 18:46:07 UTC
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Comment 12 Matteo Campanelli 2014-02-20 22:49:01 UTC
Hi everybody, I was planning to put hands on this issue as my first time hacking L.O..
I would like to ask some questions on which general directions it may be better to take:

- Reading past discussion, it seems to me that there is some agreement on the fact that dynamically-sized integrals/sums/products/etc. should be given as a command additional to "int" & C.. In other words, dynamic size should be optional. Is that correct?

- There seems to be some work done by Véghelyi András in the past (see previous commments in this issue). That code may possibly be a good starting point.
I'm not familiar at all with Gerrit and the rest of the patch/merge workflow in L.O., but is this code available anywhere? Was it integrated at the time in L.O.? Or, how could I check such a thing? 

Comments of any kind are very appreciated.

Thanks,
Matteo
Comment 13 Roberto 2014-02-21 01:13:51 UTC
(In reply to comment #12)
> Hi everybody, I was planning to put hands on this issue as my first time
> hacking L.O..
> I would like to ask some questions on which general directions it may be
> better to take:
> 
> - Reading past discussion, it seems to me that there is some agreement on
> the fact that dynamically-sized integrals/sums/products/etc. should be given
> as a command additional to "int" & C.. In other words, dynamic size should
> be optional. Is that correct?
> 
> - There seems to be some work done by Véghelyi András in the past (see
> previous commments in this issue). That code may possibly be a good starting
> point.
> I'm not familiar at all with Gerrit and the rest of the patch/merge workflow
> in L.O., but is this code available anywhere? Was it integrated at the time
> in L.O.? Or, how could I check such a thing? 
> 
> Comments of any kind are very appreciated.
> 
> Thanks,
> Matteo

Dear Mateo:
About your first point, my humble opinion is that dynamic size should be optional (some people think that different instances of the same operator, belonging to the same line, should not have different sizes; despite of the size of their operands. Check https://issues.apache.org/ooo/show_bug.cgi?id=45511 for details).
I have no information about your questions in your second point.

Kind regards.
Comment 14 Matteo Campanelli 2014-03-01 11:35:35 UTC
Hi all,
so I worked a little on dynamically-sized integrals and I have something working.
I added a new command "intd" for the purpose. An user can still use the old "int" to have the usual effect.

The picture at the URL below shows how the integral sign with "intd" resizes according to its body argument. Notice that the last line is an ordinary "int" and is there for comparison purposes.
http://i.imgur.com/Oc5N5Qy.png

The code I currently have should be easily adapted to sum, products and so forth.

Best,
Matteo
Comment 15 Commit Notification 2014-03-15 22:46:21 UTC
matteocam committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=93e6291c29d547c0c29c6e43b2ca4b36a3e8506f

fdo#53472 Created Dynamic Integral Node classes. Integrals size made dependent on body.



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 16 melikeyurtoglu 2015-10-27 18:39:08 UTC
Hi, I send following patch for this bug:
http://ci.libreoffice.org/job/lo_gerrit_master/7509/

I can resize the integral sign with the changes I made.I do provide the expected behavior change.But when I do "make startmath", I get the following output;
cd /home/melike/libreoffice/starmath && make  -j 2 -rs
[build BIN] top level modules: starmath
[build LOC] top level modules: starmath
[build ALL] top level modules: build-non-l10n-only build-l10n-only
[build CUT] starmath_import
[build CUT] starmath_qa_cppunit
/home/melike/libreoffice/starmath/qa/cppunit/test_nodetotextvisitors.cxx:447:(anonymous namespace)::Test::SimpleOperators
equality assertion failed
- Expected: { int r _ 0 }
- Actual  : int r _ 0
- Upper and lower bounds shown with integral (from & to)

test_nodetotextvisitors.cxx:447:Assertion
Test name: (anonymous namespace)::Test::SimpleOperators
equality assertion failed
- Expected: { int r _ 0 }
- Actual  : int r _ 0
- Upper and lower bounds shown with integral (from & to)

Failures !!!
Run: 21   Failure total: 1   Failures: 1   Errors: 0

Error: a unit test failed, please do one of:

export DEBUGCPPUNIT=TRUE            # for exception catching
export CPPUNITTRACE="gdb --args"    # for interactive debugging on Linux
export VALGRIND=memcheck            # for memory checking

and retry using: make CppunitTest_starmath_qa_cppunit

/home/melike/libreoffice/solenv/gbuild/CppunitTest.mk:87: recipe for target '/home/melike/libreoffice/workdir/CppunitTest/starmath_qa_cppunit.test' failed
make[1]: *** [/home/melike/libreoffice/workdir/CppunitTest/starmath_qa_cppunit.test] Error 1
Makefile:102: recipe for target 'starmath' failed
make: *** [starmath] Error 2


I made the export process(export CPPUNITTRACE="gdb --args").
I run the command to make cppunittest_starmath_qa_cppunit;
gdb worked;
(gdb) r
Starting program: /home/melike/libreoffice/workdir/LinkTarget/Executable/cppunittester /home/melike/libreoffice/workdir/LinkTarget/CppunitTest/libtest_starmath_qa_cppunit.so --headless -env:BRAND_BASE_DIR=file:///home/melike/libreoffice/instdir -env:BRAND_SHARE_SUBDIR=share -env:UserInstallation=file:///home/melike/libreoffice/workdir/CppunitTest/starmath_qa_cppunit.test.user -env:CONFIGURATION_LAYERS=xcsxcu:file:///home/melike/libreoffice/instdir/share/registry\ xcsxcu:file:///home/melike/libreoffice/workdir/unittest/registry -env:UNO_TYPES=file:///home/melike/libreoffice/instdir/program/types/offapi.rdb\ file:///home/melike/libreoffice/instdir/program/types.rdb -env:UNO_SERVICES=file:///home/melike/libreoffice/workdir/Rdb/ure/services.rdb\ file:///home/melike/libreoffice/workdir/ComponentTarget/configmgr/source/configmgr.component\ file:///home/melike/libreoffice/workdir/ComponentTarget/dtrans/util/mcnttype.component\ file:///home/melike/libreoffice/workdir/ComponentTarget/framework/util/fwk.component\ file:///home/melike/libreoffice/workdir/ComponentTarget/i18npool/util/i18npool.component\ file:///home/melike/libreoffice/workdir/ComponentTarget/package/source/xstor/xstor.component\ file:///home/melike/libreoffice/workdir/ComponentTarget/package/util/package2.component\ file:///home/melike/libreoffice/workdir/ComponentTarget/toolkit/util/tk.component\ file:///home/melike/libreoffice/workdir/ComponentTarget/sfx2/util/sfx.component\ file:///home/melike/libreoffice/workdir/ComponentTarget/ucb/source/core/ucb1.component\ file:///home/melike/libreoffice/workdir/ComponentTarget/ucb/source/ucp/file/ucpfile1.component\ file:///home/melike/libreoffice/workdir/ComponentTarget/unotools/util/utl.component -env:URE_INTERNAL_LIB_DIR=file:///home/melike/libreoffice/instdir/program -env:LO_LIB_DIR=file:///home/melike/libreoffice/instdir/program -env:LO_JAVA_DIR=file:///home/melike/libreoffice/instdir/program/classes --protector /home/melike/libreoffice/workdir/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector --protector /home/melike/libreoffice/workdir/LinkTarget/Library/unobootstrapprotector.so unobootstrapprotector --protector /home/melike/libreoffice/workdir/LinkTarget/Library/libvclbootstrapprotector.so vclbootstrapprotector -env:CPPUNITTESTTARGET=/home/melike/libreoffice/workdir/CppunitTest/starmath_qa_cppunit.test
warning: File "/home/melike/libreoffice/instdir/program/libuno_sal.so.3-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
    add-auto-load-safe-path /home/melike/libreoffice/instdir/program/libuno_sal.so.3-gdb.py
line to your configuration file "/home/melike/.gdbinit".
To completely disable this security protection add
    set auto-load safe-path /
line to your configuration file "/home/melike/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
    info "(gdb)Auto-loading safe path"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x2aaaac5e5700 (LWP 5036)]
warning: File "/home/melike/libreoffice/instdir/program/libuno_cppu.so.3-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
warning: File "/home/melike/libreoffice/instdir/program/libtllo.so-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
warning: File "/home/melike/libreoffice/instdir/program/libbasegfxlo.so-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
warning: File "/home/melike/libreoffice/instdir/program/libsvllo.so-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
/home/melike/libreoffice/starmath/qa/cppunit/test_nodetotextvisitors.cxx:447:(anonymous namespace)::Test::SimpleOperators
equality assertion failed
- Expected: { int r _ 0 }
- Actual  : int r _ 0
- Upper and lower bounds shown with integral (from & to)

test_nodetotextvisitors.cxx:447:Assertion
Test name: (anonymous namespace)::Test::SimpleOperators
equality assertion failed
- Expected: { int r _ 0 }
- Actual  : int r _ 0
- Upper and lower bounds shown with integral (from & to)

Failures !!!
Run: 21   Failure total: 1   Failures: 1   Errors: 0
[Thread 0x2aaaac5e5700 (LWP 5036) exited]
[Inferior 1 (process 5032) exited with code 01]
......

I have no idea about what I should do.Could you please can you give me your opinion?
Comment 17 Robinson Tryon (qubit) 2015-12-14 07:00:33 UTC
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyInteresting SkillCpp TopicUI)
[NinjaEdit]
Comment 18 Commit Notification 2016-02-10 07:19:31 UTC
melikeyurtoglu committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=746633bd0315939fd5e0b50c90692d356d2ed678

tdf#53472 Integral Symbols too small for some integrands

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 19 Robinson Tryon (qubit) 2016-02-18 14:51:25 UTC
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC)
[NinjaEdit]
Comment 20 jani 2016-04-26 05:56:52 UTC
Seems solved
Comment 21 jani 2016-05-11 14:35:40 UTC
Fix had some errors in it, that caused 2 new bugs, so reverted the commit
Comment 22 Regina Henschel 2016-05-12 10:32:01 UTC
Created attachment 124998 [details]
Collection operators with large body

The attached file contains some test cases. It was last save with version 5.2, which has commit id=746633bd0315939fd5e0b50c90692d356d2ed678 included. So the preview images show the errors.

When you use this file to test a new version, you have to double-click each formula object to refresh it and you have to use "Original size" on the object, to get the correct ratio.
Comment 23 Regina Henschel 2016-05-12 20:33:52 UTC
Please notice, that the attempt "intd" and the attempt by melikeyurtoglu interfere, because the attempt "intd" assumes, that non stretchy integral operators are written as "int".

Both attempts do not consider, that MathML 2.0 is the normative language for  formulas in ODF and therefore the MathML attribute "stretchy" should to be considered.

I don't think, that this problem on the whole is an "easyHack".
Comment 24 Commit Notification 2016-09-29 20:16:40 UTC
Takeshi Abe committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=663e26f24f1fa1abadc37838983bebd7407d65f8

tdf#53472, tdf#102268: Reimplement "intd"

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 25 jani 2016-10-09 10:35:51 UTC
Seems solved