Closed pineapplemachine closed 1 year ago
It occurs to me in retrospect that the intention may have been for a cell's v
attribute to always be the same string as belongs in the XML - if that's the case, just let me know and I'm happy revise the PR to follow that convention.
Thanks for the pull request! I'll hopefully get some time this week to go through it.
Unfortunately as I'm not the original developer and have recently assumed maintenance of this project I don't know the original intentions as they were. I'll take a read through and hopefully get this merged and tagged in a release soon.
I submitted #62 which fixes the same problem but in a way that may be more consistent with how the code is structured currently. I would probably recommend merging that one instead of this one? But of course whichever you think is better - if it's possible to get to it this week in any case, that would be great.
Closing this since it was solved in #62 and released in version 1.8.2.
Thanks for the fixes!
See https://bugs.documentfoundation.org/show_bug.cgi?id=155046
Unfortunately the OOXML ECMA-376 spec does not ever seem to explicitly mention what is expected for a
<v>
cell value element within a<c>
cell element wheret="b"
indicates a boolean value type. But it seems that excel4node's writing the text "true" and "false" instead of the text "0" and "1" within<v>
elements representing boolean values is uncommon behavior.With this change, boolean cells now display as expected in LibreOffice Calc and Google Sheets, where previously they did not.
I verified on my system that
npm run test
andnode sample.js && ./validate.sh Excel.xlsx
both run successfully after building.