Hello, I am Mattil Asic. I am a software engineer at Kolobora. I just recently joined them.

This is my first conference and I am not very good in English, so forgive me if I say something wrong. I will speak about the footnotes in multi-column sections. I worked on this in last year, a year ago. I thought it can be an interesting problem.

Oh, I have to go back. Ok, so I got a bug ticket to fix and it was a very simple ticket at first sight.

It was only just one line text and the writer displayed it as two pages and while the word was displayed as just one page. Besides the one line text, there was a footnote and its section has two columns and there was a continuous section break.

First I thought it's just a problem about the section break, some might change to a page break or something like that. But that was an instinct. It was a strange thing why the footnote and the column was needed.

If I deleted any of them, then the writer changed to one page and it was ok, but it was changed why it is needed. So I started to debug to find where it's become to page and I found the problem in the layouting calculation.

And there was even a comment about it stating that the footnote container causes to maximize size.

In this case, this function to maximize function will calculate if we have to maximize the column frame, the whole section frame, to the whole page.

And it has several conditions, like is footnote at end and is end note at end. There are checkboxes on the GUI named collect at end of text and collect at end of section for end notes.

They were false in this case. Oh, the hasfollow isn't matter now, it was false in this case too. But there was another function that contains footnote container. I check this function and this function just blindly check if the section have a column frame tried that has a footnote container frame tried.

And if it has one, then it returned the first one it found. So now it seems the function was directly write it like this way.

So the question was why do we want to break a page in this case. I even checked the git who changed it or something like that.

But it was in the very first commit I could reach in the initial import at 2000 year. And nobody changed it. And I was even wonder why this many condition is needed.

Not just the first one I found, but the not collect at end is still needed for it. For this I had to analyze the frames how they work. So I listed the frames related to footnote in some case.

The footnote frame is for one footnote entity. It can contain a text frame. And this can be in a footnote container frame. And that frame contains a list of footnotes.

It's important it's not a two dimensional list. It's just a simple list that it can display. And this footnote container frame can be in a page frame or a column frame.

So what is important in it that the footnote container frame does not really support columns. It's just I could say just one column of footnotes and that's all. But we can put this container frame in any of the column frame we want.

So if we put this container frames in every column frame. Then it will seems like if we support... Oh, sorry. It's like we support multi-columns.

So in one case, we want footnotes like multi-columns as like it in the word. In the other case, we want... If we don't check the collected text, we want the footnote to be at the page end.

In the other case, we want the footnote to be in the columns end. In physical, as we say in the display. And it can be true only if the column end is equal to the page end. So that's why they maximize the size of the column to the page size.

In our case, it's not a good idea because in my test case, there was only one footnote and it doesn't need to be multi-columned. But if we wouldn't do this, what I showed in the previous slide,

there could be a contradiction. Like I made a test document. There is two sections. I checked the collected end of text, which means I want the footnote to be after the section end.

There is two columns at the first section and three columns at the second section. It's very good in this way. But if we would change the collected end of text, we would uncheck this.

I mean, we want all of these footnotes at the end of the page. Then how many columns do we want? How many columns do we want? It's a contradiction. We can't say that two or three because any of them could be wrong.

So what we should need, we should be able to have column children for the container frame because it's not should be, it must be, it just should be like words able to have

indifferent number of columns at page as many as in the text. So we should have the ability for the users to choose how many columns we want in the footnotes.

But we should keep the ability to... That's all? Okay. Sorry. It's almost end.