Слияние и ширина: MergeCell и SetColWidth

Метод f.MergeCell принимает лист и две ячейки: верхнюю-левую и нижнюю-правую будущего блока — и помечает прямоугольник как один. Вызов f.MergeCell("Отчёт", "A1", "D1") растягивает первую строку на четыре колонки, а тот же метод с координатами A10 и A20 соберёт вертикальный блок из одиннадцати строк — так оформляют боковики и зоны-разделители. Значение живёт в верхней-левой ячейке: Excel рисует его по всей площади блока, а физически остальные ячейки пусты — пишите значение до слияния или после, лишь бы по координате угла. Повторное слияние того же диапазона excelize отклонит ошибкой, как и пересечение с уже объединённым блоком: карта слияний хранится в файле, и библиотека проверяет её перед записью. Снимается слияние зеркально: UnmergeCell с теми же координатами — значение остаётся в углу, остальные ячейки снова становятся обычными. Важно понимать границы операции: слияние не склеивает тексты и не суммирует числа, это про геометрию, а не про данные. Для аудита есть GetMergeCells: вернёт список блоков листа с начальной и конечной координатами, и чужой файл разумно просматривать именно с этой карты.

Плата за красивую шапку приходит при чтении собственного файла. GetRows вернёт текст в первой ячейке блока и пустые строки в остальных: построчный парсер увидит строку, где три ячейки пусты, и решит, что данные кончились. GetCellValue("C1") вернёт пустую строку, хотя на экране Excel показывает заголовок по всей площади блока. Отсюда правило разделения труда: слияния — для декоративных зон, заголовков, подписей и периодов; данные живут по одной ячейке на значение. Шапку объединить можно и нужно, колонку с ценами — не стоит: импорт из урока про чтение ячеек сломается на ровном месте, а поиск причины затянется на вечер. Вертикальные слияния в данных мешают сильнее горизонтальных: колонка категорий, слитая на десять строк, в GetRows выглядит как одна заполненная и девять пустых, и группировка по ней соберёт мусор. Если файлы со слияниями приходят со стороны, первым делом постройте карту блоков через GetMergeCells — парсеру она нужнее самих строк, потому что отличает честные пустые ячейки от пустых внутри объединения.

Метод f.SetColWidth принимает лист, начальную и конечную колонку и ширину — один вызов покрывает диапазон: SetColWidth("Отчёт", "B", "D", 14) задаст ширину трём колонкам сразу, для одной начало и конец совпадают. Единица — не пиксель: ширина столбцов excelize измеряет в символах шрифта по умолчанию, точнее в ширине цифры ноль базового шрифта, поэтому 14 на Calibri и на другом шрифте занимают разное место. Предел — 255 символов, а колонка без явной ширины узкая, около 8.43. Значение пишется в файл и рисуется как есть: библиотека не измеряет содержимое, а в xlsx нет понятия «ширина текста» до открытия файла в Excel. Отсюда и отсутствие автоподбора из коробки: команда «автоширина» живёт в Excel и пересчитывает ширину по факту отображения. В генераторах автоподбор эмулируют: посчитать максимум длины строки в колонке и выставить SetColWidth с запасом — приём в коде ниже.

Высота задаётся SetRowHeight в пунктах: по умолчанию строка около 15 пунктов, шапке с тринадцатым шрифтом ставят 22–26, иначе верхушки букв упираются в границу. С переносом текста из урока про стили есть нюанс: Excel растит строку под переносимый текст сам, но только пока высота не задана вручную — после SetRowHeight автоподбор для этой строки отключается, и длинный текст обрезается. Числа ведут себя иначе текста: когда колонке не хватает ширины, Excel не обрезает значение и не лезет на соседей, а рисует решётки ##### — страдают деньги и даты первыми, у текста есть выход на пустую соседку. Датам формата DD.MM.YYYY из урока про форматы чисел и дат нужно десять символов, а колонка по умолчанию — около 8.43: вот и решётки на первой же выгрузке. Лечение одно: ширину считает генератор по отображаемым значениям, а не надежда, что кто-то потянет границу колонки в Excel.