Bug 102319 - auto size line-height
Summary: auto size line-height
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.3.5.2 release
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-21 06:43 UTC by ankolpakov
Modified: 2017-05-31 10:47 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Report in OO (401.29 KB, image/jpeg)
2016-09-21 06:43 UTC, ankolpakov
Details
Report in OO in ods (15.47 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-09-21 08:00 UTC, ankolpakov
Details
Report in LO in ods (51.04 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-09-21 08:01 UTC, ankolpakov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ankolpakov 2016-09-21 06:43:13 UTC
Created attachment 127496 [details]
Report in OO

Hi, sorry for my bad English. We have some software which use open office or libre office to display different reports. In OpenOffice v4.0.1 report displayed OK, for example - open.jpg, but in LibreOffice v4.3.5.2 (also in LO v5.2.1) same report displayed incorrectly, for example - http://disk.tom.ru/l3vf7sn/1 - libre.jpg. Developers of our software claim "It's problem of LO - it didn't does auto size line-height and column width if it don't clearly defined". Can you correct this problem, If it's true?
Comment 1 ankolpakov 2016-09-21 08:00:56 UTC
Created attachment 127498 [details]
Report in OO in ods
Comment 2 ankolpakov 2016-09-21 08:01:40 UTC
Created attachment 127499 [details]
Report in LO in ods
Comment 3 ankolpakov 2016-09-21 08:14:33 UTC
When I saved file of report which was opened in LO and close it, and open this file in OO report display correctly. Also in LO when I delete any information from any cell "size line-height" of this line do correctly, if do ctrl+z data is back and "size line-height" stay correct.
Comment 4 brucehohl 2016-09-24 16:37:08 UTC
Open each file with an archive tool such as 7zip. Then open content.xml.  Then examine the defined row styles, for example from LO.ods:

<style:style style:name="ro2" style:family="table-row">
<style:table-row-properties 
  style:row-height="0.452cm" 
  fo:break-before="auto" 
  style:use-optimal-row-height="true"/> 
</style:style> 

The row styles defined and used in each file are different.  Hence, the rows display differently upon open.  If style:row-height="0.452cm" were instead style:row-height="1.510cm" the data rows would display as desired. And, it appears that other rows in LO.ods should use row style r01 instead of r02.
Comment 5 ankolpakov 2016-09-27 01:30:15 UTC
Answer of developers our software:
We can't calculate beforehand line-height - it's main problem, we set style "style:use-optimal-row-height="true"" and don't set up line-height at all (except line, where height clearly defined in setup of report). In specification ODF written that this style provides that software which opens file calculates line-height by itself for correct display of content. OO does this, LO doesn't.
Comment 6 brucehohl 2016-09-28 02:09:41 UTC
@ankolpakov Your report is likely a duplication of one or more of the following previously reported bugs:  Bug 62268, Bug 62361, Bug 69745.

See these reports for details. I commented on your report as I have experienced unexpected row height behavior in my use of LO. Perhaps someone might comment regarding how to increase the priority of resolving this problem.
Comment 7 Buovjaga 2016-10-09 16:23:56 UTC
(In reply to brucehohl from comment #6)
> @ankolpakov Your report is likely a duplication of one or more of the
> following previously reported bugs:  Bug 62268, Bug 62361, Bug 69745.
> 
> See these reports for details. I commented on your report as I have
> experienced unexpected row height behavior in my use of LO. Perhaps someone
> might comment regarding how to increase the priority of resolving this
> problem.

ankolpakov: please look at the reports and preferably close your own report as RESOLVED DUPLICATE of one of them. If you disagree, set to UNCONFIRMED and explain why.
Comment 8 QA Administrators 2017-05-02 11:37:25 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2017-05-31 10:47:02 UTC
Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-20170531