Bug 65982 - Different line height in Writer in Linux than in Windows for legacy document written by old OOo due to UnxForceExtLeading defaulting
Summary: Different line height in Writer in Linux than in Windows for legacy document ...
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:odf
Depends on:
Blocks:
 
Reported: 2013-06-20 20:21 UTC by Roman Polach
Modified: 2015-12-17 05:51 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Document where page break is between 52. and 53. line in Windows and between 54. and 55. line in Linux (7.51 KB, application/vnd.oasis.opendocument.text)
2013-06-20 20:21 UTC, Roman Polach
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Polach 2013-06-20 20:21:31 UTC
Created attachment 81131 [details]
Document where page break is between 52. and 53. line in Windows and between 54. and 55. line in Linux

If used Arial or Times New Roman fonts in LibreOffice Writer,
line height and/or paragraph spacing is different between
a) LibreOffice in Windows 7
and
b) LibreOffice in Linux Mint 15 (with installed "ttf-mscorefonts-installer" package installed Arial and other fonts)

Steps to reproduce:
1) create new Writer document
2) Write 60 times one-line paragraphs with "Arial 12" style
3) In Windows you can see page break between 52. and 53. line,
   while in Linux you can see page break between 54. and 55. line
4) you can save the document and open it in another operating system,
   the page break changes possition as described in 3)

Attaching document created by these steps...

Note 1: I can see this wrong behaviour for Arial and Times New Roman fonts,
but not e.g. for DejaVu fonts.

Note 2: Windows/LibreOffice behaviour is the same as Windows/MSOffice behavior

Note 3: I believe that fonts under Linux are downloaded from
http://sourceforge.net/project/showfiles.php?group_id=34153&package_id=56408
with checksums so they are probably not corrupted... I have also tried this
reproduce at another boxes (Windows and Linux) with same results.
Comment 1 Roman Polach 2013-06-20 20:29:29 UTC
As described in https://issues.apache.org/ooo/show_bug.cgi?id=75405#c9 for OpenOffice, there is undocumented flag UnxForceZeroExtLeading which can be hacked in a single file to false and then the problem should be gone.

  MyDocument/settings.xml//config:config-item[@config:name='UnxForceZeroExtLeading']=
false

This is probably the same of the problem in LibreOffice.

This hack has several problems:
I. It is a hack
II. It cannot be done for .doc files which one want to open in LibreOffice
III. It should be always default to have set correct behavior, i.e. UnxForceZeroExtLeading=false

So for fixing this bug there should be probably done at least:
1. setting this flag to false for newly created text documents
2. setting this flag to false during openning a .odt file
3. setting this flag to false during import of msword .doc file

But I do not know why such flag exists at all? 
And why it is true by default?
(And why it is undocummented?)
Is there any misbehavior when one set it to false?
Comment 2 QA Administrators 2015-03-16 23:03:42 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

    Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later)
    https://www.libreoffice.org/download/

    If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
  
  If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

    Update the version field
    Reply via email (please reply directly on the bug tracker)
    Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)

http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to "inherited from OOo";
4b. If the bug was not present in 3.3 - add "regression" to keyword


Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for your help!

-- The LibreOffice QA Team This NEW Message was generated on: 2015-03-16
Comment 3 Roman Polach 2015-03-23 09:30:19 UTC
The problem is still the same.
Tested in
LibreOffice 4.4.1.2 for Windows (break 52/53)
vs.
LibreOffice 4.4.1~rc2-0ubuntu1-trusty1 (break 54/55)
Comment 4 Jean-Baptiste Faure 2015-03-28 13:47:42 UTC
This bug report has never been confirmed by an independent tester. Set back to UNCONFIRMED.
Please, do not set your own bug report to NEW.

Best regards. JBF
Comment 5 Robinson Tryon (qubit) 2015-03-29 15:46:24 UTC
(In reply to Roman Polach from comment #1)
> As described in https://issues.apache.org/ooo/show_bug.cgi?id=75405#c9 for
> OpenOffice, there is undocumented flag UnxForceZeroExtLeading which can be
> hacked in a single file to false and then the problem should be gone.

OpenGrok does show that this string appears in various files, including 'xmlimp.cxx':
http://opengrok.libreoffice.org/search?q=UnxForceZeroExtLeading&project=core&project=help&project=translations&defs=&refs=&path=&hist=

I just googled for that flag (by itself, as well as "~ + OASIS"), and grepped through the ODF 1.2 OASIS spec, and it's not mentioned, so it does appear to be something special to LO...

I don't see a mention here (or anywhere else on the TDF wiki), so perhaps something as-yet undocumented:
https://wiki.documentfoundation.org/Development/ODF_Implementer_Notes/List_of_LibreOffice_ODF_Extensions

> But I do not know why such flag exists at all? 
> And why it is true by default?
> (And why it is undocummented?)
> Is there any misbehavior when one set it to false?

Hopefully the process of documenting this behavior will answer some or all of your q's!

(Undocumented behavior, so Status -> NEW)

[cc: mstahl]
Comment 6 Michael Stahl (allotropia) 2015-04-01 21:25:14 UTC
UnxForceZeroExtLeading is a backward compatibility setting for legacy
documents created by older StarOffice/OOo versions.

The attachment was written by OOo 2.1, which *did* presumably have
the different formatting on Unix vs. Windows.

Then that difference was considered a bug and fixed in a later OOo version,
specifically OOo issue 60945 fixed for OOo 2.2,
and the UnxForceZeroExtLeading compatibility setting was introduced
so that existing documents are formatted as in the older OOo versions.

The settings.xml in the document does not contain a value for
UnxForceZeroExtLeading, therefore the import will add a value for
it that corresponds to the legacy formatting of old versions.

If the document is loaded and stored again by current LO, it contains:

 <config:config-item config:name="UnxForceZeroExtLeading" config:type="boolean">true</config:config-item>

However, a newly created document will be stored with:

 <config:config-item config:name="UnxForceZeroExtLeading" config:type="boolean">false</config:config-item>

AFAICS this works as designed.
Comment 7 Michael Stahl (allotropia) 2015-04-01 21:28:59 UTC
forgot to add: the compatibility settings are intentionally
not part of the OASIS OpenDocument specification,
because it does not make any sense to burden the standard
with backward compatibility hacks for specific
legacy products like this.

(generally the entire content of settings.xml is specific to
OOo and products derived from that)
Comment 8 Roman Polach 2015-04-02 22:41:55 UTC
I can confirm, that if I open the (attached) document
in LO/linux (page break between 54 and 55) and then copy+paste
into a new document, then the break is between 52 and 53.
LO 4.4.2.2.
Thank you.
Comment 9 Robinson Tryon (qubit) 2015-12-17 05:51:03 UTC
Migrating Whiteboard tags to Keywords: (filter:odf)
[NinjaEdit]