Bug 53028

Summary:	[Patch] Broken auto fit row height in the cells with word wrap
Product:	POI	Reporter:	Dmitry Yakubovich <dmitry>
Component:	HSSF	Assignee:	POI Developers List <dev>
Status:	RESOLVED FIXED
Severity:	major	CC:	knst.kolinko
Priority:	P2	Keywords:	PatchAvailable
Version:	3.8-dev
Target Milestone:	---
Hardware:	PC
OS:	Windows Vista
Attachments:	Java code produce ugly xls file xls file with autosize height ok xls file with autosize height ugly Patch in two variants 2012-09-26_poi_53028_c10.patch - Patch for Comment 10

Description Dmitry Yakubovich 2012-04-03 03:02:41 UTC

After resolve bug (ID 45472) a commit (Revision 1,243,240) broke the usual behavior of xls files created through the POI.

Previously, if the row had not been set height then it was a flag RowRecord.setBadFontHeight(false) and cell with word wrap text,
which gave the auto fit of the row height when opening the file in Excel.

  Now in HSSFSheet.createRow is calling HSSFRow. setHeight which resets flag RowRecord.setBadFontHeight(true). What does Excel and then fit the row height of the text in cells with word wrapping. 
  Yet please note that HSSFRow.setHeight c height == -1 does not reset the flag of in RowRecord.setBadFontHeight(false), and don't access to private variable row type RowRecord.

I suggest the following options:
For the method **** HSSFSheet.createRow ****
1. Make a check on the set getDefaultRowHeight other than 255
 if (getDefaultRowHeight ()! = 255)
   row.setHeight (getDefaultRowHeight ());
   
2. Make another version of the createRow with a different name, or add an parameter to will create a row with no fixed working height and auto height fit.

For the method **** HSSFRow.setHeight ****
1. In the case of height == -1, reset the flag RowRecord.setBadFontHeight(false).
  if (height == -1) {
    RowRecord.setBadFontHeight (false);
    row.setHeight ((short) (0xFF | 0x8000));
  } else {

2. For the class HSSFRow add a method to access BadFontHeight ie getter and setter

Comment 1 Yegor Kozlov 2012-04-03 06:45:06 UTC

Can you post sample code that demonstrates the issue? I would like to see a sample code that used to work before r1243240 and produces bad output now. 

Also, does the problem show itself in all versions of Excel? Which version of MS Office are you using?

Yegor

Comment 2 Dmitry Yakubovich 2012-04-03 07:31:48 UTC

Created attachment 28536 [details]
Java code produce ugly xls file

Comment 3 Dmitry Yakubovich 2012-04-03 07:32:47 UTC

Created attachment 28537 [details]
xls file with autosize height ok

Comment 4 Dmitry Yakubovich 2012-04-03 07:33:28 UTC

Created attachment 28538 [details]
xls file with autosize height ugly

Comment 5 Dmitry Yakubovich 2012-04-03 07:42:20 UTC

I added an example with code and output files.

I think it does not depend on the version of MS Office. Checked in Office 2007, 2003.

Comment 6 Yegor Kozlov 2012-04-03 07:45:13 UTC

OK, thanks.

Something to work for me in the POI-3.9 dev cycle. 

Regards,
Yegor

Comment 7 sanchay 2012-06-12 10:20:11 UTC

Hi, is this issue because of this bug ? http://stackoverflow.com/questions/10978307/apache-poi-excel-hssf-wrap-text-issue

Comment 8 Rémy LeBeau 2012-07-12 13:40:53 UTC

Created attachment 29053 [details]
Patch in two variants

Seems like auto fit with HSSFSheet.setDefaultRowHeight is mission impossible due to option bit #1 in DefaultRowHeightRecord, at least in OpenOffice 3.2.1. Auto fit
should work at least when setDefaultRowHeight isn't used.

Comment 9 Evgeniy Berlog 2012-08-14 18:24:17 UTC

This problem should be fixed in trunk.

Please try with a nightly build - see download links on http://poi.apache.org/
or build yourself from SVN trunk, see http://poi.apache.org/subversion.html

Comment 10 Konstantin Kolinko 2012-09-26 13:58:53 UTC

Thank you for fixing this issue.

First, this issue is just "Broken auto fit row height".

I agree that the issue is more apparent for cells that have word wrap, but it is also observable in different circumstances. E.g. if I have a cell with a font which is bigger than the default height of the row.

Confirming, that this issue is observable with "3.8" release,
I do not see it with "3.8-beta5",
and it is fixed in the current nightly (20120924). I am using Excel 2003.

Just FYI: I also tried to verify this with LibreOffice 3.6.1 on Windows and the auto fit of row height is broken there (the row is displayed using its default height). It is their fault, not yours. A report in their bugzilla:
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=34717


Second, reviewing the fix in r1373005 I see an inconsistency:
There are 2 methods in org.apache.poi.hssf.usermodel.HSSFRow:

 - HSSFRow.setHeight(short)
 - HSSFRow.setHeightInPoints(float)

Both methods have special processing for the value of (-1). In r1373005 the fix was applied to the setHeight() method only.

I am REOPENING this issue, so that setHeightInPoints() be fixed as well.

Comment 11 Konstantin Kolinko 2012-09-26 14:03:36 UTC

Created attachment 29420 [details]
2012-09-26_poi_53028_c10.patch - Patch for Comment 10

Here is proposed fix and test for Comment 10 - HSSFRow.setHeightInPoints().

I do not have dev environment for POI, so this is untested.

Comment 12 Dominik Stadler 2016-10-05 20:03:33 UTC

Applied via r1763484, will be included in 3.16-beta1, thanks for the Patch and Test.