libxlsxwriter for Clarion

[RaFaeL]

Создание файлов Excel (xlsx) без использования Excel на основе проекта libxlsxwriter (https://libxlsxwriter.github.io). Можно создавать файлы, листы в них, писать данные (текст (в т.ч. русский), число, дата, время), ставить форматирование (цвет, рамки, шрифт, выравнивание, размер), объединять ячейки, фиксировать и скрывать строки и колонки, вставлять изображения, рисовать графики (диаграммы), устанавливать настройки печати и свойства документа.
Для конвертирования "картинок" форматов используется библиотека Tpicture от Taboga, у кого этого класса нет замените на что-то свое

[Yufil]

А нужно '<13,10>' в строке? Попробуй просто '<10>', многим программам и этого хватает...

[RaFaeL]

В библиотеке функция lxw_escape_control_characters меняет коды с 01 по 1F на "_x%04X_". Зачем - не знаю, спросите у автора на гитхабе

[Игорь Столяров]

Попробуй просто '<10>', многим программам и этого хватает...

Конечно попробовал ! Всё вроде бы (!!!) работает.
Но тогда строка с переносом в XLSX не соответствует экселовскому аналогу, что неизвестно где аукнется.

[RaFaeL]

Да, точно. 0A не меняется а 0D меняется. Спросите, почему так, может уберёт строчку эту

[Yufil]

Кларионовский парсер XML в секции CDATA сам превращает '<13,10>' в '<10>', после парсинга приходится вставлять перенос обратно. Скорее всего, это фича парсера

[kreator]

Игорь, а ничего не путаешь? В классическом xml символ '<13>' - '<br />'. У SV в классах есть преобразования специфических символов. Я сделал себе простую функцию преобразования кларионовской строки в xml строку на их основе.

Меня что-то переклинило. XML прекрасно понимает <13> и <10>. В html, наверно, то, что я написал.

[Yufil]

А что значит "XML понимает"? Вот я вывожу XML-файл и в нём фрагмент

Код: Выделить всё

<embed type="100">
<prog><![CDATA[select _hyper22
_document='CH2_1'
_hide=0
select ?Flash28
_hide=1
_fla2=1
_k=1
For _i=1 to 2
  select ?Prompt{_i}
  If _k={_i} 
    _Color=080H
    _FontBold=1
  elsIf _Color=080H 
     _Color=0808080H
  end
End
]]></prog></embed>

Потом парсю файл родным кларионовским парсером. и с удивлением вижу, что в поле <prog> переносы строки <13,10> заменились на <10>

[Игорь Столяров]

OK ! Если все живы, тогда предлагаю от разминки перейти собственно к делу ....
Выполняем код:

Код: Выделить всё

            err#=xlsx.WriteString(1,1,'12345<10>67890')

            Loop j# = 2 to 40
              err#=xlsx.WriteString(j#,1,j#)
            end

Получаем результат:

Современная наука может объяснить содержимое ячейки A1 ?
Уточнение: проблема проявляется только в Apache Calc, в Microsoft Excel - всё OK !
Проблема исчезнет, если уменьшить цикл до 10 ... Класс !

[Игорь Столяров]

Я поясню предыдущий вопрос ... Дело в том, что это не "высосанная из пальца" проблема,
а формализованная демонстрация достаточно серьёзной ошибки.

Первая строчка - это шапка таблицы, в которой есть перенос строк. Цикл - экспорт самой таблицы.
Т.е. валится экспорт любой (!!!) таблицы, в заголовке или шапке которой есть принудительное разбиение на строки.

[kreator]

Я так понимаю - библиотека не гарантирует совместимости созданного файла с другими программами, кроме самого Экселя? А ведь идея - формировать файл без каких-либо доп. средств. В общем, пока грустновато. Может у разработчиков найдётся время для адаптации не под Эксель. А файл с такими наворотами, пересохранённый самим Экселем, читается Калком?

[Игорь Столяров]

библиотека не гарантирует совместимости созданного файла с другими программами, кроме самого Экселя?

Вот это не факт ... Microsoft Excel вполне может просто корректировать некоторые явные проблемы в структуре XLSX файла.
Помните, мы разбирали, что-то подобное, если для строки явно не указана высота ?
Или, если сделать ошибку в структуре XLSX (например пересечение диапазонов MERGE), то Calc - просто клинит,
а Excel выдаёт ошибку, но пытается показать таблицу без проблемной ячейки или области ячеек ...

Да. Главный плюс XLSXWriter - это возможность создавать отчёты без коммерческого офисного пакета Microsoft Office
или платной библиотеки, например, EasyOpenOffice (в которой, кстати, то же есть не решённые проблемы).
Поэтому хотелось бы понять, что происходит. Но вряд ли такой очевидный глюк именно в самом Calc ...

[Дед Пахом]

Если в OO Calc сохранить в формате sxc (примерно то же, что xlsx), то ячейка с переносом кодируется так:

Код: Выделить всё

-<table:table-cell table:value-type="string">
<text:p>Line1</text:p>
<text:p>Line2</text:p>
</table:table-cell>

[Игорь Столяров]

Если в OO Calc сохранить в формате sxc

Да можно проще. Также кодируется перенос внутри ODS если создать его в Calc. Там свой, совсем другой формат.
В XLSX, созданном Microsoft Excel, перенос строки кодируется обычными <13,10> (см. ниже, я об этом писал).
XLSXWriter делает какую-то манипуляцию с заменой этих кодов на служебные символы, и именно здесь что-то и просходит.
Microsoft Excel эту замену понимает, а Calc - нет. Наверно в этой замене есть какой-то тайный смысл, я не знаю ....

[RaFaeL]

В XLSX, созданном Microsoft Excel, перенос строки кодируется обычными <13,10> (см. ниже, я об этом писал).

А как кодируется перенос в xlsx созданном и сохраненном в Calc?

[Игорь Столяров]

А как кодируется перенос в xlsx созданном и сохраненном в Calc?

Традиционный Apache Calc XLSX только читает, а Libre Calc записывает вот так: <si><t xml:space="preserve">12345&#10;67890</t></si>
(перенос между 5 и 6). XLSX файл прикрепляю к сообщению.

Но XLSX файлы созданные в Microsoft Excel, с преносом <13,10> - прекрасно открываются везде ...