[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with "style:use-optimal-row-height='true'"

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=62268

Vasily Melenchuk (CIB)  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|libreoffice-b...@lists.free |vasily.melenc...@cib.de
   |desktop.org |

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with " style:use-optimal-row-height='true'"

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=62268

--- Comment #31 from dumischbaenger  ---
I am waiting now years for a fix. It has obviously no priority but is a real
problem for people using LO as a kind of report generator/viewer for reports
created with standard programming languages or XML/XSL toolchain. I was able to
work around this bug with macros.

Regards,
Bernhard

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with " style:use-optimal-row-height='true'"

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=62268

--- Comment #30 from adam_cadama...@hotmail.co.uk ---
This is still an issue in LibreOfficeCalc 6.0.

Like others, I generate ods files externally to LibreOfficeCalc with a custom
database export script. I generate the all the necessary xml files, the
mimetype and add png files. I carefully zip it all up to get a compliant ods
file.

As stated before, it is not possible during generation to know the row height
in order to set it in the xml. (Or rather it would require duplicating the
current LibreOfficeCalc auto row height calculation code based on content,
font, kerning, padding, size etc)

Opening the file in Excel, everything looks good.
Opening the file in LibreOfficeCalc6, all rows are at their default heights.

It is a problem, since users run the exporter themselves to create the ods, and
expect it to look correct when opening it. Getting them to run a macro is not a
solution.

It seems that the algorithm from Bernhard Donaubauer should be sufficient:

a) if there is no height attribute and the "use_optimal-row-height" attribute
is set then calculate the row height

b) if there is no height attribute and the "use_optimal-row-height" attribute
is not set then use the default value

c) if there is a height attribute just use it

If that is not possible, could a new custom xml attribute be introduced and
used to trigger row height recalculation on file open? Then we can just add
that to the xml. I don't care if it is stripped back out on save, since then
the height will be set anyway.

Regards,
Adam

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with " style:use-optimal-row-height='true'"

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=62268

--- Comment #29 from Svante Schubert  ---
As you see, this issue blocks to view any automated generated calc documents
with larger cell content.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with " style:use-optimal-row-height='true'"

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=62268

--- Comment #28 from Svante Schubert  ---
Created attachment 135612
  --> https://bugs.documentfoundation.org/attachment.cgi?id=135612=edit
Testdocument showing that row height is not being corrected by LO to display
large text

I might simplify the test case by adding a Hello World calc document.

I created a small test spreadsheet with LibreOffice doing a hello world with
hello in a cell in one row and world in the next row with a very high font (see
document attached).
After saving the document with LibreOffice, I manually removed the explicit row
hight on the second row with the high font text.
The row has after reload the same row height as any other rows and the content
with the high text font vanished.
This happens for latest MS Office as well, but works with OpenOffice.org.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with " style:use-optimal-row-height='true'"

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=62268

--- Comment #27 from Tester  ---
5.3.3.2 still has the bug.
Is here really no interest to fix this bug?
This bug makes it specially for professionals difficult, which generate ODS in
code.
2013  to be honest, this is disappointing.

Just compare the last working version with the first buggy version to finde the
changes in the critical area can not be so difficult.
(Use the Version infos from Bernhard Dippold)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with " style:use-optimal-row-height='true'"

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=62268

--- Comment #26 from Tester  ---
((
This next here is somehow of topic and somehow related anyway. So i write it
here, but it should not hinder the main discussion here!
I checked now even the OptimalColumnWidth functionality, in case of a bug
relation with OptimalRowHeight.

Calc seams to entirely not support OptimalColumnWidth
[style:use-optimal-column-width="true"]
- It don't stick with the column after manual use, it is not stored in column
propertys.
- It is not stored in the file. 
- There seams to be no code for OptimalColumnWidth (No functions like
UpdateAllColumnWidths, AdjustColumnWidth, ...?).
- This exists, but it seams it is never used(?):
CMAP( "OptimalWidth",   XML_NAMESPACE_STYLE,   
XML_USE_OPTIMAL_COLUMN_WIDTH,   XML_TYPE_BOOL, 0 ),

Is this a TODO, or is this specification of the ODS format intentional not
supported?
It could be useful for columns which for example have only short values, or
same length IDs, or 1 Charakter marks. The problem is the same, a outside
generator can not know the optimal width of a column.
Even if OptimalRowHeight is more common and important, OptimalColumnWidth
should be supported too, i think.
Should i write a feature-request/bug-report, or there will be no support for
OptimalColumnWidth [style:use-optimal-column-width="true"] in the future?

! But, OptimalRowHeight by file load should be fixed first, before somebody
look in to this OptimalColumnWidth issue!
))

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with " style:use-optimal-row-height='true'"

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=62268

--- Comment #25 from Tester  ---
Yes, i check the code my self, when i have seen that your first post was
2013... You wait a LONG time for a fix, so lite things can be so nasty.
I hope my speculation is right, and the mapping caused a wrong behavior, and a
developer simply deactivated the defective update function. And that a skilled
developer looks in to this soon.
(The code is not documented in comments, this makes it additional difficult for
a "outside" developer to understand the logics. A "inside" developer can fix it
maybe in minutes, if this is the bug.)
Such stubborn bugs are sometimes multiple bugs which makes a search hard, let
as hope it is only this. (And never take out a red warning light, instead to
fix the problem.)


I don't know jet where to reactivate the row updater. This are some related
functions:

-> UpdateAllRowHeights
-> AdjustRowHeight
-> IsAdjustHeightEnabled (This can suppress the update. If(!) his only propose
is to camouflage the bug, it could be deleted entirely.) 
mbAdjustHeightEnabled EnableAdjustHeight

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with " style:use-optimal-row-height='true'"

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=62268

Bernhard Dippold  changed:

   What|Removed |Added

 CC||fu...@arcor.de

--- Comment #24 from Bernhard Dippold  ---
Thanks for looking in that one, Tester!

As I'm no developer, this issue causes quite a number of computers to be stuck
with LibO 3.4 (sic!) for years...

If the bug just consist of a wrong mapping, a fix should be probably easy.
As you stated:
"Optimal height" is mapped to XML_MIN_ROW_HEIGHT (pobably the minimal height)
"Optimal width" is mapped to XML_USE_OPTIMAL_ROW_HEIGHT (width and height mixed
up?)

In Comment 16 Matthew Francis found out, that Daniel Bankston did some startup
improvement to Calc as a Google Summer of Code (GSOC) 2012 job, mentored by
Kohei Yoshida and Markus Mohrhard (who is still active on the developer list).

It seems that his hack omitted recalculation of row height even if the flag the
flag "style:use-optimal-row-height" is set to "true". If it's just a wrong
association between optimal and minimal height and width and height
respectively, it should be corrected. I always thought that there might have
been a performance issue to standard Calc files.

So if some developer might dig into it (or ask Markus for mentorship?), it
would help us very much!

PS: I added your email to the CC list, so you get new mails too.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with " style:use-optimal-row-height='true'"

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=62268

--- Comment #23 from Tester  ---
Here a link where i assume the bug.
Check: getRowPropertiesMap -> OptimalHeight, OptimalWidth
https://docs.libreoffice.org/xmloff/html/XMLTableExport_8cxx_source.html#l00081

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with " style:use-optimal-row-height='true'"

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=62268

--- Comment #22 from Tester  ---
A correction for my last post:
The [fo:wrap-option="wrap"] option is not either updated in the file open
process, 
not the [fo:break-before="auto"].

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with " style:use-optimal-row-height='true'"

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=62268

--- Comment #21 from Tester  ---
So much i see, [fo:break-before="auto"] for word wrap is not either updated in
the file open process. (The small red arrow on the right of the cell is
visible)

Could it be that a developer deactivated the updating function on file open, if
the above post really shows a bug, and causes wrong behavior on file load?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with " style:use-optimal-row-height='true'"

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=62268

--- Comment #20 from Tester  ---
Bug is still present in 5.3.2.2. 

i tray quick if i can see something in the code. here the result.
i am not a Libre coder, i look in the code the first time and only for minutes.
i have not check the code logic! please a coder should check the conclusion
here carefully, and forgive me in case i searched at the wrong place...
if this is not the bug source, i will try to search a little more, to see how
far i come... but please check the argument here first.


this is the search trace so far

from libreoffice-5.3.2.2.tar.xz

--> use-optimal-row-height
TOKEN( "use-optimal-column-width",XML_USE_OPTIMAL_COLUMN_WIDTH ),
TOKEN( "use-optimal-row-height",  XML_USE_OPTIMAL_ROW_HEIGHT ), 

--> XML_USE_OPTIMAL_ROW_HEIGHT

!!! This code shows a anomaly. The name mapping seams to be wrong.
libreoffice-5.3.2.2\xmloff\source\table\XMLTableExport.cxx

"XML_MIN_ROW_HEIGHT" is mapped as "OptimalHeight"
"XML_USE_OPTIMAL_ROW_HEIGHT" is mapped as "OptimalWidth"

 const XMLPropertyMapEntry* getRowPropertiesMap()
{
static const XMLPropertyMapEntry aXMLRowProperties[] =
{
RMAP( "Height", XML_NAMESPACE_STYLE, XML_ROW_HEIGHT,   
XML_TYPE_MEASURE,   0 ),
RMAP( "OptimalHeight",  XML_NAMESPACE_STYLE, XML_MIN_ROW_HEIGHT,   
XML_TYPE_MEASURE,   0 ),
RMAP( "OptimalWidth",   XML_NAMESPACE_STYLE,
XML_USE_OPTIMAL_ROW_HEIGHT,XML_TYPE_BOOL, 0 ),
MAP_END
};

return [0];
}

--> getRowPropertiesMap
libreoffice-5.3.2.2\xmloff\source\table\XMLTableExport.cxx

mxRowExportPropertySetMapper = new SvXMLExportPropertyMapper( new
XMLPropertySetMapper( getRowPropertiesMap(), xFactoryRef.get(), true ) ); 


libreoffice-5.3.2.2\xmloff\source\table\XMLTableImport.cxx

rtl::Reference < XMLPropertySetMapper > xRowMapper( new
XMLPropertySetMapper( getRowPropertiesMap(), xFactoryRef.get(), false ) ); 




--> Some More... XML_USE_OPTIMAL_ROW_HEIGHT
Here it seams to be correct
"XML_USE_OPTIMAL_ROW_HEIGHT" is mapped as "OptimalHeight"

const XMLPropertyMapEntry aXMLScRowStylesImportProperties[] =
{
// #i57867# Include background color
(CellBackColor/IsCellBackgroundTransparent) for import only.
// Import and export should use the same map, with
MID_FLAG_NO_PROPERTY_EXPORT for the background entries,
// but this doesn't work at the moment because SvXMLImportPropertyMapper
compares MID_FLAG_NO_PROPERTY to 0.
// If this is changed (not for 2.0.x), a single map can be used again.

MAP( "CellBackColor", XML_NAMESPACE_FO, XML_BACKGROUND_COLOR,
XML_TYPE_PROP_TABLE_ROW|XML_TYPE_COLORTRANSPARENT|MID_FLAG_MULTI_PROPERTY|MID_FLAG_MERGE_ATTRIBUTE,
0 ),
MAP( "Height", XML_NAMESPACE_STYLE, XML_ROW_HEIGHT,
XML_TYPE_PROP_TABLE_ROW|XML_TYPE_MEASURE, CTF_SC_ROWHEIGHT),
MAP( "IsCellBackgroundTransparent", XML_NAMESPACE_FO, XML_BACKGROUND_COLOR,
XML_TYPE_PROP_TABLE_ROW|XML_TYPE_ISTRANSPARENT|MID_FLAG_MULTI_PROPERTY|MID_FLAG_MERGE_ATTRIBUTE,
0 ),
MAP( "IsManualPageBreak", XML_NAMESPACE_FO, XML_BREAK_BEFORE,
XML_TYPE_PROP_TABLE_ROW|XML_SC_TYPE_BREAKBEFORE, CTF_SC_ROWBREAKBEFORE),
MAP( "OptimalHeight", XML_NAMESPACE_STYLE, XML_USE_OPTIMAL_ROW_HEIGHT,
XML_TYPE_PROP_TABLE_ROW|XML_TYPE_BOOL, CTF_SC_ROWOPTIMALHEIGHT),
MAP_END()
};
 const XMLPropertyMapEntry aXMLScRowStylesProperties[] =
{
MAP( "Height", XML_NAMESPACE_STYLE, XML_ROW_HEIGHT,
XML_TYPE_PROP_TABLE_ROW|XML_TYPE_MEASURE, CTF_SC_ROWHEIGHT),
MAP( "IsManualPageBreak", XML_NAMESPACE_FO, XML_BREAK_BEFORE,
XML_TYPE_PROP_TABLE_ROW|XML_SC_TYPE_BREAKBEFORE, CTF_SC_ROWBREAKBEFORE),
MAP( "OptimalHeight", XML_NAMESPACE_STYLE, XML_USE_OPTIMAL_ROW_HEIGHT,
XML_TYPE_PROP_TABLE_ROW|XML_TYPE_BOOL, CTF_SC_ROWOPTIMALHEIGHT),
MAP_END()
}; 
const XMLPropertyMapEntry aXMLScFromXLSRowStylesProperties[] =
{
MAP( "Height", XML_NAMESPACE_STYLE, XML_ROW_HEIGHT,
XML_TYPE_PROP_TABLE_ROW|XML_TYPE_MEASURE, CTF_SC_ROWHEIGHT),
MAP( "IsManualPageBreak", XML_NAMESPACE_FO, XML_BREAK_BEFORE,
XML_TYPE_PROP_TABLE_ROW|XML_SC_TYPE_BREAKBEFORE, CTF_SC_ROWBREAKBEFORE),
MAP( "OptimalHeight", XML_NAMESPACE_STYLE, XML_USE_OPTIMAL_ROW_HEIGHT,
XML_TYPE_PROP_TABLE_ROW|XML_TYPE_BOOL_FALSE, CTF_SC_ROWOPTIMALHEIGHT),
MAP_END()
};


Here it seams to be correct
"XML_USE_OPTIMAL_COLUMN_WIDTH" is mapped as "OptimalWidth"

const XMLPropertyMapEntry* getColumnPropertiesMap()
{
static const XMLPropertyMapEntry aXMLColumnProperties[] =
{
CMAP( "Width",  XML_NAMESPACE_STYLE,XML_COLUMN_WIDTH,  
XML_TYPE_MEASURE,   0 ),
CMAP( "OptimalWidth",   XML_NAMESPACE_STYLE,   
XML_USE_OPTIMAL_COLUMN_WIDTH,   XML_TYPE_BOOL, 0 ),
MAP_END
};

return [0];
}


thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with " style:use-optimal-row-height='true'"

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=62268

--- Comment #19 from Tester  ---
(I prepared this text for the bug report and found this here... so i post my
issue. i agree with Bernhard Dippold

Calc Version: 5.3.0.3 (Bug is still present)

Issue, libreoffice-Calc should update the automatic optimal height of rows, wen
the file is opened.
This is a issue which maybe shows up only by outside generated documents (Not
saved by libreoffice-Calc).

The Rows are set to be formated in optimal height, and because the generator
can not know this hight, the data is left out.
Calc should now update the Rows heights to there optimal. But after opening a
document, all rows are in the same standard hight.
The expected behavior is that Calc updates the height from this rows
automatically by the opening of the file, in case no height is set in the XML.
So that the user don't have to take any further action to correct the heights
manually.
I speculate, a simple trigger of a "Do-Automatic-Row-Height-Correction" in the
opening process fix the bug. dependent of the code, it is maybe only 1 code
line more.

Below are the XML codes generated form external generator, and tests.
See in "office:automatic-styles" the "style:use-optimal-row-height" option in
ro1 ro2
See in "office:automatic-styles" the "style:row-height" option in r03 r04
r03 r04 are the data generated from a external generator, form him it is
impossible to predict the height.

If a automatic update is not wanted, "style:use-optimal-row-height" simply must
be "false". It is set to "false" from Calc automatically, in case a user
changes the hight manually.
If it is "true", the correct behavior is to update it on file-load.


(I ca send a exampple.ods, but a expert should unterstand the issue
immediately.)

(In case you care about details, my ODS generator is a PHP code, which
generates documentation for medical informations. The users of the generator
should not do extra work to correct the row hight after opening the document.
And the generator can not know the hight Calc will create, so can not set it in
the generation process. The update must be done by loading the file. So pleas
no work arounds.)


content.xml:
...






































Fix Hight, No Automatic
Update, Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight Hight
Hight Hight





Automatic Known Hight,
but Wrong, Do Automatic Update?, Hight Hight Hight Hight Hight Hight Hight
Hight Hight Hight Hight Hight Hight Hight





Automatic Unknown
Hight, Do Automatic Update!, Hight Hight Hight Hight Hight Hight Hight Hight
Hight Hight Hight Hight Hight Hight





Automatic Unknown
Hight, Do Automatic Update!, Hight Hight Hight Hight Hight Hight Hight Hight
Hight Hight Hight Hight Hight








...

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with style:use-optimal-row-height='true'

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=62268

Joel Madero jmadero@gmail.com changed:

   What|Removed |Added

   See Also||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=69
   ||745

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with style:use-optimal-row-height='true'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62268

--- Comment #17 from Bernhard Dippold bernh...@familie-dippold.at ---
Hi Matthew, thanks for bibisection!

As ignoring the flag style:use-optimal-row-height='true' on FileOpen has been
done on purpose, I wouldlike to know, where we should discuss the positive and
negative aspects of this behavior. 

While I understand, that file opening time can be reduced in the majority of
cases by ignoring that flag, LibreOffice loses it's capacity to handle files in
ODS Format being modified on XML base (while staying valid OASIS ODF
documents).

I stated in the first comment the importance of this point for our group of
hospitals, so we need a decision inside LibO on the way to go. If necessary we
would give AOO a try, but that's a step I'd really like to avoid.

So - where should the question be discussed?
disc...@documentfoundation.org?
libeoff...@lists.freedesktop.org?

Thanks for reply!

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with style:use-optimal-row-height='true'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62268

Matthew Francis fdb...@neosheffield.co.uk changed:

   What|Removed |Added

   Keywords||bisected
 CC||daniel.dev.libreoffice@gmai
   ||l.com,
   ||fdb...@neosheffield.co.uk
 Whiteboard|bibisectRequest |bibisected

--- Comment #16 from Matthew Francis fdb...@neosheffield.co.uk ---
Bibisect points to source-hash-2b5b04e1e62914bf0902dfd7943cdc44499c47a6 in
43all (massive quantities of skipping required so I will omit the log)

Follow-up source bisection points to the below commit. Looks like a GSOC 2012
job.


commit cd2f8a1cabbfb924c62d7af2aac3ac09288c2d4c
Author: Daniel Bankston daniel.e.banks...@gmail.com
Date:   Mon Jun 25 01:21:26 2012 -0500

Stop calculating row heights and instead use imported row heights only

Change-Id: I1a5e33c292fb915e61511efbdb9ce4a0cfd7265f

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with style:use-optimal-row-height='true'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62268

--- Comment #15 from Bernhard Dippold bernh...@familie-dippold.at ---
Thanks Robinson (qubit) for confirming!
Could you please also have a look at the correspondig bug 62361 ?

In this bug report here we have three different behaviours when opening the
example file (attachment 77008):

LibO before 3.5.7.2 expands the row height on fileopen according the flag
style:use-optimal-row-height='true'. The multiple line input is visible when
the file is opened, row-height of row 4 is 1,89cm. 
(tested with 3.5.5.3 today)

LibO 3.5.7.2 shows only a part of the text, as the text contains the line
breaks and the cell height is not expanded. At the moment, I don't have access
to this version, but the description in comment 12 is what I remember from
4.0.0.3.


Present LibO versions ignore the line breaks in the text - it is consolidated
into one line: STARTTHIS IS A LNG TEXTTEXT TEXT TEXT-ENDE- (row-height
of line 4 is 0,48cm). Input field shows only START, probably because of the
(invisible) line break. There is no red triangle, because all of the text is
visible, even if the format is broken.

If you click inthe input line or double click the text the text is formatted:
START
THIS IS A LNG TEXT

TEXT TEXT TEXT
-ENDE-

Row height is still too small to fit the text, but if you modify the text (even
if you add and remove a character), it is recalculated with the correct row
height (1,74cm). If you leave the cell without modifications, row height stays
small, the text is consolidated again. Even if you undo the modifications row
height is reduced and the text doesn't contain any line breaks anymore.

Please - anybody with knowledge in this area: Could yo tell us, what is the
reason for these changes?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with style:use-optimal-row-height='true'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62268

Robinson Tryon (qubit) qu...@runcibility.com changed:

   What|Removed |Added

   Keywords||regression
 Status|UNCONFIRMED |NEW
 CC||qu...@runcibility.com
 Ever confirmed|0   |1
 Whiteboard||bibisectRequest

--- Comment #14 from Robinson Tryon (qubit) qu...@runcibility.com ---
TESTING on Ubuntu 14.04 + LO 3.5.0.3 and LO 4.4.0.1

(In reply to Bernhard Dippold from comment #10)
REPRO Steps:
 Open attachment 77008 and have a look at cell A4:
 
 LibO Versions before 3.5.7.2 (my test version: LibO 3.4.3 build OOO340m on
 WInXP) show five lines of text:
 
 START
 THIS IS A LNG TEXT
 
 TEXT TEXT TEXT
 -ENDE-

CONFIRMED: That's how it appears for me in 3.5.0.3

 Row height is expanded to 1,89cm to fit the content.
 
 Newer versions (I tested it with LibO 4.0.0.3 Build ID:
 7545bee9c2a0782548772a21bc84a9dcc583b89 on WinXP) just show the empty middle
 line, marked with a red triangle at the rigth border to indicate more
 content.

CONFIRMED: Testing with 3.5.7.2, it looks like I just see the bottom edge of
the line of text, until I click on the Input Line.

With 4.4.0.1, the multiple lines appear consolidated into a single line (with
all of the text visible), and no red arrow. When I click on the Input Line,
then the cell expands and I see multiple lines at once.

This is definitely a change in behavior. I'm guessing it's intentional and not
an unexpected regression, but it would be good to know when this happened, so 
Whiteboard - bibisectRequest
keywords - regression
Status - NEW

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with style:use-optimal-row-height='true'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62268

Bernhard Dippold bernh...@familie-dippold.at changed:

   What|Removed |Added

 CC||Bernhard.Donaubauer@Bayerwa
   ||ld-Online.com

--- Comment #13 from Bernhard Dippold bernh...@familie-dippold.at ---
If I understood Rainer Bielefeld correct, he moved the main target of this bug
to bug 62361. Even if nobody else commented the other bug, it's status is NEW
while this one is still UNCONFIRMED - so it stays under the radar of (nearly)
everybody.

I'm going to add a comment to bug 62361 about your confirmation here for the
present versions of LibO - and if you would change the status here to NEW, this
might lead to more interest here. Perhaps one of the developers would be able
to decide if this one is a duplicate to #62361 or vice versa.

(I added you to the CC list - please remove yourself if you get my comments
twice becasue of your preference settings)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with style:use-optimal-row-height='true'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62268

--- Comment #12 from Bernhard Donaubauer 
bernhard.donauba...@bayerwald-online.com ---
Is there any news on this issue. We installed a new version of LO on our server
and have now the same problem as Bernhard Dipphold explained. This error - in
my opinion it is an error - hits our reporting tools based on ODF an LO.

I think I can remember that at least OO always stated that the creation of ODF
via XML, XSLT, ... is a valid way to generate ODF Files. If you don't calculate
the row height this way is getting invalid at least in respect to the
use-optimal-row-height attribute. I have no way in XSLT to calculate the row
height.

I wonder why this feature was removed? Is there a bug number?


I think it would be possible to settle both parties with the following
algorithm:


a) if there is no height attribute and the use_optimal-row-height attribute
is set then calculate the row height

b) if there is no height attribute and the use_optimal-row-height attribute
is not set then use the default value

c) if there is a height attribute just use it


Regards,
Bernhard Donaubauer

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with style:use-optimal-row-height='true'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62268

Bernhard Dippold bernh...@familie-dippold.at changed:

   What|Removed |Added

  Attachment #76450|0   |1
is obsolete||

--- Comment #10 from Bernhard Dippold bernh...@familie-dippold.at ---
Created attachment 77008
  -- https://bugs.freedesktop.org/attachment.cgi?id=77008action=edit
Small Calc document with

Now got an example file unmodified by a recent LibO version:

Open the file and have a look at cell A4:

LibO Versions before 3.5.7.2 (my test version: LibO 3.4.3 build OOO340m on
WInXP) show five lines of text:

START
THIS IS A LNG TEXT

TEXT TEXT TEXT
-ENDE-

Row height is expanded to 1,89cm to fit the content.

Newer versions (I tested it with LibO 4.0.0.3 Build ID:
7545bee9c2a0782548772a21bc84a9dcc583b89 on WinXP) just show the empty middle
line, marked with a red triangle at the rigth border to indicate more content.

Row height is 0,48cm.

Automatic word wrap is activated for cell A4.

Content.xml states optimal row height as true while defining row-heigth as
0,478cm :

- style:style style:family=table-row style:name=ro2
  style:table-row-properties fo:break-before=auto style:row-height=0.478cm
style:use-optimal-row-height=true / 
.
.
.
- table:table-row table:style-name=ro2
- table:table-cell office:value-type=string table:style-name=ce4
  text:pSTART THIS IS A LNG TEXT TEXT TEXT TEXT -ENDE-/text:p 
  /table:table-cell
...
/table:table-row

This file should replace attachment 76450 because my first file had been opened
and saved by LibO 3.6.4 and therefore doesn't show the different behavior
between the older and newer versions.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with style:use-optimal-row-height='true'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62268

Bernhard Dippold bernh...@familie-dippold.at changed:

   What|Removed |Added

  Attachment #77008|Small Calc document with|Small Calc document where
description||line wrap in cell A4 should
   ||cause recalculation of row
   ||height

--- Comment #11 from Bernhard Dippold bernh...@familie-dippold.at ---
Comment on attachment 77008
  -- https://bugs.freedesktop.org/attachment.cgi?id=77008
Small Calc document where line wrap in cell A4 should cause recalculation of
row height

description corrected

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with style:use-optimal-row-height='true'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62268

Rainer Bielefeld libreoff...@bielefeldundbuss.de changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=62361

--- Comment #9 from Rainer Bielefeld libreoff...@bielefeldundbuss.de ---
I submitted Bug 62361 - FILEOPEN without optimum row hight calculation, what
seems related or even might be a DUP. I think in that bug I reproduce
reporter's original problem, what is not possible with sample 2013-03-12 23:49
UTC, Bernhard Dippold .

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with style:use-optimal-row-height='true'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62268

--- Comment #7 from Rainer Bielefeld libreoff...@bielefeldundbuss.de ---
Created attachment 76538
  -- https://bugs.freedesktop.org/attachment.cgi?id=76538action=edit
Sample document, first step.

I did some more tests and was already able to reproduce an at least very
similar problem, but it seems that the problem is related to a very particular
way to create the document, and I forgot the way :-(
But I will find it again, I am sure.

May be you want to do some tests with attached sample.ods, what should show
correctly calculated row height in Tabelle1.A1 until LibO 3.4, starting with
3.5(.7.2) row height calculation fails

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with style:use-optimal-row-height='true'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62268

--- Comment #8 from Bernhard Dippold bernh...@familie-dippold.at ---
Here at work I can't test other versions than 3.6.2 and 4.0.1.

Both show the wrong height in your sample.ods.

The height shown is the one defined in the content.xml: 24,64mm
So it ignores style:use-optimal-row-height='true'.

I don't know how you created the sample file, but it's behavior is similar to
bug 57519 (if you save the created file): 
You just have to open a file where the row height defined in content.xml is
different from the result of a recalculation of the optimal row height.

Perhaps the modification we're looking for has not been any work concerning row
height recalculation, but was part of speed optimization on fileopen:

If someone decided that it is not necessary to recalculate every row (with
'optimal height') on fileopen, this would probably lead to faster opening of
large documents. 

I didn't get a sample document from our software developer containing the data
we open in LibO and convert to PDF - I'll upload it ASAP.

PS: Your macros miss the (previously unmentioned) point that our documents
contain rows with absolute (fixed) height. If you are interested in such a
document (containing 7 sheets) I'm going to remove all identificable patient
data and send it to you as PM.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with style:use-optimal-row-height='true'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62268

Rainer Bielefeld libreoff...@bielefeldundbuss.de changed:

   What|Removed |Added

Summary|FORMATTING: Optimum row |FILEOPEN: Optimum row
   |height should be retained   |height should be
   |after save - close - reopen |recalculated with
   ||style:use-optimal-row-heig
   ||ht='true'

--- Comment #3 from Rainer Bielefeld libreoff...@bielefeldundbuss.de ---
Summary more nearby reporter's expectations

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with style:use-optimal-row-height='true'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62268

--- Comment #4 from Rainer Bielefeld libreoff...@bielefeldundbuss.de ---
@Bernhard:
I can't reproduce your result that optimum row height will be calculated when
open file with Server Installation of LibreOffice 3.4.4  - WIN7 Home Premium
(64bit) German UI [Build ID: OOO340m1 (Build:402)]: Your sample and all copies
created with m Test b from various versions all show truncated test at bottom
and top of cell A4.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with style:use-optimal-row-height='true'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62268

Bernhard Dippold bernh...@familie-dippold.at changed:

   What|Removed |Added

 Status|NEEDINFO|UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #5 from Bernhard Dippold bernh...@familie-dippold.at ---
Thank you very much, Rainer, for your examinations and the explanations you
made about ODF OASIS Standard.

You're right in explaining our expectations - and your new summary describes
our intentions very well.

My sample document has been opened and saved with LibO 3.6.2 and thus doesn't
show the way former versions did handle the files for several years.

I'm going to ask our software developer to provide a file unchanged by LibO, so
you can test it with the older versions. What he told me is:

- LibO up to version 3.4.4 recalculated row height on fileopen, when
style:use-optimal-row-height=true
- Excel 2010 recalculates it in the same way.
- As you tested, AOO 3.4.1 does the same recalculation on fileopen

- only present LibO versions don't do the recalculation, but use the row height
defined in the content.xml despite the flag.

With your tests you describe a similar difference between the versions:
Up to version 3.4.5 row height in Row 3 is 51,8 mm. Even if the content is not
fully visible, row height has been recalculated to fit the text. The height is
slightly too small, so I assume that someone wrote a patch in order to optimize
this recalculation. I'm quite sure that this didn't affect fileopen only, but
entire recalculation of optimal row height. 

I probably didn't search for the right key words, but I wasn't able to find the
bug containing the patch correcting the problem, that automated row height
adaption was slightly too small.

This (or a similar) patch seems to stop recalculation of optimal-row-heigth on
fileopen: 

In your test all versions from 3.5.7.2 show a row height of 4,8 mm - the height
defined in content.xml ignoring the optimal-row-height flag.

I'm not the one to decide, if AOO and Excel 2010 are wrong in interpreting ODF
OASIS Standard as recalculation of row height after modification of the content
whether this has been made in the current application or outside.

If LibO interpretes the Standard as only to be respected inside the own
application, we need to drop the new LibO versions in all our hospitals.

Please tell me, if I should address this question to one of the mailing lists
(which one? libreoffice@lists.freedesktop? discuss@documentfoundation?).

But I could imagine that some of the XLS related bug reports might be related
to the problem that the slightly different font size between the office suites
cause wrong row heights on fileopen...

Please change the status to NEEDINFO again, if you need more information.
(Or change it to NEW if you think it is worth to work on it)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 62268] FILEOPEN: Optimum row height should be recalculated with style:use-optimal-row-height='true'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62268

--- Comment #6 from Rainer Bielefeld libreoff...@bielefeldundbuss.de ---
Created attachment 76510
  -- https://bugs.freedesktop.org/attachment.cgi?id=76510action=edit
Macros as Workaround

(In reply to comment #5)
As a quick workaround I tried 2 Macros.
Row by row from 
 http://www.calc-info.de/files/Calc_StarBasic.pdf (slow!)
and System with a self recorded macro what simply does menu(s) 
'Edit - Select All - Format Row height - Optimum Row Height' (auick)

Macros not as ready solution, only as a demo showing possibilities. An expert
should be able to created some kind of Extension solving your problem in such a
way applying optimum row hight at every file open.

Because I do not know whether this here will end with a fix (because behavior
might be intended) I recommend to present the problem on
http://ask.libreoffice.org/en/questions/ and may be post a minimum
description with link to AskLibO on 
disc...@de.libreoffice.org, disc...@documentfoundation.org
May be someone can give a hint concerning a secret flag in the LibO settings or
similar ...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs