Created attachment 84336 [details] The file demo the different formating results between Libreoffice 4.0 and 4.1 Problem description: I found there may be a problem of compatiblity about Libreoffice 4.0 and 4.1 . Some odt format results that edited in Libreoffice 4.0 Writer will "offset" when I reopen it with Libreoffice 4.1 Writer. Steps to reproduce: 1. Download the attachment "offset.odt" 2. Open offset.odt with Libreoffice 4.0, you will see the distance between bottom line and star is small. 3. Open offset.odt with Libreoffice 4.1, you will see there is a big gap between the bottom line and star. Current behavior: The same odt file has different formating results when I open with Libreoffice 4.1 (compared to Libreoffice 4.0). Expected behavior: The same odt file has the same formating results between different Libreoffice versions. Operating System: Debian Version: 4.1.0.4 release
Created attachment 84338 [details] This file show the formating result of Libreoffice 4.0
Created attachment 84340 [details] This file show the formating result of Libreoffice 4.1 Please take a look at the end of page 2 of the both pdf files. The end of Output_4.1.pdf, there is a large gap between the bottom line and stars (compared to the end of file output_4.0.pdf)
Created attachment 84341 [details] The screenshot to show this problem.
tested with 4.0.4.2 and 4.1.0.4 under Win7 64bit sorry but I see no difference in the demo file look using those 2 different version. I see different offset at the bottom of the star lines between page 1 and page 2 in both version, but again what I see in 4.0.4 is the same in 4.1.0 am I missing something or did you upload the wrong test file?
Hi tommy27: Please install a chinese truetype font "fonts-cwtex-heib" to show this problem. If you are using Debian/Ubuntu, you can install it by following command: apt-get install fonts-cwtex-heib Or you can download it from here: http://ftp.twaren.net/local-distfiles/tex/xetex/fonts/cwheib.ttf Restart Libreoffice after you installed this font, you will see this problem. Note: The Libreoffice version I have tested are 4.0.3, 4.1.0 and 4.1.1 Thanks for your help.
Installed font. Again no difference between 4.0.4 and 4.1.0 under Win7 64bit. Another Linux tester needed.
I also suggest to try reducing the test document to the minimum version that can reproduce the big on your system. I mean try to reduce it to a single page and rid of as many element as possible... the less things it has the higher chances to identify what causes the problem
I tested this problem on WinXP (32 bit). There is no difference between 3.4.6 and 4.1.0. (just like tommy27 said). I guess this problem happens only under Linux (I test it under Debian, jessie , 32bit).
Created attachment 84578 [details] The simple document to show this problem (In reply to comment #7) > I also suggest to try reducing the test document to the minimum version that > can reproduce the big on your system. > > I mean try to reduce it to a single page and rid of as many element as > possible... > > the less things it has the higher chances to identify what causes the problem Tommy: Thanks for your suggestion. I uploaded "offset_20130825.zip" to simplify this problem. I think this is a problem of "Table". You can see the height of table has slight different between "offset5-4.0.3.pdf" and "offset5-4.1.1.pdf". The table has smaller height in Libreoffice 4.1 ( compared to Libreoffice 4.0) . Thus the "offset5.odt" has only one page in Libreoffice 4.1 , but it has 2 pages when it was opened in Libreoffice 4.0.
still no difference with minimal test case on Win7 64bit.
Created attachment 84823 [details] The result of Apache openoffice 4.0 I test this problem with Apache Openoffice 4.0 under Linux. I found the result of Apache Openoffice 4.0 was the same with Libreoffice 4.0. There must be something wrong in Libreoffice 4.1 under Linux.
On Fedora 19 and LibreOffice 4.1.1.2 (Build ID 4.1.1.2-3.fc19), the offset5.odt is 2 pages long, before installing the chinese font you provided as well as after installing it. The second page consists of 5 full lines of stars and a sixth line with 10 stars
Thomas Pulzer: Your result on Fedora (Libreoffice 4.1.1) was different from my result on Debian(Libreoffice 4.1.1), my result has only one page. I am surprised that the same odt file will look different when it opened with different Linux system. And your result was different from mine that opened with Libreoffice 4.0.3 (Debian). By the way, does offset5.odt looks different when comparing the result of Libreoffice 4.0 and Libroffice 4.1 on your Fedora? Thank you~
Are you sure that your compatibility options are the same for LO 4.0 and LO 4.1 ? Compatibility options are defined in menu Tools > Options > LibreOffice Writer > Compatibility. I am not sure if making test files with only stars is a good idea because you create a text with only one very long word without any space. It is not representative of a real text. I suggest you to use a Lorem Ipsum text or a real text. Best regards. JBF
Created attachment 86448 [details] The file to show different table height in LO 4.0 and LO 4.1
Created attachment 86450 [details] Pdf file offset6.odt exported from LO 4.0.3
Created attachment 86451 [details] Pdf file of offset6.odt exported from LO 4.1.1
Jean-Baptiste Faure : Hi~ I checked the settings "Tools > Options > LibreOffice Writer > Compatibility", it's the same in LO 4.0.3 and 4.1.1. I guess the problem is that the same table will show different height in LO 4.0 and LO 4.1 (Linux only, it's OK on Windows so far). So I deleted all the star, and add some rows of table, and change all the font to "Liberation Sans". I rename this new testing odt file as offset6.odt, please download it here: https://bugs.freedesktop.org/attachment.cgi?id=86448 My testing result was: The table in LO-4.0.3 goes to second page: https://bugs.freedesktop.org/attachment.cgi?id=86450 The table in LO-4.1.1 has only one page: https://bugs.freedesktop.org/attachment.cgi?id=86451 Thank you
I tested your file both with LO 4.0.5 (TDF build) and LO 4.1.3.0.0+ (build at home) under Ubuntu 13.04 x86-64. Strangely LO says that the font used is "cwTeX 粗黑體", not Liberation Sans. Anyway, even if I change the font to Liberation Sans, both versions give me the same layout: 2 pages, the second having the last 8 rows of the table. The master give me the same layout. It seems that this bug is in your distribution version only. If you can install upstream LO version, you can verify yourself this hypothesis. Best regards. JBF
Jean-Baptiste Faure： Hi, I downloaded rpm version (4.1.1.2), and install on my Debian(x86, 32bit). This table height problem still exist, table in offset6.odt has only one page. May be this problem happens only on 32bit version, Would anybody test 32bit version of Libreoffice? Thank you. Best Regards, Minhsien0330
minhsien0330: On a fresh installed Fedora 19 with recent updates (20130926) and additional installed LO 4.0.5.2 with your latest template (offset6.odt) following behavior occured: Before the installation of the font you provided, both version span the document over two pages. After the installation of said font, LO 4.0.5.2 displays a two-paged document, whereas LO 4.1.1.2 does display two pages of the document, but the table fills only the first page. Strange about is, that in LO 4.1.1.2 the font shows as "not installed" in the font picker. Compatibility settings are the same for both program versions. From my point of view, this is a bug earning the status 'confirmed'.
Created attachment 86637 [details] Screenshot of offset6.odt in LO 4.0.5.2 Screenshot for Comment #21, showing the behavior of LO 4.0.5.2
Created attachment 86638 [details] Screenshot of offset6.odt in LO 4.1.1.2 Screenshot for Comment #21, showing the behavior of LO 4.1.1.2
(In reply to comment #21) > minhsien0330: > On a fresh installed Fedora 19 with recent updates (20130926) and additional > installed LO 4.0.5.2 with your latest template (offset6.odt) following > behavior occured: > > Before the installation of the font you provided, both version span the > document over two pages. > > After the installation of said font, LO 4.0.5.2 displays a two-paged > document, whereas LO 4.1.1.2 does display two pages of the document, but the > table fills only the first page. Strange about is, that in LO 4.1.1.2 the > font shows as "not installed" in the font picker. > > Compatibility settings are the same for both program versions. > > From my point of view, this is a bug earning the status 'confirmed'. I did not notice, that you changed the font to Liberation Sans. So, I'm curious, why the .odt thinks, it's still "cwTeX 粗黑體". That could explain the strange behavior after installing this font.
Created attachment 86643 [details] offset7.odt > I did not notice, that you changed the font to Liberation Sans. So, I'm > curious, why the .odt thinks, it's still "cwTeX 粗黑體". That could explain the > strange behavior after installing this font. Because I change it by "Ctrl+A --> mouse click " Liberation Sans " on the font list", this behavior change the "Asian text font" only, but the "Western text font" remains "cwTeX 粗黑體". Please click "Format --> Character --> Font", you will know what I mean. You are right! After change both "Western text font" and "Asian text font" to "Liberation Sans"(just as offset7.odt), LO 4.0 and 4.1 have the same formatting result!!! Regards, Minhsien0330
Created attachment 86644 [details] offset7-4.0.3.pdf
Created attachment 86646 [details] offset7-4.1.1.pdf
Dear Thomas Pulzer： Would you change the "Status" of this bug to "New"? Thank you!
Dear all: Umm..., Would anybody change the "Status" to "New" please? Or ... can I change it by myself?
Ok. set status to new because of independent confirmations in previous comments
I see the same problem on Windows 7, so setting Platform to all. The reason for the different layout is this: In Tools > Options > Compatibility you can set some options. Those should be saved together with the document and restored when the document is reloaded. This works for the all options but the first three. Regardless of your settings for the document, the first three options are checked. This small differences in spacing can lead to large layout changes, especially when images have enough room on one page in the original layout, but are shifted to the next page, because now there is not enough room for the picture.
Please look, whether the option "Load user-specific settings with the document" is checked in Tools > Options > Load/Save > General. Otherwise default values are used. I could fix the different formating, when I checked this option.
(This is an automated message.) LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs) -- as this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc.) its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched. You can find out more about MABs and how the process works by contacting libreoffice qa on irc: http://webchat.freenode.net/?channels=libreoffice-qa The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list): https://wiki.documentfoundation.org/QA
(In reply to comment #31) > This works for the all options but the first three. Regardless of your > settings for the document, the first three options are checked. So this bugs subject should be changed to: "Some Writer Compatibility options are not loaded/saved in a document"? To clarify: These options are "Use printer metric for document"/"Add spacing between paragraphs and tables (in current document)"/"Add paragraph and table spacing at tops of pages (in current document)"?
(In reply to comment #32) > Please look, whether the option "Load user-specific settings with the > document" is checked in Tools > Options > Load/Save > General. Otherwise > default values are used. > I could fix the different formating, when I checked this option. to Björn Michaelsen: On my Debian, this option has no effect on this bug. Whether I checked this option or not , LO 4.1.X still showed the wrong format. So I am not sure it is proper to set the title to "Some Writer Compatibility options are not loaded/saved in a document". Does this option take effect on this bug in your LO 4.1.X ? The file I tested is : https://bugs.freedesktop.org/attachment.cgi?id=86448 Thank you~
(In reply to comment #34) > (In reply to comment #31) > > This works for the all options but the first three. Regardless of your > > settings for the document, the first three options are checked. > > So this bugs subject should be changed to: "Some Writer Compatibility > options are not loaded/saved in a document"? > > To clarify: These options are "Use printer metric for document"/"Add spacing > between paragraphs and tables (in current document)"/"Add paragraph and > table spacing at tops of pages (in current document)"? to Björn Michaelsen: Sorry for misunderstanding your opinion, I think I know what you said now. I total agree to change the subject to "Some Writer Compatibility > options are not loaded/saved in a document".
"Load user-specific settings with the document" set -> all compatibility settings loaded "Load user-specific settings with the document" unset -> first 3 compatibility settings always enabled, all other ones loaded works this way in 4.1.0.4, 4.1.6.1, 4.0.6.2, ... and already in OOo 3.3. so it appears odd but not a regression. => will revert to previous title with the "cwheib.ttf" font available, the document from https://bugs.freedesktop.org/attachment.cgi?id=86448 indeed looks different in 4.0.6.2 vc. 4.1.6.1/current 4.2 on Linux. on Windows in 4.2.3.3 it looks just like in 4.0.6.2 on Linux (13 rows on second page). so my suspicion is on the harfbuzz/freetype font-related changes going into 4.1. bibisect range: 923312f67fbf120158f01c2c0e588af38fc22364..2ede6c95e6481c92cc199e7d74fd36c841636304 some suspicious commits to vcl/generic/glyphs/gcach_ftyp.cxx in that range...
(In reply to comment #31) > I see the same problem on Windows 7, so setting Platform to all. Regina, what exactly are you seeing on Windows? do you have the cwheib.ttf font installed? > The reason for the different layout is this: > In Tools > Options > Compatibility you can set some options. Those should be > saved together with the document and restored when the document is reloaded. > > This works for the all options but the first three. Regardless of your > settings for the document, the first three options are checked. do you see any difference in loading these settings from documents across versions? i don't but i only tested on Linux; i find it extremely unlikely that the settings work differently on Windows but you never know...
This can be a result from the changes in font ascent/decent calculation with FreeType, but checking the font I see that Win, Typo and hhea values all are identical, so there should be no change.
Source bisection suggests this is not about the font ascent/decent calculation (commit f9560c8f9982eaef09b74baa479c187f049c4f9e), but the commit before that which changes the line height calculation, i.e. 5e77c9e17ba7dd9d296c9b755093f01e7eb4f514. The reason the stars shifted is because the blank lines above., e.g. those in the empty inner table, changed height. Khaled, feel free to chip in if you have any other opinion, but I'm going to assume that the line heights after the commit are more correct than before, and close this bug. Seting status -> RESOLVED NOTABUG commit 5e77c9e17ba7dd9d296c9b755093f01e7eb4f514 Author: Khaled Hosny <khaledhosny@eglug.org> Date: Sat May 11 00:50:59 2013 +0200 Revert 052f181dad89ad34d90513bc9dcd3e3239727933 Which in itself was effectively a revert of 3364fefe1e2dec522211040f2f9ea37bf5cd7466 Keeping the old broken line height calculation code is just masking of the real problem; there are some code elsewhere that have fragile workarounds to the real bug here (the removed code here shows a good example of such workarounds). On Mac we use the correct metrics as well, so we need to find the quirks and fix them, instead of pretending they do not exist. This fixes fdo#55469, among others. Change-Id: I36f13b28eaba022b7c388feae7e0bfd0ed1c3e89
*** Bug 89349 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]