Bug Hunting Session
Bug 62355 - Formula objects with widehat/widevector in Writer have wrong size, top of the hat/vector is cropped
Summary: Formula objects with widehat/widevector in Writer have wrong size, top of the...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Formula Editor (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: low normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 37386 64421 64723 64806 70473 71252 75758 89759 99206 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-03-14 20:57 UTC by Arnaud Versini
Modified: 2017-01-15 10:18 UTC (History)
17 users (show)

See Also:
Crash report or crash signature:


Attachments
A cropped hat (24.54 KB, application/pdf)
2013-03-14 20:57 UTC, Arnaud Versini
Details
sample doc with comb. diacr. (12.29 KB, application/vnd.oasis.opendocument.text)
2013-06-01 10:17 UTC, Yury
Details
Gentium Plus formula "A {tilde A}" with Open Symbol tilde (13.65 KB, image/jpeg)
2013-06-01 10:20 UTC, Yury
Details
Gentium Plus formula "A {tilde A}" with "native" (Gentium Plus) tilde (13.24 KB, image/jpeg)
2013-06-01 10:21 UTC, Yury
Details
bibisect log made by ddorange (233.16 KB, image/png)
2014-01-05 07:41 UTC, Dorange-Pattoret Didier
Details
Made with LO 4.2 RC1 under OpenMandriva (5.24 KB, image/png)
2014-01-05 07:50 UTC, Dorange-Pattoret Didier
Details
OSX_libo_4.0.4 (83.22 KB, image/png)
2014-01-07 21:37 UTC, William Gathoye
Details
ArchLinux_libo_4.1.4 (93.23 KB, image/png)
2014-01-07 21:38 UTC, William Gathoye
Details
With LO 4.1.3 and AOOo 4.0.1 (Ubuntu). (24.41 KB, image/png)
2014-01-15 21:18 UTC, Dorange-Pattoret Didier
Details
Sorry the last was wrong (25.09 KB, image/png)
2014-01-15 21:28 UTC, Dorange-Pattoret Didier
Details
Win7 and LO 4.2 RC 2 (13.97 KB, image/png)
2014-01-15 21:37 UTC, Dorange-Pattoret Didier
Details
widehat {a + {b + c} over {a}} formula PDF (Linux) (9.14 KB, application/pdf)
2014-01-20 12:49 UTC, Pierre-Eric Pelloux-Prayer
Details
With LO (3.00 KB, image/png)
2014-02-23 18:20 UTC, Dorange-Pattoret Didier
Details
With AOOo 4.0.1 (3.24 KB, image/png)
2014-02-23 18:21 UTC, Dorange-Pattoret Didier
Details
screencopy OK for widehat, KO for widevector (3.42 KB, image/png)
2014-02-23 20:12 UTC, Jean-Baptiste Faure
Details
Documents and images about comment #53 tests (213.12 KB, application/zip)
2014-05-07 08:34 UTC, Enrique
Details
vec F & widevec AB (3.05 KB, image/png)
2017-01-15 09:29 UTC, Franck Larrivé
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arnaud Versini 2013-03-14 20:57:16 UTC
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
Comment 1 Szuhánszky Tamás 2013-04-05 09:23:23 UTC
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.
Comment 2 Joel Madero 2013-04-15 04:15:50 UTC
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
Comment 3 Jorendc 2013-05-10 11:38:51 UTC
*** Bug 64421 has been marked as a duplicate of this bug. ***
Comment 4 Jorendc 2013-05-10 11:58:18 UTC
*** Bug 37386 has been marked as a duplicate of this bug. ***
Comment 5 Jorendc 2013-05-18 16:37:56 UTC
*** Bug 64723 has been marked as a duplicate of this bug. ***
Comment 6 Jorendc 2013-05-21 05:58:11 UTC
*** Bug 64806 has been marked as a duplicate of this bug. ***
Comment 7 Jorendc 2013-05-23 14:56:12 UTC
(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 :-)
Comment 8 Yury 2013-06-01 10:10:30 UTC
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).
Comment 9 Yury 2013-06-01 10:16:02 UTC
> 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.
Comment 10 Yury 2013-06-01 10:17:30 UTC
Created attachment 80119 [details]
sample doc with comb. diacr.
Comment 11 Yury 2013-06-01 10:20:42 UTC
Created attachment 80121 [details]
Gentium Plus formula "A {tilde A}" with Open Symbol tilde
Comment 12 Yury 2013-06-01 10:21:12 UTC
Created attachment 80122 [details]
Gentium Plus formula "A {tilde A}" with "native" (Gentium Plus) tilde
Comment 13 Yury 2013-06-01 14:04:53 UTC
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.
Comment 14 Jorendc 2013-10-15 19:49:14 UTC
*** Bug 70473 has been marked as a duplicate of this bug. ***
Comment 15 Dorange-Pattoret Didier 2014-01-05 07:41:17 UTC
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
Comment 16 Dorange-Pattoret Didier 2014-01-05 07:50:45 UTC
Created attachment 91512 [details]
Made with LO 4.2 RC1 under OpenMandriva
Comment 17 Dorange-Pattoret Didier 2014-01-05 07:52:17 UTC
The bug is always here.
I attached a snapshot of bibisection.
I hope it could help you to fix this bug.
Thanks.
Comment 18 William Gathoye 2014-01-07 21:37:46 UTC
Created attachment 91616 [details]
OSX_libo_4.0.4
Comment 19 William Gathoye 2014-01-07 21:38:26 UTC
Created attachment 91617 [details]
ArchLinux_libo_4.1.4
Comment 20 William Gathoye 2014-01-07 21:38:38 UTC
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.
Comment 21 Dorange-Pattoret Didier 2014-01-08 13:46:04 UTC
I agree with this idea : it's only a gnu/linux bug !
Comment 22 Arnaud Versini 2014-01-11 13:09:03 UTC
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.
Comment 23 Arnaud Versini 2014-01-12 11:32:22 UTC
@Didier, I used the oldest version of the bibisect repo and doesn't work for me, sorry.
Comment 24 Arnaud Versini 2014-01-15 20:27:39 UTC
@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.
Comment 25 Joel Madero 2014-01-15 20:37:41 UTC
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
Comment 26 Joel Madero 2014-01-15 20:40:17 UTC
@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?
Comment 27 Christophe Devalland 2014-01-15 20:41:59 UTC
I agree. It's probably an inherited bug from OOo.
Comment 28 Dorange-Pattoret Didier 2014-01-15 20:44:22 UTC
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}} ?
Comment 29 Christophe Devalland 2014-01-15 20:48:08 UTC
it's a linux bug only, isn't it ?
Comment 30 Dorange-Pattoret Didier 2014-01-15 20:50:42 UTC
(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 ...
Comment 31 Dorange-Pattoret Didier 2014-01-15 20:53:04 UTC
(In reply to comment #29)
> it's a linux bug only, isn't it ?

Yes see my last comments.
Comment 32 Christophe Devalland 2014-01-15 20:56:33 UTC
@Didier : but this problem occurs in AOO too !
Comment 33 Dorange-Pattoret Didier 2014-01-15 21:18:02 UTC
Created attachment 92180 [details]
With LO 4.1.3 and AOOo 4.0.1 (Ubuntu).
Comment 34 Christophe Devalland 2014-01-15 21:19:53 UTC
(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 ?
Comment 35 Dorange-Pattoret Didier 2014-01-15 21:28:42 UTC
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 36 Dorange-Pattoret Didier 2014-01-15 21:30:24 UTC
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 ?
Comment 37 Joel Madero 2014-01-15 21:35:29 UTC
I'm comfortable to saying this is inherited with these comments, again updating version
Comment 38 Dorange-Pattoret Didier 2014-01-15 21:37:13 UTC
Created attachment 92183 [details]
Win7 and LO 4.2 RC 2

Widehat is right but borderline are crazy ....
Comment 39 Dorange-Pattoret Didier 2014-01-19 19:25:27 UTC
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 ?
Comment 40 Joel Madero 2014-01-19 19:55:10 UTC
Unfortunately there is no older bibisect
Comment 41 Arnaud Versini 2014-01-19 19:58:40 UTC
Perhaps you can download older version of OpenOffice.org to see if it is inherited
Comment 42 Dorange-Pattoret Didier 2014-01-19 21:35:51 UTC
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 !
Comment 43 Dorange-Pattoret Didier 2014-01-20 06:59:01 UTC
Hello,
The bug is not present on Libreoffice 4.2 RC 2 running with Mac OS.
So it a real only Linux bug.
Comment 44 Pierre-Eric Pelloux-Prayer 2014-01-20 12:49:25 UTC
Created attachment 92447 [details]
widehat {a + {b + c} over {a}} formula PDF (Linux)

Bug is not present using git master (04a7ac6f062e9296eb643180cf54345bcdb260c4) version on Linux.
Comment 45 Dorange-Pattoret Didier 2014-02-23 18:20:47 UTC
Created attachment 94612 [details]
With LO
Comment 46 Dorange-Pattoret Didier 2014-02-23 18:21:29 UTC
Created attachment 94613 [details]
With AOOo 4.0.1
Comment 47 Jean-Baptiste Faure 2014-02-23 20:12:03 UTC
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
Comment 48 Jean-Baptiste Faure 2014-03-01 14:26:06 UTC
*** Bug 71252 has been marked as a duplicate of this bug. ***
Comment 49 Jean-Baptiste Faure 2014-03-08 22:38:36 UTC
*** Bug 75758 has been marked as a duplicate of this bug. ***
Comment 50 Enrique 2014-05-06 23:07:22 UTC
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.
Comment 51 Joel Madero 2014-05-07 04:22:23 UTC
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
Comment 52 Dorange-Pattoret Didier 2014-05-07 05:31:29 UTC
This issue does not appear on AOO 4.0 and AOO 4.1
Comment 53 Enrique 2014-05-07 08:31:19 UTC
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 ...
Comment 54 Enrique 2014-05-07 08:34:46 UTC
Created attachment 98604 [details]
Documents and images about comment #53 tests

Documents and images about comment #53 tests
Comment 55 Joel Madero 2014-09-08 16:18:59 UTC
Removing whiteboard status - that's not the correct place to write full sentences.
Comment 56 Gaborit Jean-Luc 2014-09-08 17:35:25 UTC
 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
Comment 57 Owen Genat (retired) 2015-03-14 00:42:59 UTC
According to comment 8 and comment 9 this may be a duplicate of bug 37016.
Comment 58 Enrique 2015-03-14 12:36:43 UTC
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
Comment 59 mehmet337402 2015-04-25 17:12:01 UTC
I have the same issue. My os: Linux Mint 17.1 Mate. Libreoffice 4.2.72
Comment 60 Yury 2015-04-26 07:17:56 UTC
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.
Comment 61 Yury 2015-04-26 07:19:34 UTC
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).
Comment 62 Enrique 2015-04-26 17:27:55 UTC
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
Comment 63 Owen Genat (retired) 2015-04-26 21:52:51 UTC
Bug 37016 added to See Also list.
Comment 64 Yury 2015-04-27 08:12:24 UTC
(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.
Comment 65 mehmet337402 2015-05-23 11:04:45 UTC
This problem still continues. LibreOffice 5.0.0.0.beta1 on Linux Mint 17.1
Comment 66 mehmet337402 2015-05-26 16:31:26 UTC
*** Bug 89759 has been marked as a duplicate of this bug. ***
Comment 67 Dorange-Pattoret Didier 2015-12-22 07:19:15 UTC
The bug is still here. LO 5.0.4
Comment 68 heterea 2016-04-07 23:25:27 UTC
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
Comment 69 Joel Madero 2016-04-11 00:02:27 UTC
*** Bug 99206 has been marked as a duplicate of this bug. ***
Comment 70 Element Green 2016-09-11 00:05:39 UTC
Still occurring on Ubuntu 16.04 with LibreOffice 5.2.1.2 with vec and widevec.
Comment 71 mehmet337402 2016-10-25 19:16:26 UTC
I use LinuxMint 18 x86_64. LibreOffice Sürüm: 5.1.4.2
Problem completely solved.
Comment 72 Jean-Baptiste Faure 2016-10-25 20:06:33 UTC
(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
Comment 73 Franck Larrivé 2017-01-15 09:29:22 UTC
Created attachment 130448 [details]
vec F & widevec AB
Comment 74 Franck Larrivé 2017-01-15 09:35:38 UTC
Comment on attachment 130448 [details]
vec F & widevec AB

still KO for vec & widevec with LO 5.2.4.rc2 on Ubuntu 16.04
Comment 75 Franck Larrivé 2017-01-15 09:36:58 UTC Comment hidden (obsolete)
Comment 76 Franck Larrivé 2017-01-15 09:40:33 UTC Comment hidden (obsolete)
Comment 77 Franck Larrivé 2017-01-15 09:41:52 UTC Comment hidden (obsolete)
Comment 78 Franck Larrivé 2017-01-15 09:43:02 UTC Comment hidden (obsolete)
Comment 79 Ruslan Kabatsayev 2017-01-15 09:46:46 UTC
(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?
Comment 80 Franck Larrivé 2017-01-15 09:48:03 UTC
Comment on attachment 130448 [details]
vec F & widevec AB

still KO for vec & widevec with LO 5.2.4.rc2 on Ubuntu 16.04
Comment 81 Franck Larrivé 2017-01-15 10:14:07 UTC
(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"
Comment 82 Ruslan Kabatsayev 2017-01-15 10:18:28 UTC
(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.