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
Still a problem in master e4080dc (1 Oct, 16.50) Confirming.
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.
Created attachment 69690 [details] Change in the SmOperNode::Arrange
Created attachment 69692 [details] before in hxx file
Created attachment 69693 [details] after hxx-file
Created attachment 69694 [details] int-sum-prod
(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.
(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
Created attachment 70305 [details] Size of the Sum,Prod,Int Symbol
(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.
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
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
(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.
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
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.
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?
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyInteresting SkillCpp TopicUI) [NinjaEdit]
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.
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC) [NinjaEdit]
Seems solved
Fix had some errors in it, that caused 2 new bugs, so reverted the commit
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.
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".
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.