Bug 45789 - automatic row height in reports
Summary: automatic row height in reports
Status: ASSIGNED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Ilhan Yesil
URL:
Whiteboard:
Keywords: difficultyInteresting, easyHack, skillCpp, skillJava, topicUI
: 40229 114387 116210 (view as bug list)
Depends on:
Blocks: 50105
  Show dependency treegraph
 
Reported: 2012-02-08 07:48 UTC by Lionel Elie Mamane
Modified: 2019-06-28 15:36 UTC (History)
17 users (show)

See Also:
Crash report or crash signature:


Attachments
example database (28.24 KB, application/vnd.oasis.opendocument.database)
2012-03-21 08:04 UTC, Lionel Elie Mamane
Details
wrong result 2 (11.54 KB, application/vnd.oasis.opendocument.text)
2012-03-21 08:05 UTC, Lionel Elie Mamane
Details
right result (12.70 KB, application/vnd.oasis.opendocument.text)
2012-03-21 08:06 UTC, Lionel Elie Mamane
Details
another, larger database to demo this bug (14.98 KB, application/vnd.oasis.opendocument.database)
2018-03-06 16:09 UTC, Howard Johnson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lionel Elie Mamane 2012-02-08 07:48:29 UTC
In a report that contains at least one field with a highly variable amount of data from row to row, it is often desirable for that field to take as many lines as it needs on the printout, but not to reserve several lines on *all* data rows just to accomodate the rows that have more data (thereby wasting space).

This is easily achieved after the report is generated by editing the resulting writer document and setting "optimal row height" on the rows that contain the given field (that is all rows in a tabular-style layout).

We should have a way to specify this in the report design itself.

Add a boolean property "autogrow" (or similar) to every control. In the generated writer document, at the moment the table(s) are created to hold the data, set the "optimal height" for rows that contain at least one control whose autogrow property is set to true.

For bonus points, also add a way to fix the height of the whole detail section (all rows in the lowest grouping, if any). This is useful in layouts where things have to be at a fixed position on the page.
Comment 1 sasha.libreoffice 2012-03-21 07:20:06 UTC
Thanks for new idea
Please, attach small Database document that demonstrates this problem
Comment 2 Lionel Elie Mamane 2012-03-21 08:04:35 UTC
Created attachment 58813 [details]
example database

One table (Assets), two rows. One has short text in "comments", the other has long text in comments. With the current system, one can only get two different kinds of "wrong" results:

 - "wrong result 1" (report in this database document): the short text takes too much space
 - "wrong result 2" (attached odt file and Assets report in this database document): the long text is cut to fit within one line, as indicated by a red triangle.

The result I would like is in attachment "right result". Obtained by editing "wrong result 2", selecting the two data row and selecting optimal row height for those.
Comment 3 Lionel Elie Mamane 2012-03-21 08:05:13 UTC
Created attachment 58814 [details]
wrong result 2
Comment 4 Lionel Elie Mamane 2012-03-21 08:06:22 UTC
Created attachment 58816 [details]
right result
Comment 5 sasha.libreoffice 2012-03-21 09:57:14 UTC
Thanks for attachments
To produce last attachment (3-th) we do:
1. Select table
2. Right click table, select Row->Hight
3. Check box "Fit to size"

And now I have another question: what wrong if we do this behaviour as default. I see one advantage: user will not have problems with data that accidentally becomes hidden outside of cell. This may produce data loss when document will printed. This may increase productivity, because users will have no need to check this option each time.

But may be exist disadvantages for make this as default?
Comment 6 Lionel Elie Mamane 2012-03-21 10:33:39 UTC
(In reply to comment #5)
> And now I have another question: what wrong if we do this behaviour as default.

Well, a row (cell) could take far too much space and fuckup the layout (depending on how the layout is done).

Whether the "fit to size" thing is desirable depends on the data being shown... FWIW, in MS Access, one can choose this kind of thing per-control (AutoGrow and AutoShrink). This allows to do e.g.:

 Name     Number          Data
 Eleonor  1                    short data
 Lionel M 2                     short data
 Ted     

when the name of number one is really "Eleonora Battista Almeire", number 2 "Lionel Mamane"

> I see one advantage: user will not have problems with data that accidentally
> becomes hidden outside of cell. This may produce data loss when document will
> printed. This may increase productivity, because users will have no need to
> check this option each time.
> 
> But may be exist disadvantages for make this as default?
Comment 7 Lionel Elie Mamane 2012-03-21 10:39:23 UTC
(In reply to comment #5)
> And now I have another question: what wrong if we do this behaviour as default.

Well, a row (cell) could take far too much space and fuckup the layout (depending on how the layout is done).

Whether the "fit to size" thing is desirable depends on the data being shown... FWIW, in MS Access, one can choose this kind of thing per-control (AutoGrow and AutoShrink). This allows to do e.g.:

 Name     Number          Data
 Eleonor  1                    short data
 Lionel M 2                     short data
 Ted        3                     long data, blah, blah word
                                      wrap, lorem ispsum doloret
                                      ma Pete non dolet.
 Bruce    4                     long data, blah, blah word
 Willis                             wrap, lorem ispsum doloret
                                      ma Pete non dolet.

when the name of number one is really "Eleonora Battista Almeire", number 2 "Lionel Mamane" and number 3 just "Ted". As a short prefix of the name is all that one needs to disambiguate between rows, one does not want to waste space (neither horizontal, nor vertical) to show full name, so that the rows take as many lines as the data needs. Short data -> one line even if name is long, and long data -> many rows even if name is short. If many rows anyway, *do* use the extra space for word-wrapping the name.

I don't quite see a way to achieve that with LibO, but at least we can put a per-row (instead of per-control) choice, which is already better than the current.

So, really, it should be an option. The *default* state of that option could be "enabled", that's up for discussion.
Comment 8 sasha.libreoffice 2012-03-21 22:12:39 UTC
Thanks for additional explanations and examples

> FWIW, in MS Access, one can choose this kind of thing per-control (AutoGrow and
> AutoShrink). This allows to do e.g.
It makes sense to reuse user's knowledge. If user learned something useful in one program, IMHO it is useful to allow to him/her use it in another program.

Now we have enough knowledge about how this should be. Let we see how it will be implemented.
Thanks for idea. And thanks in future for implementing.
Comment 9 Lionel Elie Mamane 2012-06-18 05:45:00 UTC
*** Bug 40229 has been marked as a duplicate of this bug. ***
Comment 10 Lionel Elie Mamane 2012-06-18 05:56:26 UTC
As a temporary work-around, one can use the following macro to open a report and put every row to autoheight:


	Dim rpt as Object
	rpt = ThisDatabaseDocument.ReportDocuments.getByName(rptName).open

	Dim tbls as Object, tbl as Object
	tbls = rpt.getTextTables()

	dim j as Integer
	for j = 0 to tbls.count() - 1
		tbl = tbls.getByIndex(j)
		if Left$(tbl.name, 6) = "Detail" then
			Dim rows as Object, col as long
			rows = tbl.Rows
			dim i as integer
			For i = 0 to rows.count - 1
				dim row as Object
				row = rows.getByIndex(i)
				row.IsAutoHeight = True
			Next i
		endif
	next j
Comment 11 Ralph Peters 2012-06-20 07:43:53 UTC
It would really be nice if this "bug" could be fixed in the report builder!  For me, it would convert Report Builder into something usable!  Please push this to the top of the list of things that need to be fixed.
Comment 12 Robert Großkopf 2012-07-31 10:05:51 UTC
*** Bug 50105 has been marked as a duplicate of this bug. ***
Comment 13 Björn Michaelsen 2013-10-04 18:47:33 UTC
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Comment 14 Michal Strnad 2014-03-19 10:12:31 UTC
Hello,

I am starting work on this bug.
Comment 15 Lionel Elie Mamane 2014-04-03 14:05:36 UTC
(In reply to comment #14)
> I am starting work on this bug.

Hi. How is the work going? Do you have any draft? Do you need any help / review / pointer?
Comment 16 Michal Strnad 2014-04-13 22:33:03 UTC
Hello,

I have some questions about this bug. I will try describe them here or 
on IRC tomorrow.

Sorry for the delay

Michal Strnad


On 3.4.2014 16:05, bugzilla-daemon@freedesktop.org wrote:
>
> *Comment # 15 <https://bugs.freedesktop.org/show_bug.cgi?id=45789#c15> 
> on bug 45789 <https://bugs.freedesktop.org/show_bug.cgi?id=45789> from 
> Lionel Elie Mamane <mailto:lionel@mamane.lu> *
> (In reply tocomment #14)
> > I am starting work on this bug.
>
> Hi. How is the work going? Do you have any draft? Do you need any help / review
> / pointer?
> ------------------------------------------------------------------------
> You are receiving this mail because:
>
>   * You are the assignee for the bug.
>
Comment 17 Lionel Elie Mamane 2014-04-14 05:05:05 UTC
(In reply to comment #16)

> I have some questions about this bug. I will try describe them here or 
> on IRC tomorrow.

I won't be on IRC (travelling for vacation), but if you have general questions, you may find good help there. For Base-specific or this-bug-specific questions, please post them as comments to this bug, I'll try to check this bug from time to time.
Comment 18 Lionel Elie Mamane 2014-05-20 10:12:57 UTC
Michal? Any news on your work on this bug? Any question? Do you still intend to work on it?
Comment 19 Jacob 2014-06-03 23:16:41 UTC
Is this still being worked on?  I'm honestly really surprised it's not a feature, it would make the reporting engine so much more useful.
Comment 20 Lionel Elie Mamane 2014-08-11 10:35:53 UTC
No answer from assignee -> marking as available again
Comment 21 jeyli 2014-08-29 11:12:06 UTC
Hi,
I am trying to work on this Bug but I don't know where to start. Maybe you can help me and tell me in which file I have to look for.
Comment 22 Lionel Elie Mamane 2014-08-29 11:58:27 UTC
To add the property "AutoGrow" to controls, you need to add it:

1) To the file format in reportdesign/source/filter/xml/
   (probably xmlReportElementBase.* or xmlReportElement.*)

2) To the actual in-memory "model" (implementation) of controls:
   I suggest you start with
   Formatted field: reportdesign/source/core/api/FormattedField.cxx
                    reportdesign/source/core/inc/FormattedField.hxx

3) Have the actual treatment (generation) of the report take these
   into account. The treatment happens in
   reportbuilder/java/org/libreoffice/report/
Comment 23 Lionel Elie Mamane 2014-08-29 12:03:40 UTC
For an example of a commit that added a new property (albeit not to controls, the the report as a whole), see http://cgit.freedesktop.org/libreoffice/core/commit/?id=4178806bb010129f3b13b62825476666fe48ddcd

It shows e.g. how to add a new token to the XML format.
Comment 24 Lionel Elie Mamane 2014-08-29 12:13:08 UTC
The reportbuilder creates an odt file (OpenDocument text), but not through Writer. It creates the XML directly and *then* starts writer on it for display / print / etc.

When working on it, I've found the ODF reference a good help to understand what is being generated and what needs to be generated. https://lists.oasis-open.org/archives/tc-announce/201201/msg00001.html

Here, in particular, we are generating tables http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1415580_253892949
Need to find how in the XML a table row with automatic height is coded. To find out that kind of things, create an odt document with writer, with a table. Save it. Then make *one* change, namely changing *one* row to "automatic height". Save it under a different name. Compare the two documents (that is, the XML that is within the ZIP structure). xmlindent is your friend. Most probably one attribute is added/changed in the <table:table-row> element.

That's the result you need to produce in ReportBuilder when the "AutoGrow" feature is on.
Comment 25 Lionel Elie Mamane 2014-08-29 12:16:58 UTC
The code that creates a new row seems to be

 private void startRow(final AttributeMap attrs)

in reportbuilder/java/org/libreoffice/report/pentaho/output/text/TextRawReportTarget

look where/how this is called. The decision to apply "automatic height" or not will most probably be in the/a caller of this startRow (or their caller). Thread.dumpStack() is your friend :)
Comment 26 Lionel Elie Mamane 2014-08-29 12:23:35 UTC
Finally, the *UI* for handling properties of controls is apparently in  reportdesign/source/ui/

You can look at how the other properties are handled there.
Comment 27 Lionel Elie Mamane 2014-08-29 12:24:38 UTC
These pointers should hopefully get you started. Let me know if you run into difficulties or have other questions. Because of the LibreOffice conference, I might be less avaible from 2 to 7 September.
Comment 28 jeyli 2014-08-29 12:27:55 UTC
Thank you for the information!
I'll try it on monday
Comment 29 jeyli 2014-09-01 09:11:15 UTC
I think this bug is too difficult for me yet, so I'll take an easier bug first to learn more about libreoffice. :)
Comment 30 Omar Syed 2014-11-10 23:36:25 UTC
Don't worry guys.  I got this
Comment 31 Lionel Elie Mamane 2014-12-18 15:55:50 UTC
(In reply to Omar Syed from comment #30)
> Don't worry guys.  I got this

I look forward to reviewing your patch ! Let me knwo when it, or a draft of it, is ready.
Comment 32 Alex Thurgood 2015-01-03 17:41:20 UTC Comment hidden (no-value)
Comment 33 Zlatko Kostadinow 2015-02-19 15:03:24 UTC
I was not able to reproduce this bug with the example database and the source code at commit 5d388443b9809e73202ce551bcffa10d442094ca from 12 Feb 2015. Is it still up-to-date or it was fixed?
Comment 34 Lionel Elie Mamane 2015-02-19 15:29:30 UTC
(In reply to Zlatko Kostadinow from comment #33)
> I was not able to reproduce this bug with the example database and the
> source code at commit 5d388443b9809e73202ce551bcffa10d442094ca from 12 Feb
> 2015. Is it still up-to-date or it was fixed?

This enhancement request is still pending.
Comment 35 lukas.mentel 2015-04-30 12:45:39 UTC
Hello,
I want to work at this bug, but I fear I need help :)
Please sorry my bad english.
Comment 36 Lionel Elie Mamane 2015-04-30 12:49:05 UTC
(In reply to lukas.mentel from comment #35)
> Hello,
> I want to work at this bug, but I fear I need help :)
> Please sorry my bad english.

Please read particularly comments 22 to 26. Then come back to me with any question or difficulty you have.
Comment 37 lukas.mentel 2015-04-30 18:59:38 UTC
How can I execute logerrit? If I try the command ./logerrit setup, the computer asks for an app to open (Windows 8.1).
Comment 38 Lionel Elie Mamane 2015-04-30 20:10:12 UTC
(In reply to lukas.mentel from comment #37)
> How can I execute logerrit? If I try the command ./logerrit setup, the
> computer asks for an app to open (Windows 8.1).

Hmm... I'm not using Microsoft Windows, so I suggest you ask on the mailing list or on IRC.
Comment 39 derrick rocha 2015-08-09 22:09:36 UTC
Is this still an issue?  Thanks.
Comment 40 Lionel Elie Mamane 2015-08-10 02:31:27 UTC
(In reply to derrick rocha from comment #39)
> Is this still an issue?  Thanks.

yes
Comment 41 kerem 2015-10-18 18:58:06 UTC
Hello, 

I am starting work on this bug. I want ask questions to you. Please can you help me? 

First of all, I don't know where the start. Also will i work any code files? 

Thank you for your suggestion.
Comment 42 Lionel Elie Mamane 2015-10-18 18:59:49 UTC
(In reply to kerem from comment #41)
> Hello, 
> 
> I am starting work on this bug. I want ask questions to you. Please can you
> help me? 
> 
> First of all, I don't know where the start. Also will i work any code files? 
> 
> Thank you for your suggestion.

Please read particularly comments 22 to 26. Then come back to me with any question or difficulty you have.
Comment 43 kerem 2015-10-19 17:31:31 UTC
(In reply to Lionel Elie Mamane from comment #42)
> (In reply to kerem from comment #41)
> > Hello, 
> > 
> > I am starting work on this bug. I want ask questions to you. Please can you
> > help me? 
> > 
> > First of all, I don't know where the start. Also will i work any code files? 
> > 
> > Thank you for your suggestion.
> 
> Please read particularly comments 22 to 26. Then come back to me with any
> question or difficulty you have.

In comment 24, reportbuilder creates an odt file, not through Writer. I can't this. How to create odt file?
Comment 44 Lionel Elie Mamane 2015-10-20 05:48:25 UTC
(In reply to kerem from comment #43)
> In comment 24, reportbuilder creates an odt file, not through Writer. I
> can't this. How to create odt file?

An ODT file is basically a ZIP structure with XML in it.

In reportbuilder, the Java top-level class that does the process seems to be in file
reportbuilder/java/org/libreoffice/report/pentaho/output/text/TextRawReportTarget.java
(in combination with the external jfreereport), but that is not where you will need to intervene, but in the code that creates a table row.

The code responsible for a cell is basically
reportbuilder/java/org/libreoffice/report/pentaho/layoutprocessor/TableCellLayoutController.java

My original idea was to find the code responsible for a row and inject the attribute for "fit to size" row height there. However, now that I take a fresh look at it, I realise that the <table:table-row> tags are probably copied unchanged from the report definition. So it might be easier to change the way the report definition is saved rather than the way it is processed.

The saving of the report definition happens in C++, in reportdesign/source/filter/xml/
I think it is particularly in reportdesign/source/filter/xml/xmlExport.cxx
function void ORptExport::exportContainer(const Reference< XSection>& _xSection)
looks relevant; need to set the right attribute or style for "automatic height" there.
Comment 45 kerem 2015-10-23 15:20:11 UTC
(In reply to Lionel Elie Mamane from comment #44)
> (In reply to kerem from comment #43)
> > In comment 24, reportbuilder creates an odt file, not through Writer. I
> > can't this. How to create odt file?
> 
> An ODT file is basically a ZIP structure with XML in it.
> 
> In reportbuilder, the Java top-level class that does the process seems to be
> in file
> reportbuilder/java/org/libreoffice/report/pentaho/output/text/
> TextRawReportTarget.java
> (in combination with the external jfreereport), but that is not where you
> will need to intervene, but in the code that creates a table row.
> 
> The code responsible for a cell is basically
> reportbuilder/java/org/libreoffice/report/pentaho/layoutprocessor/
> TableCellLayoutController.java
> 
> My original idea was to find the code responsible for a row and inject the
> attribute for "fit to size" row height there. However, now that I take a
> fresh look at it, I realise that the <table:table-row> tags are probably
> copied unchanged from the report definition. So it might be easier to change
> the way the report definition is saved rather than the way it is processed.
> 
> The saving of the report definition happens in C++, in
> reportdesign/source/filter/xml/
> I think it is particularly in reportdesign/source/filter/xml/xmlExport.cxx
> function void ORptExport::exportContainer(const Reference< XSection>&
> _xSection)
> looks relevant; need to set the right attribute or style for "automatic
> height" there.

Okey I understand. So I change something in function void ORptExport::exportContainer(const Reference< XSection>&_xSection). I change that about the "automatic height", is true? In addition to, are there any your suggestions? 

Thank you.
Comment 46 Robinson Tryon (qubit) 2015-12-13 10:16:32 UTC Comment hidden (obsolete)
Comment 47 kerem 2015-12-17 11:46:32 UTC
I sent following patch for this bug;

https://gerrit.libreoffice.org/#/c/20751/
Comment 48 kerem 2016-01-24 21:55:47 UTC
I sent following new patch for this bug;

https://gerrit.libreoffice.org/#/c/21761/1
Comment 49 Lionel Elie Mamane 2016-01-30 13:26:35 UTC
(In reply to kerem from comment #45)
> (In reply to Lionel Elie Mamane from comment #44)

>> The saving of the report definition happens in C++, in
>> reportdesign/source/filter/xml/
>> I think it is particularly in reportdesign/source/filter/xml/xmlExport.cxx
>> function void ORptExport::exportContainer(const Reference< XSection>&
>> _xSection)
>> looks relevant; need to set the right attribute or style for "automatic
>> height" there.

> Okey I understand. So I change something in function void
> ORptExport::exportContainer(const Reference< XSection>&_xSection). I change
> that about the "automatic height", is true? In addition to, are there any
> your suggestions? 

Sorry it took me so long to answer. Basically, yes, that is my guess, but that is about step 3 from comment 22. We also (first?) need to do steps 1 and 2 from comment 22. See also comment 24 and comment 26.

To summarise: the work is to add a property "AutoGrow" to every control. It needs to be added to the control models and to the UI that allows to user to set that property. Then, in RptExport::exportContainer, if any of the controls of this row has "AutoGrow" set to true, then set the "automatic row height" attribute" on the whole row.

Code pointers are in comment 22, except that in step 3, the code pointer is probably wrong and should be replaced by what I say in comment 44. Steps 1 and 2 are still valid. Sorry for the mixup.
Comment 50 Robinson Tryon (qubit) 2016-02-18 14:52:28 UTC Comment hidden (obsolete)
Comment 51 Alex Thurgood 2017-12-11 12:02:10 UTC
*** Bug 114387 has been marked as a duplicate of this bug. ***
Comment 52 gdahefferman 2017-12-11 17:10:18 UTC
Thank you Alex for spotting and e-mailing me that my enhancement Bug 114387 has already been submitted as 45789. I apologize for any inconvenience caused.
Comment 53 Howard Johnson 2018-03-05 20:21:18 UTC
*** Bug 116210 has been marked as a duplicate of this bug. ***
Comment 54 Howard Johnson 2018-03-06 16:09:29 UTC
Created attachment 140395 [details]
another, larger database to demo this bug

6 years, 16 volunteers, 4 duplicates, tough bug!  (-: My attachment here today is a more comprehensive Base report to further demo this issue. :-)


1) I think we might be starting with the wrong bug.  

No really, the more important bug I think, is that the LO source code is mostly too hard to work on.  

I have myself begun to study the source base, but in most places it lacks the most basic comments to help the unfamiliar figure out how it works, to be able to read the code to even work on bugs like this.  

(A few years go by and I can't even read my own code without a few comments to refresh my memory.  And as we all get older, this issue gets worse.)

So what I think is needed _first_, is to work together (or alone) to start to add sufficient comments to the code base to help new coders find their way around.  One needs to be able to read the code without going to an extreme amount of work.  

I am willing to help with such an effort, as I begin to try and read the code myself.  (Please see more specific question about this below.)


2) As for THIS bug, and having used database report writers (plural) with CanGrow and CanShrink type features, I am definitely of the opinion that BOTH of these properties are required, not just AutoGrow, and need to be added to all controls.

The reason for CanShrink is that if no data is in group, it is often desirable to fully collapse the group, so as to save paper space where it's not needed.  But this can only reasonably work if CanShrink is also available.  In this case you would set the can-shrink on all fields in the group, and also on the group itself.

Furthermore, I think it would make no sense to fix only half of this problem, and to miss the other half, especially when it is so hard to do, and these are so closely related.


3) Finally, and sadly, the Base report writer, as it is, is extremely slow.  Just try to produce a report with 100 pages sometime.  It takes forever.

So I think any work done on #1 or #2 above should keep a watchful eye on someday re-writing the slower parts, (or the whole thing) to be faster.  For one, I can see from the above comments that Java is involved.  At a minimum I think that it someday needs to get rewritten in some flavor of C, as I have found java to sometimes be slow.


SUMMARY: So my point #1 above (call for code comments), becomes even more important in the long haul: It will help fix things now, and make things faster in the future.


MY QUESTION: Are code comment-only commits (i.e. comments w/o any code changes) welcome to the powers that be here?

I realize that the people who wrote this are probably long gone, so any comments will only try to recapture some of what was in their heads, and comments will definitely be a work in progress, so some tolerance for not getting them right the first time would be appreciated.

Also my call for comments is not just about this bug.  It appears to me that there are a whole backlog of Base bugs that are in the category of:  Given the volunteer time we have available, 'too hard' to fix right now.


Can I get a green light to start to add comments to the code to make it more readable, AND if yes, is there some community tolerance for how this is to be done, as any comments might be better than none?  

I have some particular commenting styles I've developed over the years, but even I don't always stick to my commenting styles.  :-)  For one I never like processing comments into documentation, so I don't do that.  Comments I think are to help engineers read the code, period.

Thanks.


____________
I'm so independent that I often won't do what I put on my own to-do list.  :-~
Comment 55 Ulf Zibis 2018-03-07 00:18:45 UTC
(In reply to Howard Johnson from comment #54)
> MY QUESTION: Are code comment-only commits (i.e. comments w/o any code
> changes) welcome to the powers that be here?
> 
> I realize that the people who wrote this are probably long gone, so any
> comments will only try to recapture some of what was in their heads, and
> comments will definitely be a work in progress, so some tolerance for not
> getting them right the first time would be appreciated.
> 
> Also my call for comments is not just about this bug.  It appears to me that
> there are a whole backlog of Base bugs that are in the category of:  Given
> the volunteer time we have available, 'too hard' to fix right now.
> 
> 
> Can I get a green light to start to add comments to the code to make it more
> readable, AND if yes, is there some community tolerance for how this is to
> be done, as any comments might be better than none?  
> 
> I have some particular commenting styles I've developed over the years, but
> even I don't always stick to my commenting styles.  :-)  For one I never
> like processing comments into documentation, so I don't do that.  Comments I
> think are to help engineers read the code, period.

Hi Howard,
I appreciate your offer.
I'm not one of the deciders here, I just like to comment, that it might be better to open a new bug fot this. You might have more readers then.
Comment 56 Lionel Elie Mamane 2018-03-07 06:33:08 UTC
(In reply to Howard Johnson from comment #54)

> No really, the more important bug I think, is that the LO source code is
> mostly too hard to work on.  

> MY QUESTION: Are code comment-only commits (i.e. comments w/o any code
> changes) welcome to the powers that be here?

I expect so. I expect the right place to discuss that is the development mailing list at https://lists.freedesktop.org/mailman/listinfo/libreoffice


> 2) As for THIS bug, and having used database report writers (plural)
> with CanGrow and CanShrink type features, I am definitely of the opinion
> that BOTH of these properties are required, not just AutoGrow, and need
> to be added to all controls.

Yes, the way I was suggesting this to be implemented is actually equivalent to setting both "CanShrink" and "CanGrow". Setting it per-row can be done relatively easily with the current infrastructure. Setting it per-control requires a deeper redesign of report builder, or a new feature in ODT/Writer. Report builder now "just" creates an ODT document, and Writer does all the actual layouting. So per-control would require that *Writer* support the feature of "autogrow" (which it calls "optimal row height") per cell, and not only per row.
Comment 57 Howard Johnson 2018-03-09 00:38:26 UTC
(In reply to Lionel Elie Mamane from comment #56)

> ..the right place to discuss that is the development
> mailing list at https://lists.freedesktop.org/mailman/listinfo/libreoffice

Thanks.


I said  >>...report writer, .. extremely slow

To briefly follow up on this, after days of looking, I just discovered why one of my base reports was so extremely slow saving and reporting, and how to easily fix it.  I'll submit in another bug report.
Comment 58 Heiko Tietze 2018-03-20 10:40:07 UTC
No need for input from UX I guess. Removing the ML from CC.
Comment 59 Ilhan Yesil 2018-04-12 10:19:22 UTC
Hello, 
I want to work on this bug, it looks interesting and will be my second contribution to libreoffice.
Comment 60 Ilhan Yesil 2018-04-25 12:26:05 UTC
Current status: After examination of the code, I added some ids and properties for the new property Autogrow. Now the new property is displayed if a report is in edition and a control is selected.

Next step would be, that I store this property into the file, but I have a question here.

This is how the property of a row is currently generated:

<style:style style:name="Detail.1" style:family="table-row">
<style:table-row-properties style:row-height="0.499cm"/>
</style:style>


If I later manually open the generated odt file and set the row to optimal height, then it is saved without "style:row-height" in this way:

<style:style style:name="Detail.1" style:family="table-row"/>

So how do I save this new property? My suggestions are:
1. Just don't save style:row-height?
2. Add new style property style:autogrow:
<style:table-row-properties style:row-height="0.499cm" style:autogrow="true" />
3. Replace style:row-height with new property:
<style:table-row-properties style:autogrow="true" />
4. Write "autogrow" into style:row-height
<style:table-row-properties style:row-height="autogrow"/>
5...?

I would also like to know, if there are naming conventions to concern if autogrow is introduced here in this xml formatted file?
Comment 61 Lionel Elie Mamane 2018-04-25 12:54:58 UTC
(In reply to Ilhan Yesil from comment #60)
> Current status: After examination of the code, I added some ids and
> properties for the new property Autogrow. Now the new property is displayed
> if a report is in edition and a control is selected.

Great progress!

> Next step would be, that I store this property into the file, (...)

> So how do I save this new property?

style:use-optimal-row-height="true"

See http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1420232_253892949
Comment 62 Ilhan Yesil 2018-05-08 11:29:47 UTC
style:use-optimal-row-height is saved now.

-<style:style style:name="ro4" style:family="table-row">
<style:table-row-properties style:use-optimal-row-height="true" style:row-height="0.499cm"/>
</style:style>

But if i reopen the report for edit, the property is false.

Is the property saved somewhere else then in content.xml? I debugged the code while it is importing content.xml and other sections of the code. The property "use-optimal-row-height" is parsed correctly, but how this information is to deliver to the control? 

I need an advice please.
Comment 63 Lionel Elie Mamane 2018-05-08 11:44:46 UTC
(In reply to Ilhan Yesil from comment #62)
> style:use-optimal-row-height is saved now.

Great.

> But if I reopen the report for edit, the property is false.
> 
> The property "use-optimal-row-height" is parsed correctly, but how this
> information is to deliver to the control?

Change the parser to apply the autogrow property you created to each affected control, that is each control of this row.

Would it be possible to see your "in progress" code? Maybe I could be more specific upon seeing it.
Comment 64 Ilhan Yesil 2018-05-08 12:33:57 UTC
I've submitted my current incomplete status for a review.

https://gerrit.libreoffice.org/#/c/53977/
Comment 65 Ilhan Yesil 2018-05-09 12:56:26 UTC
I solved it, the flag "AutoGrow" is now read. I uploaded a new patch set.

My next step would be to work on the JAVA code. I've here a problem. When I open the report, the fields are filled like this:

<text:p text:style-name="P1">Any[Type[com.sun.star.sdbc.XClob], com.sun.star.bridges.jni_uno.JNI_proxy@1f543bd9 [oid=1e56ce2f880;mscx[0];e442f7c441644aebaca2a57af370d4f1, type=com.sun.star.sdbc.XClob]]</text:p>

I think it has to do with the firebird driver, but I've not found what to do. With the installed version 6.0.3.2 there is no problem. I'm working on a Windows 10 machine.
Comment 66 Robert Großkopf 2018-05-09 14:02:39 UTC
(In reply to Ilhan Yesil from comment #65)
> 
> I think it has to do with the firebird driver, but I've not found what to
> do. With the installed version 6.0.3.2 there is no problem. I'm working on a
> Windows 10 machine.

Don't try to solve Firebird-bugs with workarounds here. If you could solve the problem for the internal HSQLDB we must have a look what's going wrong with Firebird an reports.

Great there is somebody who tries to solve this problem of automatic row-height.
Comment 67 Lionel Elie Mamane 2018-05-09 14:26:44 UTC
(In reply to Ilhan Yesil from comment #65)
> I solved it, the flag "AutoGrow" is now read. I uploaded a new patch set.
> 
> My next step would be to work on the JAVA code. I've here a problem. When I
> open the report, the fields are filled like this:
> 
> <text:p text:style-name="P1">Any[Type[com.sun.star.sdbc.XClob],
> com.sun.star.bridges.jni_uno.JNI_proxy@1f543bd9
> [oid=1e56ce2f880;mscx[0];e442f7c441644aebaca2a57af370d4f1,
> type=com.sun.star.sdbc.XClob]]</text:p>
> 
> I think it has to do with the firebird driver, but I've not found what to
> do. With the installed version 6.0.3.2 there is no problem. I'm working on a
> Windows 10 machine.

Is this a problem that is introduced with your patch, or does it also happen without your patch? If it exists without your patch, that's a separate problem/bug, I would recommend the same as Robert: 

My guess is that this is because a column of the database you try has a "Memo" (very large text / Character large object) type. Do your tests with plain integer / varchar / char columns and you should not see this problem, which will allow you to concentrate on this enhancement here.

(If afterwards, you want to solve the CLOB bug as a separate work, that's not refused) :)
Comment 68 Ilhan Yesil 2018-05-09 15:36:09 UTC
(In reply to Lionel Elie Mamane from comment #67)
Windows 10 machine.
> 
> Is this a problem that is introduced with your patch, or does it also happen
> without your patch? If it exists without your patch, that's a separate
> problem/bug, I would recommend the same as Robert: 

No, it's not introduced with my patch, I saw this also before coding. I used your sample database for the test.
Comment 69 Ilhan Yesil 2018-05-11 15:36:43 UTC
My code compiles on Windows 10 (MSVC 2015, cygwin), but after each commit I get this:

CommandLine Error: Option 'disable-symbolication' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options

Seems it has to do with clang-format. Because of this, I've no last code check before I submit to loggerrit. On jenkins I had some build errors, I assume it has to do with this missing code check. Can someone give me hints?
Comment 70 Ilhan Yesil 2018-05-16 14:30:14 UTC
Sorry, i agree it was not suitable to put my last question here.

I think it works now as required.
Comment 71 Ilhan Yesil 2018-05-17 07:04:37 UTC
With the last patch submitted it works now. It was not necessary to touch Java code. 

https://gerrit.libreoffice.org/#/c/53977/
Comment 72 Xisco Faulí 2018-06-17 02:41:25 UTC Comment hidden (obsolete)
Comment 73 Xisco Faulí 2018-07-18 02:37:10 UTC Comment hidden (obsolete)
Comment 74 Xisco Faulí 2018-08-18 02:37:17 UTC Comment hidden (obsolete)
Comment 75 Xisco Faulí 2018-09-18 02:47:57 UTC Comment hidden (obsolete)
Comment 76 Xisco Faulí 2018-10-19 02:48:51 UTC Comment hidden (obsolete)
Comment 77 Xisco Faulí 2018-11-19 03:37:57 UTC Comment hidden (obsolete)
Comment 78 Xisco Faulí 2018-12-20 03:54:05 UTC Comment hidden (obsolete)
Comment 79 Xisco Faulí 2019-01-20 03:45:20 UTC Comment hidden (obsolete)
Comment 80 Xisco Faulí 2019-02-20 03:45:49 UTC Comment hidden (obsolete)
Comment 81 Xisco Faulí 2019-03-23 03:15:39 UTC Comment hidden (obsolete)
Comment 82 Xisco Faulí 2019-06-26 09:08:39 UTC
Dear Ilhan Yesil,
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assigned it back to yourself if you're still working on this.