| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Co-authored-by: Noel Peden <[email protected]>
|
|
On the workbook you can now configure the font_scale_divisor and the bold_font_multiplier to get better results for the automatic cell width calculationb
|
|
|
|
|
|
|
|
|
|
|
|
`gap_width` and `gap_depth` now allow only integers in the range of 0–500. The previous behaviour (requiring a percentage value) was according to the current version of the OOXML spec, but Excel seems to rely on an older version, where the gap amount was required to be a simple integer.
Also, `gapDepth` is only allowed in 3D bar charts, so it is now no longer available for 2D bar charts.
|
|
|
|
|
|
Mimemagic requires users to download or install additional files.
Rails used Marcel as an abstration layer on this library. Marcel
was updated to another file matching database. Following Rails in
this matter will remove the need for users to do additional work,
just to use caxlsx.
|
|
The styles need to actually exist, otherwise the test fails with “ArgumentError: Invalid cellXfs id”.
|
|
|
|
|
|
|
|
|
|
|
|
Deprecate using `#serialize` with boolean argument
|
|
Fix special characters in table header
|
|
|
|
|
|
|
|
Allow to set cell type to `date`
|
|
Fix worksheet title length enforcement
|
|
- 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
|
|
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.
|
|
|
|
|
|
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 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.
|
|
Maximum column width limit in MS Excel is 255 characters https://support.microsoft.com/en-us/office/excel-specifications-and-limits-1672b34d-7043-467e-8e27-269d656771c3
If this value is exceeded, MS Excel gets stuck and doesn't allow column resizing.
|
|
Previously, cells with autowidth sometimes were too narrow for the content to fit.
The original width calculation tried to take the difference between narrow and wide chars into account, but it didn’t work out very well. The new calculation is simpler. Compared to the previous implementation it results in cells being slightly wider in most cases.
|
|
Fixes #37
|
|
Caxlsx used to treat cell values beginning with an equal sign as formula by default.
This can be dangerous if the input data is user generated or coming from other untrusted sources (see https://www.owasp.org/index.php/CSV_Injection for details).
This commit adds a new option `escape_formulas` that can be used with `#add_row` and on instances of `Cell`. If set to true, cell values beginning with an equal sign are treated as normal strings (and will be displayed literally by Excel and co.)
|
|
- `size` returns length in characters, but doesn't factor in multibyte Unicode characters.
By switching to `bytesize`, we check the relevant measure of how many bytes the worksheet name is.
- Fixes https://github.com/randym/axlsx/issues/588
- Copy of PR against original axlsx
(https://github.com/randym/axlsx/pull/589)
|
|
|
|
Also cacle only ids, not entire instances.
|
|
This PR aims to fix several issues with Relationship cache:
1) It's not threadsafe, so I propose to use a TLS variable for this.
2) Memory obtained by cache remains non-freed before the next run of `serialize`. I think it should be freed immediately.
3) Memory should be freed in `ensure` block to prevent memory bloating in case of exception.
*There are only two hard things in Computer Science: cache invalidation and naming things.*
|
|
|
