Hello everyone, I'm Sairper Akdemir and I work for Colobro Productivity. This talk will
be about an interoperability improvement in LibreOffice Impress tables. So this is a
screenshot from the bug report and let's talk about what was the problem on the surface
level. On the right you can see how it appears in PowerPoint and on the left you can see
how it appears when it was opened by Impress, the PPTX file exported by PowerPoint. What
we need to focus here is the rows pointed by the arrows are somehow shrunk when it was
opened in Impress and it wasn't immediately obvious. If we look at how PowerPoint exports
the table layout into PPTX files, what we will realize is it defines row heights. So let's
just focus on that part but it doesn't really define a total table height to fit inside.
While we are importing these row heights what we do is we first calculate what does all
of the row heights add up to because we use the total table height to layout a table.
So we calculate that by adding up each of the row heights and also we assign each row
with their own height. But it turns out when this specific file is exported and if you
look at row heights for the empty rows, they are correct, there is nothing wrong there
but if you look at for instance the one row that says COLA, it appears to have a row height
of zero which doesn't really make sense. So now let's also something to mention here
is if we start typing anything in one of the empty rows, there are no text properties
actually imported from the PPTX file, they are somehow lost in the process like the text
when we start typing in the empty rows in the PowerPoint one, it starts as a blue, it
has a blue color, etc. It has a different size but if we write it in the impressed one,
it is just defaulted so it's black and 18 points. So before understanding the problem
we need to know a little bit about how impressed layouts the table. The table is basically
fitted into a given total height but while doing so we also care for what each row heights
were. So basically we need to know the total height correctly because if it is smaller
than some of the rows, we basically happen to be shrinking, trying to shrink the table.
When that happens, what the impressed tries to do is adjust the row height proportionally
to what were they before and if there is text inside, there is a minimum height it can go
to and when that happens, like in this case when that happens, since it can't shrink
the line that says color further, it shrinks the empty line because it can to try to fit
in that wrong table height. Also, if we explore the PPTX output, we will realize that the empty
cell properties are exported in n-paragraph run properties. We need to import that. There
isn't already an implementation for that but I will discuss this a little bit later.
If you look at the problem in detail, let's say what we need to fix here is we need to
somehow care for these problematic row heights that during import which they don't have
a height of zero but they are defined as so, such. Empty cell, we need to know the text
sizes for empty cells too. We need to do this from n-paragraph run properties. Also, there
was some previous range of pixels here that kind of altered the layouting code instead
of the import code and there are some regressions that messed up some table resizing functionality
there. We need to revert those changes.
So basically, it turns out to be PowerPoint tries to export desired row heights. For instance,
if you try to just pull a row to zero while it has text in it, it doesn't let you do it
but it actually saves it as such. So, in the end, that creates a problem for us. So, to
fix this, what we can do and what I did was during import, before layouting the table
into an area which our impress usually does it, we do a pre-layouting which is we just
take the row sizes and we don't give the layouting code any area to layout into and we let it
layout itself. So, it basically just looks at the row sizes and tries to expand them
if they are smaller than possible. And that gives us a final height that we can use in
successive layouting attempts. So, we kind of correct the total table heights doing that.
And we also don't have the text properties for the empty rows. So, the problem there
was, turns out these text properties are actually imported into text nodes but when
there's new text is being typed, they actually inherit their properties from the cells'
own properties instead of the text nodes. Text nodes are just being dumped and new ones
are being created. So, to fix that, we need to push the text properties from the n-paragraph
run properties into the cells' properties that themselves to make it work correctly.
Well, to finish up, with these fixes, we were able to get rid of the problematic regression
causing code in the layout thing and we moved the conceptual fixes from there into the import
code, making it possible to work correctly. And additionally, some unit tests were added
to make sure the n-paragraph run properties stayed correctly that covered those areas.
Thank you. That's all from me.