Is there (or could there be) a block longer than one page → IN THE COURT starts at the start of 1st page but the end of table is at 2nd page?
The possibility is very rare so we can ignore the condition.
I think I’m starting to understand what problem you’re trying to solve. Correct me if I’m wrong.
So you get a big, very big file with court cases, which should be printed on paper and cut into individual units. Since individual orders often creep from page to page, the corresponding fragments should then be reconnected (glued together?) and at the same time try not to mix up the fragments.
If it is possible to programmatically redistribute all the blocks in the file in such a way that none of the court case would creep onto the next sheet, then firstly the number of cuts would be greatly reduced, and secondly there would be no need to glue the fragments together. This would save time and manual labor. But it would not be possible to greatly reduce the amount of paper used - the blank spaces at the bottom of the page would most likely become smaller, but would not disappear completely.
You still haven’t answered @ajlittoz’ question - how big documents should the macro process? It is important for us to know this in order to choose the right approach to finding a solution. For example, if each such file contains more than a hundred blocks, then recursive enumeration of options should be immediately excluded - for a large number of blocks, the program will simply terminate with the error “Stack overflow”
Yes, we can ignore such situations. But the macro needs to be told exactly what it should do if it encounters such a block. Or if it encounters two such blocks in the file. Or more…
This macro will be used in the entire state of Maharashtra in India everyday. Somedays there might be more than 150 cases on daily board somedays at some places there might be only ten cases. Some people may need to year wise sort the order sheet of the cases and some people will just required that the paper should not be wasted. So I required both types of macros.
Unfortunately, this task cannot be solved - the very fact that the file must be printed on paper means that paper will be wasted. A complete transition to paperless electronic document management can provide real paper savings, but this will not happen today or tomorrow.
The program for redistributing blocks can slightly reduce the amount of manual work on cutting printouts and the consumption of glue, but it will not save paper. Just for example. A file with 150 cases can be printed on 150 sheets, one case per sheet. This will completely eliminate manual work, but will lead to paper waste. If you manage to redistribute the blocks so that each sheet has exactly two cases and one cutting line between them, this will lead to the consumption of 75 sheets of paper and the need to use scissors 75 times. If you leave the file “as is”, all the cases one after another, then it can be printed, for example, on 70 sheets and make 90 cuts and another 20 gluing.
All these numbers are approximate, just to illustrate this idea:
You once said that this file is generated programmatically, you receive it for work already in this form. Perhaps it makes sense to contact the developers of that program so that they change their code and generate the file immediately in the form you need?
@AniruddhaMohod please upload some bigger ODT (>100 tables if you have it) for better testing. My idea to improve the calculations is: the blocks that are longer than half of page don’t need calculations among selfs. And optimally the last block have the dashed line at the start of next page.
I asked one mathamatician for help because I don’t know the mathematical notations on linked Wikipedia. He said me he will take a look on that during this week, so I suppose I will continue after next consultation with him.
Lokadalat Roznama.odt (76.9 KB)
Sending herewith a bigger odt >100 tables.
If there is blank space on page 1 and second block on page 2 is smaller than the blank space on page 1. If we place the second block in place of first block on second page that block used to be automatically shifted to page no. 1
There is a majority of small blocks, have you some document with more longer blocks?
actual text does not really matter, does it ?
you could provide him with a macro logging the block footprint of all files, so you’ll have a full picture of the problem ?
It seems there isn’t any block larger than half of page 
. And also no rare block longer than one page.
I have a full head (and sometimes small headache from big thinking about reduce algorithm) that I don’t want to spent time with the preparation of training ODT. And the better is to have some original data for testing than some artificial ones.
Logging macro could be also possibility , but @AniruddhaMohod had more asks today and I started to lose grasp. So it seems I will probably solve only this algorithm (because it is really very interesting issue).
Unfortunately, you are not working with the original file. @AniruddhaMohod, wanting to make our lives easier - with the best of intentions, repeatedly publishes not the original files, but pre-processed ones. In fact, the original design of these COURT contains a lot of empty space (once @AniruddhaMohod apparently mistakenly published the original tables, but quickly replaced them with compressed ones).
Thus, the source files may contain blocks larger than half a page, and even - very rarely - larger than a whole page.
It’s a pity that we can’t see the original. Perhaps we could understand the reason for the error mentioned here - the source file opens with a message about corrupted data.
If you want the original file which is generated by our software, I can provide it to you. But I started creating macro for removing the blank lines. Now with the help of @KamilLanda I feel whatever I can think @KamilLanda can make it to existence.
You can copy and paste the blocks. You can also copy and paste the contents of the table to make it bigger
@JohnSUN I got idea to calculate the sizes of blocks in mm, it has sufficient accuracy for the blocks, and smaller numbers are well arranged for human.
oVCur.Position uses 1/100mm, but it includes also the space between pages.
So there must be also the detection of this space.
If we place a block of text on the top of page (of course other than first page) and if the block of text is smaller in size than the blank space below the previous page the block will automatically get shifted to previous page. That too because of you. Hope this behaviour will help you in designing the macro.
I finished the macro before few minutes, but I used own new algorithm and I write the documentation. There are some unexpected insidiousnesses in LibreOffice, so I also add the descriptions of ones to documentation. But unfortunately I have backache, so I need more days to finish it.
The blocks can be rearranged so that minimum pages will be required to print.
Uufff! It was hard work. Run macro ReducePages from menu TREEPACKING or module TreePacking. It will open the FilePicker to select the reduced file. Selected file will be copied to new one with suffix -REDUCED.
treepacking-macro-and-documentation.odt (91.6 kB)
Tested file:
tested-file.odt (35.4 kB)
The worst case could occur is MISSING TABLES
that meas not all blocks were pasted to new file.
I hope it will not occur, but I’m not sure I discovered all insidiousnesses.
This is so elegant that it’s almost genius! I sincerely admire the work done!
I hope your health is better now?
. And yes, health is better and I prepare my webpages. Probably in a few days I will finish it.
