| Age | Commit message (Collapse) | Author |
|---|
|
Fix special characters in table header
|
|
Fix special characters in pivot table cache definition
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Allow to set cell type to `date`
|
|
Fix worksheet title length enforcement
|
|
Relaxes Ruby dependency to work with Ruby 3
|
|
1. For some reason in MRI 3 the gems tagged as platform RBX in the Gemfile
got installed anyways :/
2. The RBX-specific gems were not compatible to be installed with MRI 3
3. The RBX-3 target was allowed to fail and failed for a while as RVM was
not even able to install that Rubinius version
4. -> Remove RBX from the build matrix solves some problems
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- The previous change caused unnecessary issues
- We approximate that Excel calculates the character length with UTF-16
- Fixes https://github.com/caxlsx/caxlsx/issues/67
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add tests
|
|
|
|
Opposes a redundant test
|
|
We only support Ruby 2.3 and newer (see axlsx.gemspec).
|
|
Fixes CVE-2020-14001
kramdown is not used in the gem itself though, only in development when generating documentation.
|
|
Split examples into separate markdown files, each containing a description, sample code, and a screenshot of the resulting xlsx document.
The script `generate.rb` is provided to actually generate the example documents by executing the sample code contained in the markdown files.
|
|
Update Ruby versions on Travis
|
|
- add 2.7.1
- move every version to latest patches
|
|
|
|
|
|
Previously we tested that either rubyzip or shelling out to zip produced
the expected xlsx file, but we never explicitly checked whether rubyzip
or shell zip was used. I noticed that rubyzip always sets a far future
date, whereas `zip` uses today's date. I'm using this as a heuristic to
determine which zip method was used.
|
|
|
|
|
|
|
|
|
|
Update `Axlsx::Package#serialize` to accept the second argument as a
boolean (being deprecated) or an options hash.
In order to transition toward using keyword arguments for
`Axlsx::Package#serialize`, change the documented method signature to an
options hash, while still parsing the second argument as `confirm_valid`
if a boolean is provided (in which case we also warn the user that a
boolean argument is deprecated).
|
|
Add option to `#serialize` with system zip command
|
|
Add a `:zip_command` option to `Axlsx::Package#serialize` that allows
the user to specify an alternate command to use to perform the zip
operation on the XLSX file contents.
The default zip operation is provided by RubyZip. On large documents
users may experience faster zip times using a zip binary.
Resolves #55
|
|
Back in `1e5388ce`, a rescue block was added to `#test_serialization` to
prevent the test from breaking on boxes where the file system is not
writable. This extra protection doesn't seem necessary anymore, so we
are removing the protection in favor of letting the test error in this
case.
|
|
|
|
Prior to this change, strings like "1e12345" would be interpreted as float values, regardless of the actual value of the exponent (which easily could be out of range for Ruby).
In case the exponent was greater than `Float::MAX_10_EXP` (usually 308), this would result in a cell of type `:float` containing the literal string `"Infinity"`. Excel can not parse such cells and therefore gives a “corrupt data” error.
In case the exponent was less than `Float::MIN_10_EXP` (usually -307) the cell would contain `0.0`. This does not result in Excel throwing an error, but probably isn't the expected result either.
Note that this problem is quite likely to happen when creating a worksheet with hexadecimal strings, because e.g. "1234e567" is a perfectly valid hex value.
The additional range check of the exponent introduces a slight performance overhead, so I decided to split the code path: I presume parsing floats with exponents < 100 (or no exponents at all) is way more common, so this code path behaves exactly like before. Only in the case of a 3 digit exponent the additional range check is introduced.
|
