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.
Thanks for new idea Please, attach small Database document that demonstrates this problem
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.
Created attachment 58814 [details] wrong result 2
Created attachment 58816 [details] right result
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?
(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?
(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.
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.
*** Bug 40229 has been marked as a duplicate of this bug. ***
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
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.
*** Bug 50105 has been marked as a duplicate of this bug. ***
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
Hello, I am starting work on this bug.
(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?
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. >
(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.
Michal? Any news on your work on this bug? Any question? Do you still intend to work on it?
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.
No answer from assignee -> marking as available again
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.
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/
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.
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.
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 :)
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.
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.
Thank you for the information! I'll try it on monday
I think this bug is too difficult for me yet, so I'll take an easier bug first to learn more about libreoffice. :)
Don't worry guys. I got this
(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.
Adding self to CC if not already on
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.