Hello Regis, Thank you for your questions, I'm happy to clarify some things. Currently, the ReportBuilder graphics module is already implemented in C++ so touching this part of the library is not within the scope of the project.
I have spent the beginning stages of the project running the ReportBuilder through the debugger with the goal of understanding how the library works so I will attempt to explain what I have learned. The part of ReportBuilder that is written in Java is the Pentaho report engine and the code for it is located here. https://opengrok.libreoffice.org/xref/core/reportbuilder/java/org/libreoffice/report/ The Pentaho report engine can be thought of like a filter, it takes a ReportDefinition UNO object and some xml, and outputs an odt document. The odt document that is produced with the Pentaho report engine is what is ultimately displayed in the GUI when you create a report using ReportBuilder. The calls go something like this: ReporBuilder GUI (click Execute Report) -> reportdesign/source/filter/xml/xmlExport.cxx (produces xml with rpt tags) -> used as input along with a ReportDefinition object for the Pentaho Report Engine -> produces an odt document So the goal of the project will be to remove or bypass the code that is located in https://opengrok.libreoffice.org/xref/core/reportbuilder/java/org/libreoffice/report/ and to replace it with a combination of modified code in https://opengrok.libreoffice.org/xref/core/reportdesign/source/filter/xml/xmlExport.cxx and an xslt filter. The why for all of this is simply to remove the Pentaho report engine external dependency from the LibreOffice source code. Hopefully this has been helpful in clarifying the goals of this project and what it is attempting to do. I will be providing weekly updates and hopefully things will become more clear as I get some functioning code. Cheers, Adam Seskunas On Thu, May 22, 2025 at 4:40 PM Regis Perdreau <regis.perdr...@gmail.com> wrote: > Hello Adam and mentors, > > I don't really understand this GSOC, I thought it was about redoing the > reportbuilder graphics module in C++, apparently it's about making a single > command line tool? or exporting files. > Do you have a diagram of understanding and tell the files and directories > impacted. Where in the code are you going to insert your filter and why? Or > is it an external library containing UNO commands? > May be you can provide some https://opengrok.libreoffice.org/ links. > Best > > Régis Perdreau > > > > Le mar. 20 mai 2025 à 21:01, Adam Seskunas <adamsesku...@gmail.com> a > écrit : > >> Hello all, >> >> Just a quick weekly update on implementing ReportBuilder in C++. >> >> Last week I set out to write a very basic xslt filter that could handle >> some straight lines in a report. As this was the first time I had written >> an xslt filter and there was some work needed to get everything set up(file >> locations, python scripts to get input/output, python scripts to automate >> zipping/unzipping odt files, etc.) it took most of the week. The filter >> works and it was a good exercise as some of the work will be used later. >> >> During my weekly meeting with my mentors, there was much discussion about >> what exactly is the input for the xslt filter is and what is the output. >> The goal of the project is to remove the Pentaho Report Engine and the >> companion Java code from the LibreOffice codebase and we wanted to make >> sure that the Pentaho engine was not touching the input for the would be >> xslt filter. It was decided that I should take some time to make sure and >> to really nail down the what the input and output would be. >> >> Which led to my realization, while debugging the ReportBuilder that I >> have had the input and output reversed. In some ways, this makes things >> potentially easier, but also adds some new challenges. It also solves some >> lingering questions I had about how the ReportBuilder functions, which is a >> positive development. >> >> So now my next steps have changed from working on the xslt filter, to >> adapting the existing C++ to place the database data into the input xml. I >> will start to look at how this will be done in detail the rest of the week >> with the hope that it can be implemented in the next two weeks. >> >> That's it for now, thanks for reading, >> Adam Seskunas >> >
