Created attachment 76540 [details] A cropped hat Hello Formula objects seems to have the wring size in objects with a wide-hat, the up of the hat is cropped Procedure to reproduce : Create a writer document Add a formula Type this formula : widehat {a + {b + c} over {a}} Return to Writer Result : The hat is cropped like the PDF in PJ Expected behavior : A good looking hat
Hi! I have tried it in a lot of version (4.x and 3.6) under Windows 7, and experienced that the hat is flat, i don't know what you mean under "cropped" sorry, but as you said it's not a good looking hat. So know we are waiting for someone who can judge this report correctly.
Thank you for reporting this issue! I have been able to confirm the issue on: Version 3.6.5.2 Platform: Bodhi Linux 2.2 x64 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + As I've been able to confirm this problem on an earlier release I am changing the version number as version is the earliest version that we can confirm the bug, we use comments to say that the bug exists in newer versions as well. Marking as: New (confirmed) Normal - prevents high quality/professional quality work Low - not very common feature to insert formula to begin with, also this is one thing within formula (widehat) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 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
*** Bug 64421 has been marked as a duplicate of this bug. ***
*** Bug 37386 has been marked as a duplicate of this bug. ***
*** Bug 64723 has been marked as a duplicate of this bug. ***
*** Bug 64806 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > As I've been able to confirm this problem on an earlier release I am > changing the version number as version is the earliest version that we can > confirm the bug, -> done now :-)
Even the simplest use of combining diacritics like {hat A} or {tilde A} *by means of formula editor "catalog"* might go wrong. The BIG problem is glyphs accessed via "catalog" (tilde, hat etc.) are taken from the "Open Symbol" face, included in LibO out-of-the-box (at least on Linux). And so, certain combinations of glyph heights of body text face and "Open Symbol" diacritics just go wrong. E.g., "Open Symbol" diacritics combine well with "Gentium Plus" capitals, but no so well with "Linux Libertine O" capitals. So not every font face is actually usable in Formula Editor! IF one changes the "catalog" face from "Open Symbol" to something else (in Tools->Options->Fonts dialog), one is not out of the woods yet. There is another, related problem, which *probably* merits another ticket: formula renderer assumes (?) the combining diacritics in the "catalog" face do not actually combine. Or something. The fact is some combinations of faces are rendered with diacritics far to the left of the glyph over which it ought to be placed. I'm attaching the sample doc, all set in "Gentium Plus", and TWO screenshots, rendered (1) with font substitution "Open Symbol->Gentium Plus" AND (2) without such substitution. The doc contains: (1) plain text "A {tilde A}" equivalent (shows the correct tilde placement); (2.1) formula "A {tilde A}", with "Gentium Plus" tilde (not so correct placement); (2.2) same formula with "Open Symbol" tilde (not correct at all).
> I'm attaching the sample doc, all set in "Gentium Plus", and TWO > screenshots, rendered (1) with font substitution "Open Symbol->Gentium Plus" > AND (2) without such substitution. > The doc contains: (1) plain text "A {tilde A}" equivalent (shows the correct > tilde placement); (2.1) formula "A {tilde A}", with "Gentium Plus" tilde > (not so correct placement); (2.2) same formula with "Open Symbol" tilde (not > correct at all). Sorry, got confused -- it's Open Symbol diacritics which's placed not so correct, but native which is thrown to the left.
Created attachment 80119 [details] sample doc with comb. diacr.
Created attachment 80121 [details] Gentium Plus formula "A {tilde A}" with Open Symbol tilde
Created attachment 80122 [details] Gentium Plus formula "A {tilde A}" with "native" (Gentium Plus) tilde
As far as I understand, the problem is caused by renderer not reserving enough space on top of the glyph. For some font faces this is okay anyway, and for some faces this produces cropping. As a workaround of sorts, I'd suggest adding "^{}" in every formula. Helps with the problematic font faces I'm using. As a solution I'd suggest make renderer reserve space for "^{}" equivalent in all cases.
*** Bug 70473 has been marked as a duplicate of this bug. ***
Created attachment 91511 [details] bibisect log made by ddorange It was made with the file http://mirror3.layerjet.com/libreoffice-qa/bibisect-4.0.tar.xz
Created attachment 91512 [details] Made with LO 4.2 RC1 under OpenMandriva
The bug is always here. I attached a snapshot of bibisection. I hope it could help you to fix this bug. Thanks.
Created attachment 91616 [details] OSX_libo_4.0.4
Created attachment 91617 [details] ArchLinux_libo_4.1.4
Arnaud Versini and me haven't succeeded to reproduce this bug on Windows 8.1 using LibO 3.6.5, 4.0.2 and 4.2 (2014-01-07 7:32:09), and on OS X Moutain Lion using LibO 4.0.4. It seems like it is a GNU/Linux-only bug. See screenshots for OS X with 4.0.4 and ArchLinux 4.1.4.
I agree with this idea : it's only a gnu/linux bug !
I'm trying to bisect with source bisect. @Didier , seems for me that commit http://cgit.freedesktop.org/libreoffice/core/commit/?id=15af925c254f27046427de70a59011e2ac3d6bdb have the issue for me. I need to check your bisect.
@Didier, I used the oldest version of the bibisect repo and doesn't work for me, sorry.
@Didier, did you use this exact formula ? widehat {a + {b + c} over {a}} As for me all versions doesn't work correctly, not a regression for me.
I cannot confirm that bibisect - I went all the way back to 3.5beta0 and the problem was even worse back then. Updating version to reflect this...almost undoubtedly an inherited bug from OOo
@Michael - curious if you're interested in this one. Don't want to add it to MAB but quite a few dupes and *perhaps* an easy one to resolve?
I agree. It's probably an inherited bug from OOo.
I tried tonight with this exact formula widehat {a + {b + c} over {a}}. I get the bug with LO 4.1.3.2 under Ubuntu and I do'nt get it with LO 4.2 RC 2 under Win7. If necessary I could try a new bibisection with exactly widehat {a + {b + c} over {a}} ?
it's a linux bug only, isn't it ?
(In reply to comment #27) > I agree. It's probably an inherited bug from OOo. I do'nt. My bibisection (https://bugs.freedesktop.org/attachment.cgi?id=91511) was made with an LO 4.0 archive (http://mirror3.layerjet.com/libreoffice-qa/bibisect-4.0.tar.xz). The bug comes in latest not in oldest ...
(In reply to comment #29) > it's a linux bug only, isn't it ? Yes see my last comments.
@Didier : but this problem occurs in AOO too !
Created attachment 92180 [details] With LO 4.1.3 and AOOo 4.0.1 (Ubuntu).
(In reply to comment #33) > Created attachment 92180 [details] > With LO 4.1.3 and AOOo 4.0.1 (Ubuntu). Could you try with the same font in AOO ?
Created attachment 92181 [details] Sorry the last was wrong Sorry but the last capture was wrong. This was made with LO 4.1.3 and Aoo 4.1 Ubuntu Times New Roman 12.
Comment on attachment 92181 [details] Sorry the last was wrong It seems that the bug do'nt give the same view or it's not exactly the same bug ?
I'm comfortable to saying this is inherited with these comments, again updating version
Created attachment 92183 [details] Win7 and LO 4.2 RC 2 Widehat is right but borderline are crazy ....
I tried tonight a bisection with this formula widehat {a + {b + c} over {a}} and the archive http://mirror3.layerjet.com/libreoffice-qa/bibisect-4.0.tar.xz And the bug is present in the oldest revision. It seems inherited from OOo. I would like to make a bisection with an oldest archive (3.5). Can I found it ?
Unfortunately there is no older bibisect
Perhaps you can download older version of OpenOffice.org to see if it is inherited
I downloaded old versions of OpenOffice.org and Ubuntu 13.10 The bug is not present in OOo 3.2.1 but comes with OOo 3.3 I hope it will help you !
Hello, The bug is not present on Libreoffice 4.2 RC 2 running with Mac OS. So it a real only Linux bug.
Created attachment 92447 [details] widehat {a + {b + c} over {a}} formula PDF (Linux) Bug is not present using git master (04a7ac6f062e9296eb643180cf54345bcdb260c4) version on Linux.
Created attachment 94612 [details] With LO
Created attachment 94613 [details] With AOOo 4.0.1
Created attachment 94619 [details] screencopy OK for widehat, KO for widevector (In reply to comment #44) > Created attachment 92447 [details] > widehat {a + {b + c} over {a}} formula PDF (Linux) > > Bug is not present using git master > (04a7ac6f062e9296eb643180cf54345bcdb260c4) version on Linux. For me in LO 4.2.3.0.0+ (Build ID: 5fd90cdd1fdb20ab7f6a2b67c384f0994f09a86b) under Ubuntu 13.10 x86-64 : - not present anymore for widehat - still there for widevector Best regards. JBF
*** Bug 71252 has been marked as a duplicate of this bug. ***
*** Bug 75758 has been marked as a duplicate of this bug. ***
As title just mentions widehat/widevector, I just want to confirm it also happens with "vec" in something so simple like that, Newton's second law: vec F = m vec a which shows no vector arrow over F This is important for documents with physics formulas As a dirty workaround: size 14 " " vec F = m vec a at least shows vector arrow over F I am using ubuntu 14.04 64 bits, and I can confirm it does not work in 4.2.3.3 but it was working some time ago with previous LibreOffice versions.
Can someone check to see if it worked with our earliest release? http://downloadarchive.documentfoundation.org/libreoffice/old/ would be nice to know if this is a regression
This issue does not appear on AOO 4.0 and AOO 4.1
Tested with http://downloadarchive.documentfoundation.org/libreoffice/old/3.3.0.4/deb/x86_64/LibO_3.3.0_Linux_x86-64_install-deb_en-US.tar.gz with ubuntu 14.04 64 bits Some installation messages Configurando libreoffice3-dict-es (3.3.0-19) ... javaldx: Could not find a Java Runtime Environment! despite I have java -version java version "1.7.0_55" Java(TM) SE Runtime Environment (build 1.7.0_55-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode) but it works running /opt/libreoffice/program$ ./swriter Some tests and results (I will add them as attachments), it is hard to explain: LO3.3: Created document "2014-05-07-Bug62355Test-Created-Lo3.odt" Result: 2014-05-07-LibreOffice3-FormulaTest.jpg - KO: widehat, circle, widetilde - OK: vec, widevec, overline - formula color is "grey" LO4.2: Opening document created from LO3: Result: the same as LO3.3 2014-05-07-LibreOffice4.2-FormulaTest-DocumentNotModified.jpg BUT!!!!! ... just clicking in the formulas, without any modification on them: Result: 2014-05-07-LibreOffice4.2-FormulaTest-DocumentModified.jpg - KO: vec, widevec, overline - OK: widehat, circle, widetilde - formula color is "black" Almost "opposite result"!? (just overline work in both, as it seems the height of the line is not enough to be cropped) Just to check, "modification" from LO4.2 saved as new document 2014-05-07-Bug62355Test-Modified-Lo4.2.odt and opening again with LO3.3.... 2014-05-07-LibreOffice3-FormulaTest-DocumentModifiedFrom4.2.jpg Result: the same as LO4.2 when saved BUT .... :-) just clicking in the formulas, without any modification on them... result come back to original LO3.3 behavoir, again vec OK, and again gray color ...
Created attachment 98604 [details] Documents and images about comment #53 tests Documents and images about comment #53 tests
Removing whiteboard status - that's not the correct place to write full sentences.
I reproduce this bug on: LO Version: 4.3.1.2 Build ID: 958349dc3b25111dbca392fbc281a05559ef6848 Windows 7 Edition Familliale Premium Service Pack1 I change Platform: Linux to All
According to comment 8 and comment 9 this may be a duplicate of bug 37016.
Tested again with testfile in comment#53 and Version: 4.4.3.0.0+ Build ID: 8106e522c4ea2ae4441ec571579a38eeb6d9af04 TinderBox: Linux-rpm_deb-x86_64@46-TDF Result: still not working ok with something so simple like "vec F = m vec a" About comment#57, I think it may be related, but it is not duplicate Indeed Bug37106 suggest a workaround not valid with vec %itheta^{{" "}a} Just tested vec F ^" " = m vec a Result: vector over F dissapears, because vector arrow is too high It can be checked with size 20 " " vec F ^" " = m vec a Result: vector over F appears
I have the same issue. My os: Linux Mint 17.1 Mate. Libreoffice 4.2.72
For things like this: vec F ^" " = m vec a the working workaround is: vec F ^{} = m vec a You may hit other issues when using the ^{}, _{}, and their variations, though -- like baseline shifting #65229.
It all depends on combination of fonts (set in formula properties + what goes as/instead of OpenSymbol) and the metrics of the surrounding text area (formula frame dimensions).
About Comment#60: The problem is not with vec F ^" " = m vec a but just with vec F = m vec a (I can confirm that with previous formula, vector over F is cropped, with last version Version: 4.4.4.0.0+ Build ID: 3717ee4bdc059fe2ed912efde20fd0c965b3fca3 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-4, Time: 2015-04-25_07:55:14 Locale: es_ES ) In comment#58 I used ^" " just to check that comment#57 may be related, but it is not duplicate I tested in latest version your workaround vec F ^{} = m vec a and it works; vector over F is not cropped, thanks! About Comment#61 ¿where do I set fonts in formula properties? Anyway, I think it should be revised what I tested in comment#53: vector over F is cropped or not depending of the version used to save the file ... and it begins to be cropped or not after editing the formula
Bug 37016 added to See Also list.
(In reply to Enrique from comment #62) > Anyway, I think it should be revised what I tested in comment#53: vector > over F is cropped or not depending of the version used to save the file ... > and it begins to be cropped or not after editing the formula The amount of vertical whitespace used for the formula rendering (reflecting, likely, the algorithm used) began to differ from version to version in the 4.3 series, which were being released in the opening months of 2015. You may look into my apropos comments in #88139. First, formulas were 'squeezed'/distorted vertically, then there appeared an inordinate number of whitespace (but no distortion), then the extra whitespace got reduced, then it got reduced a bit more. In the 4.3.7.2 we seem to have a working solution for this, for a moment.
This problem still continues. LibreOffice 5.0.0.0.beta1 on Linux Mint 17.1
*** Bug 89759 has been marked as a duplicate of this bug. ***
The bug is still here. LO 5.0.4
LibreOffice 5.1.0.3, Windows 7 x64 widevec is shown with the arrow tip proportional to the width of the content, making it unrecognizable when it is "too large" http://i.imgur.com/5WDCSWF.png
*** Bug 99206 has been marked as a duplicate of this bug. ***
Still occurring on Ubuntu 16.04 with LibreOffice 5.2.1.2 with vec and widevec.
I use LinuxMint 18 x86_64. LibreOffice Sürüm: 5.1.4.2 Problem completely solved.
(In reply to mehmet337402 from comment #71) > I use LinuxMint 18 x86_64. LibreOffice Sürüm: 5.1.4.2 > Problem completely solved. As we do not have a commit, the correct status is WorksForMe. That said comment #70 confirmed that the bug still occur in 5.2.1. Anyway setting as WFM, please feel free to reopen if you still encounter this bug. Best regards. JBF
Created attachment 130448 [details] vec F & widevec AB
Comment on attachment 130448 [details] vec F & widevec AB still KO for vec & widevec with LO 5.2.4.rc2 on Ubuntu 16.04
(In reply to Franck Larrivé from comment #78) > Comment on attachment 130448 [details] > vec F & widevec AB > > still KO for vec & widevec with LO 5.2.4.rc2 on Ubuntu 16.04 Hey, why so many repetitions?
(In reply to Ruslan Kabatsayev from comment #79) > (In reply to Franck Larrivé from comment #78) > > Comment on attachment 130448 [details] > > vec F & widevec AB > > > > still KO for vec & widevec with LO 5.2.4.rc2 on Ubuntu 16.04 > > Hey, why so many repetitions? Sorry for that, every time I publish the comment by "submit" I get a "504 gateway time-out"
(In reply to Franck Larrivé from comment #81) > every time I publish the comment by "submit" I get a "504 gateway time-out" Right, I also get it. But it seems to only be related to downloading of the page after submission — the submission itself appears to be successful.