Fix testing methodology

[TheWilley]

After further research, it seems like the testing methodology was created in vain, as a small yet important detail was glanced over. The testing document explains that we use the data from a Minecraft world to get the contents of a book within a players inventory. The assumption was that the text displayed in the book GUI would be the same within the .dat file located in the world folder. However, the problem is that the book contents is not truncated within the .dat file, it is done on demand when opening the book GUI. This can even be confirmed when looking at Minecraft's source code:

this.cachedComponents = itextcomponent != null ? GuiUtilRenderComponents.splitText(itextcomponent, 116, this.fontRenderer, true, true) : null;

Essentially the text is split into an array of strings in such a way that they'll fit on a single line on a page. Looking in the .dat file itself we can also confirm that the text is in fact not truncated beforehand, as string which should be way out of page bounds are still stored:

Item 6 contains a very long string

The book GUI removes the overflowing text

Unless we modify the Minecraft source code, there is basically nothing that can be done about this. The test is essentially useless, as it effectively compares its own output with itself, which always yields a positive test result. I have made some attempts at a solution (including converting the source code to javascript) but to no avail. The testing methodology may have to be changed if a solution cannot be found. I won't put too much time into this if the solution turns out to be more work than worth.

[PargonX]

this shouldnt effect most books though right?

[PargonX]

what i would do, and dont get angry if it not a good idea i dont know how it works, but see how big the word has to be before it goes over the border, do a check for " if last word length is longer then # " then go to next page

[TheWilley]

This is essentially what is already done: Each line in a Minecraft book has a limit of 114 pixels. The app divides the input text into 'sections' which fit each line. All sections are stored in an array, and since one page fits 14 lines, the app takes 14 of these sections and joins them into a single string again. This process repeats for the entire book. Lastly, the command itself is generated.