Development/Calc
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
This page provides an overview of Calc development.
Random ideas
Some random collection of what's to be done in Calc.
Core
Drawing object storage rework
Currently, all drawing objects that can be inserted into Calc are stored with absolute coordinates independently from the underlying sheet geometry. In other words, each drawing object has no clue what cell or cells it overlaps. Each time a row or column changes its height or width, Calc re-calculates the positions of all affected drawing object to adjust for that change for each row height change. However, when the heights of multiple rows change at the same time, Calc has to re-calculate the positions of the objects for each row change. This has a huge performance implication especially when filtering a sheet that contains many drawing objects, since their positions needs to be adjusted for each row height change. Note that cell comments are also drawing objects, and the same issue applies to them.
As you can see, this is terribly inefficient. To rectify this, we need to change how the drawing objects' geometries are stored so that they know the start and end cells that they anchor, and the offsets within those two cells. This way, Calc needs to re-calculate their positions only once after the filtering is complete.
Update: Caolan did a preliminary work on this which is already in the master branch.
Draw border around current selection
We need to draw a distinct border around current selection in order to allow different drag mode than we can currently provide. Right now, we rely on a presence of selected range to trigger a drag, but because of this, dragging of a single cell is a pain. Providing a border to grab and start dragging will improve this situation.
Additionally, having a distinct drag border will allow us to implement right-click dragging for special dragging needs.
Multiple sheet types
Currently, a sheet can only contain data grid where you enter values, formulas etc in a 2-dimensional grid layout. We need to add support for other sheet types, such as chart, to allow charts to be embedded as sheets. This could later be extended to go beyond just the data grid and chart types.
Removal of hacks to reduce cyclomatic complexity
Calc's code contains a fair amount of hacks, or suboptimal designs that unnecessarily increase the complexity of the code. Some examples are:
- branching of code paths by IsImportingXML() call. The core shouldn't need to know whether we are loading a document or not. It's the job of the filter code to call the right method, not the job of the core to do things differently depending on whether it's loading a file or handling user input. Also, using the term 'XML' here is mis-guiding, since this is strictly meant for ODS loading only. And having the core do something special just for the ODS file format is a bad design.
- SetStreamValid() etc for ScTable. This applies to Calc's trick to save the XML stream for a given sheet and re-uses it on export if the sheet is not modified. Again, the core shouldn't need to do anything special just for ODS file stream; ScTable should introduce a 'sheet modified' flag, and tie this functionality to that flag. That would be a more appropriate general approach. Also, investigate the additional lock semantics of this StreamValid flag. That's truly ugly and should be investigated and be removed from the core.
- more to come...
Enterprises love standadized documents layouts and brand logos on the header or footer is a must for their spreadsheets. Today LibreOffice does not allow to insert a graphic in the header or footer of a spreadsheet. To overcome, you have to put it in the header/footer background image with little control on size and position.
Increasing the limit of number of columns from 1024 to 16384
Often we need the ability to load sheets from MS Excel/csv files that have more than 1024 columns in it. MS Excel can open such large column-count files, but in Calc we are limited to loading files with 1024 columns. Refer corresponding bugzilla page here. The columns of a sheet were allocated statically as a plain array of ScColumn's of size MAXCOLCOUNT inside ScTable called aCol. Just altering the definition of MAXCOLCOUNT from 1024 to 16384 has the following two major issues :
- Since we preallocate MAXCOLCOUNT number of columns at the beginning, the memory requirement for even a default empty sheet will increase a lot, independent of how many columns the user is actually going to use.
- Most of the code in methods of ScTable and ScDocument has the following code-pattern in them :
for ( SCCOL nCol = 0; nCol <= MAXCOL; ++nCol )
{
// Does some work on the column aCol[nCol]
}
where MAXCOL is defined as MAXCOLCOUNT - 1. If we increase the MAXCOLCOUNT statically, it would cause these loops to take longer to run even if the user may use only some of the first few columns.
The obvious way to mitigate the above problems is to make the column storage in ScTable dynamic, such that a column is allocated only if it is actually required by the user.
Summary of work that has been done on this front so far :
- A discussion mailing list that led to the ideas to work on this project. This is a good resource for anyone starting out to work in this project.
- Design Minutes from a FOSDEM discussion Eike/Noel/Michael -
- First step in this project was to introduce a dynamic column container using std::vector in ScTable instead of using a plain static array. This was done in this patch. The dynamic container is used in ScTable such that there is minimal change required for other files. But it is still not possible to let this container be dynamic (that is to grow from no columns to the required number of columns on user need), because the code in most places assumes that the container has MAXCOLCOUNT number of columns, so the dynamic container still needs to be initialized with MAXCOLCOUNT number of columns till we fix all places where the "static column container" assumption is made.
- Some side steps were then made to improve some static datastructures used in ScMarkData and ScAttrArray classes to work efficiently with dynamic column container and future column count increase. These were done in two patches a) Refactor ScMarkData for tdf#50916 and b) Refactor ScAttrArray for tdf#50916. They have detailed commit messages.
- A series of patches were made to fix the code where the "static column container" assumption is made. Refer the bugzilla page for complete list.
What to do next ? : We still need to make sure we have fixed all places in table*.cxx and documen*.cxx where the static column container assumption is made. Also we need to implement fixes to various caveats mentioned in the mailing list discussion and the newest comments to tdf#50916.
ODF Import
Unimplemented Chart ODF Elements lists a number of chart ODF elements that have been added for better OOXML roundtripping support but have no implementation besides import and export yet
Unsupported MS Excel Functions
A list of Microsoft Excel functions currently not supported in LibreOffice has been created and is located here: Excel Functions Not Supported in LO.