fix: preserve template style when using a converter

[HaceraI]

This pull request addresses an issue where pre-existing cell styles from a template are lost when the cell's data is processed by a Converter. I have created a minimal reproducible example to demonstrate the problem.

The Problem

When writing data to an Excel file using a template that contains pre-formatted cells (e.g., with background colors, borders), if a cell's content is handled by a Converter (like LocalDateConverter which applies a date format), the original style from the template is completely overridden. The final cell only retains the new style elements introduced by the converter (typically just the data format), losing all visual styling from the template.

To Reproduce:

I have set up a dedicated repository that clearly demonstrates this issue. It uses a template with a yellow background in cell B2 and writes a LocalDate to it.

• Repository: https://github.com/HaceraI/fastexcel-loststyle-issue
• Steps:
  1. Clone the repository.
  2. Run the test.
  3. Observe that the fonts of columns B and C in the generated Excel file are inconsistent with those of other columns.

Root Cause Analysis

The root cause lies in the interaction between Converter implementations and the FillStyleCellWriteHandler.

1. Most Converter implementations (e.g., for Date, LocalDate) call WorkBookUtil.fillDataFormat() to apply a specific data format.
2. This utility creates a new WriteCellStyle object and sets it on the WriteCellData.
3. Crucially, the originCellStyle on the WriteCellData remains null, as the framework does not automatically capture the cell's existing style from the template at this stage.
4. Later, in FillStyleCellWriteHandler, the handler attempts to merge writeCellStyle (from the converter) and originCellStyle (null). Since originCellStyle is null, the template's style is ignored, and the cell's style is completely replaced by the new style from the converter.

The Solution

To address this, I've made a targeted modification to FillStyleCellWriteHandler.

The new logic introduces a check:

if (originCellStyle == null && writeCellStyle != null && writeCellStyle.getDataFormatData() != null) {
    originCellStyle = context.getCell().getCellStyle();
}

This is a surgical fix that ensures:

• It only intervenes when originCellStyle has not been set.
• It specifically targets scenarios where a Converter has likely added a data format (writeCellStyle.getDataFormatData() != null).
• It safely captures the existing style directly from the POI Cell object before the merge operation.

This approach is minimally invasive and avoids breaking changes to the Converter interface or other utility classes.

[delei]

Could you please provide a unit test case?
能否提供一个对应的单元测试案例?

[HaceraI]

I noticed that the existing test cases seem to address or explain this issue, so perhaps my change is unnecessary?
在测试用例中，我发现似乎存在对该问题的说明及解决方案，也许我的更改是不必要的？

Link

[delei]

Hi, @HaceraI ,thanks for submitting this PR.As for now, this PR has not started review yet.
IMO, if necessary,you can try to improve the unit tests first.If it's just a matter of usage, or this code comment provides a solution.You can decide for yourself whether to close this PR.

感谢提交这个 PR，目前这个还没开始 Review
IMO，如果必要的话，可以先尝试改进单元测试。如果只是使用上的问题，或者代码注释已经提供了解决方案，你可以自行决定是否关闭这个PR。