worksheet page setup modified to follow the same logic of the worksheet properties and to consider all available parameters.
What is proposed here is done keeping compatibility with the previous versions keeping the worksheet.page_setup as the combination of PageSetup and PrintOptions under it.
But splitting the 2 will make code simplier, but will break legacy. Maybe it can be better managed than what I've done.
Small detail I'm not proud of it is the 'untuple' function in page.py module. It has been added to pass a series of tests using saved xlsx files that contains this parameters as tuples. I'm surprised they work correctly because I've the impression they don't follow the schema constraints.
Looks pretty reasonable to me but probably lacking some tests. These can be added to the existing ones by breaking out the relevant XML files from the XLSX files you mention and concentrate only on the relevant tags.
untuple looks fine though it is missing context. And tests.
I'm pretty certain the existing code is hardly in use. I wrote the unit tests myself but only to document existing behaviour. If necessary we can keep the existing names around and issue warnings if they're used.
Quickly implemented an idea of this morning on how to simplify the code just splitting page_setup and print_options at the worksheet level. Still have to add some tests and to modify tutorials concerning this.
Tutorials modified accordingly to new page structure. I've added some few tests. I have the impression that it is sufficient, in fact the way of building page setup and print options made it "obvious". If you provide parameters in a wrong format, you will get immediately an exception. The problem now when you build your worksheet is to know all the available parameters and the way they have to be formatted. Loading an existing workbook will implement correctly all parameters, no more losses of very special parameters that were not present before.
Concerning the new descriptor 'MatchPattern' it will be useful to test another pattern, but I don't think it's useful to imagine one that will have no application in our library. So just add tests whenever a new pattern will be needed.
Thanks, I've merged this. I still don't understand the untuple stuff which I've renamed flatten and looking briefly at the specification it doesn't look necessary. Can you provide an example of where it's required?
Well, I've done this to pass some tests that are using some predefined formats. I mentioned them in a previous message. Just take this out and you will see which are the tests that fails because the value is presented as a tuple with just one value. I agree with you about the fact that this is not required by the specification.
I tested on my side and they pass. I don't have an explanation about it, I just feel stupid. By the way I'm happy it is the case. As I told before I didn't like this workaround. As it is not needed anymore, just throw it away and its related test too. No need to keep this.
Do you want me to do it and propose a new pull request?