On 5 Jul 2024, at 12:47, John Skilleter wrote:
A number of things seem to have broken with regard to chart layout in
version 3.1.4 (and later).
There are no relevant changes in the code, as you can confirm by comparing the generated XML.
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Sengelsweg 34
Düsseldorf
D- 40489
Tel: +49-203-3925-0390
Mobile: +49-178-782-6226
On 5 Jul 2024, at 16:29, John Skilleter wrote:
I agree that it is an Excel bug - LibreOffice Calc is happy with either
file.Unfortunately, my managers like Excel, warts and all.
If it's still the case with 3.1.5, I'd suggest you monkey patch the code. LibreOffice does something similar, so it should be possible to include something with the full version number, which is supposed to make debugging easier. But at the moment I don't the time to try out all the possibilities and I'd rather pull all my teeth out. But it is possible that 3.1.5 actually fixes it. If not, maybe you're
I seem to remember seeing something like this years ago, which is why I left things as they were. But it really is useful to be able know exactly which version is in use. And it really is a completely stupid bug by Microsoft. Fortunately, the Office team has actually been fairly receptive to bug reports: I have the impression that those working there now hate some of the design and implementation decisions taken years ago. Overloading CustomFilter's operators with a secret code springs to mind and we know they have no formal validators for the various parts of the specification done in BNF.
I'd, and I think the world, would be much happier if we had a clear definition of the application name, though it's actually irrelevant as the stuff in [ContentTypes].xml specifies what the documents are. The AppVersion could, in theory, denote a specific version of Excel, except that, of course, OOXML shouldn't differentiate between MS Excel, OpenOffice, Openpyxl or John's Funky Spreadsheet…
On 5 Jul 2024, at 17:27, Charlie Clark wrote:
I seem to remember seeing something like this years ago, which is why I left things as they were.
I've just spent some time playing with various combinations here.
LibreOffice uses the following:
<Properties xmlns:vt="http://schemas.openxmlformats.org/officeDocument/2006/docPropsVTypes" xmlns="http://schemas.openxmlformats.org/officeDocument/2006/extended-properties">
<Template />
<TotalTime>0</TotalTime>
<Application>LibreOffice/7.5.8.2$MacOSX_X86_64 LibreOffice_project/f718d63693263970429a68f568db6046aaa9df01</Application>
<AppVersion>15.0000</AppVersion>
</Properties>
It would be great if we could use this. But you can't. Comparison with the charts is difficult because of the different namespace prefixing.
But things get more interesting if you play around with combinations with Microsoft Excel.
The following works fine for me on Excel for Mac 2019 and Excel for Windows 2016
<Properties xmlns="http://schemas.openxmlformats.org/officeDocument/2006/extended-properties">
<Application>Microsoft Excel</Application>
<AppVersion>3.1.6</AppVersion>
</Properties>
This causes problems as soon as the Application name changes and we dropped the ".6" recently because this was apparently causing problems with some version of Excel.
However, things get even more interesting once you start incrementing the version number. I can go all the way up to 12.X.Y and Excel is happy but anything beyond 13 and the labelling in charts goes to shit..
You can do this easily with the xml by unpacking and playing around with the source, zipping the resource and opening Excel.
Eg.
zip ../fixed.xlsx -r * && open ../fixed.xlsx
This suggests two things: Microsoft keeps a database of Office releases in the executable; or it has some heuristics; or both. Anyone who's done any hacking will know that this sounds like an excellent place to start looking for an unhandled error… though I'd hoped they'd be dealt with by something else by now.
In any case, it suggests that the specification is simply incorrect and should be amended. And Excel's inconsistent behaviour is obviously buggy. I could take this up with the Working Group but they're not very happy with me at the moment with my unfinished bug reports: these are managed using word files… To their credit Microsoft does continue to engage in the process but it is extremely slow.
If people could do some more testing as to what works with particular Office versions, I'd be happy to live with X.Y.Z in the version as I don't envisage going all the way up to eleven, let alone thirteen… even if there is a Spinal Tap sequel! :-D
On 9 Jul 2024, at 18:25, Charlie Clark wrote:
If people could do some more testing as to what works with particular Office versions, I'd be happy to live with X.Y.Z in the version as I don't envisage going all the way up to eleven, let alone thirteen… even if there is a Spinal Tap sequel! :-D
I've spent some more time looking at the chart stuff in detail and have come across some interesting defaults which indicate that the problem really doesn't have anything to do with the version but some obviously very shitty coding in MS Office.
The most important thing is that the version seems to affect how Excel handles the namespace in the chart: as long as the c:prefix is used, everything remains as expected. This is insane, because, in XML, there's no difference between the default namespace and a prefixed one!
This seems to have some additional side-effects:
It's easy to fix the code for charts so that what Openpyxl generates looks like Excel's defaults, and we can then keep the important meta-information, as we like.
I'll see if I can get a bug report submitted to Microsoft as there really is quite a lot for them to think about.
or you patch the package itself, edit file "...\Lib\site-packages\openpyxl\packaging\extended.py" line ~129:
replace:
self.Application = f"Microsoft Excel Compatible / Openpyxl {_version_}"with:
self.Application = "Microsoft Excel"