Correction (and marking as critical bug) to the first description:

If such a file is opened in LO 3.5, worked on and saved, the user "WILL" lose correct formatting of the document. This came up in an environment where multiple users are working on the same document and we upgraded some to LO 3.5. There we also spot that LO 3.4 and Winword were correctly working with the file.

I am able to reproduce this issue on OpenOffice 3.3

Without modifying the .doc, I am also seeing the font size of 11 on LibO 3.5, and font size of 12 on LibO 3.4.

Hello, has there been any progress on this bug?

This was still an issue in 3.5.5. I skipped 3.5.6 and went for 3.6 but the issue is still there.
Any news on this matter?

An interesting thing:

at the beginning of each body text paragraph, there is a single Greek word (Του and Των resp.), in Arial like the English text. The Greek words are in 12pt, even when I view the document with LibreOffice 3.5.6.2 and 3.6.1.1, while the English text is in 11pt.

Could this give us a clue about the origin of the problem?


REPRODUCIBLE also on MacOS X:
* LibreOffice 3.4.0:   Main (English) text 12pt
* LibreOffice 3.4.6:   Main (English) text 12pt
* LibreOffice 3.5.6.2: Main (English) text 11pt
* LibreOffice 3.6.1.1: Main (English) text 11pt
* cf. Apache OOo 3.4:  Main (English) text 12pt

=> Regression in 3.5.x, therefore added "regression" keyword.

=> Reproducible not only on Windows, therefore changed Platform to "All".

I'm sorry but I don’t think we should regard this as a "critical" bug (no crash, no big (!) data loss, “only” formatting changed, no flying saucers ;-), so I lower the importance a bit to "major". No offence! This does not mean that this bug is not important -- we need to get it fixed, of course --, it just means that there are even more critical bugs.


I hope this is reproducible on Linux, too -- could someone who uses Linux please bibisect this issue? This would help our developers much to fix this issue. <http://wiki.documentfoundation.org/Bibisect>

Created attachment 65907 [details]
Test file with a second (full english) testing paragraph

Roman,
agreed, no flying saucers :D

However it's annoying to have to fix documents which got corrupted this way....

After you mentioned the two paragraphs starting with Greek words I installed 3.4.6 on a Virtual Machine and opened the initial test.doc of this report again.

I made a copy of the centered Testing header and the paragraph itself, and removed the first Greek word, so we now begin with an English letter.

I am attaching the outcome as test2.doc for further testing.

The strange thing that you'll also see, is that the "Testing" paragraph now is correctly Size 12.
The new "Testing2" paragraph which starts with an English letter is Size 11, except the first letter. The first letter is the result of replacing the small 't' with a capital "T". This letter is actually size 12.

(In reply to comment #8)
> However it's annoying to have to fix documents which got corrupted this way....

I completely agree, and agree that this problem needs to get fixed; as I said, "it just means that there are even more critical bugs."

> The strange thing that you'll also see, is that the "Testing" paragraph now is
> correctly Size 12.

Really strange -- because this paragraph was not changed at all, right?

> The new "Testing2" paragraph which starts with an English letter is Size 11,
> except the first letter. The first letter is the result of replacing the small
> 't' with a capital "T". This letter is actually size 12.

And (just to be sure) this letter is really the Latin capital letter 'T', not a Greek capital letter Tau ('Τ') anymore (I have examinated the file contents with an text editor).


Well, I am not sure what we (QA volunteers( can do more about this bug. It is still a bit mysterious, and I would like to track it down more, but I don’t know what to do. So we can just CC the developers about it and see if someone finds time to investigate further into this issue ...

Or wait a minute -- it is a regression, therefore bibisecting the issue would help the developers a lot to track down this issue. Unfortunately, I can’t do this (bibisecting works best/only on Linux), but maybe someone else can help?

Unfortunately this issue is not bibisectable because it looks like even the oldest version of libreoffice in the bibisect repository (source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932) has this issue.

For future reference, you can always download a VM instance for bibisect on the wiki.

(In reply to comment #11)
> Unfortunately this issue is not bibisectable because it looks like even the
> oldest version of libreoffice in the bibisect repository
> (source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932) has this issue.

Added Whiteboard comments according to this information.

adding myself as QA person so that I can query this one out. Going to try to find someone to tackle this

I'm testing on 3.6.4.3 and 3.7beta2 and it looks like the bug may have been fixed?  Can someone verify one way or another?

Hi, 
it seems to be fixed. 
Thanks! :)

Do we know exactly what fixed it, as it seems to be fixed magically... as magically as it broke. (Just want to be sure it does not break again... ;) )

Marking as RESOLVED - WORKSFORME as we don't know what exactly fixed the issue.


Thanks all