HotXLS ODS: kaavat ja säännöt Excelille luettaviksi

Tuottaakseen ODS-tiedoston, jonka sekä Excel että LibreOffice lukevat oikein, HotXLS kirjoittaa jokaisen kaavan OpenFormula-syntaksissa esiteltyä of:-nimiavaruutta käyttäen, ja kirjoittaa jokaisen arvo- tai kaavaehdollisen muotoilun kahdesti: <style:map>:nä kunkin katetun solun tyyliin, joka on ainoa muoto, jonka Excel 16 lukee, ja calcext:conditional-formats-lohkona, joka on se muoto, johon LibreOffice luottaa. Kumpikin sovellus ohittaa toiselle tarkoitetun puolen, joten tiedosto, joka näkyy oikein toisessa, ei todista mitään toisesta

Kyseinen viimeinen lause on oppi kuuden HotXLS-julkaisun takana väliltä v2.384.55–v2.384.72. Jokainen korjaus alkoi tiedostosta, jonka HotXLS kirjoitti, luki takaisin täydellisesti ja jonka toinen kahdesta kohdesovelluksesta sai väärin. Seuraavassa on se, mitä kukin sovellus oikeasti hyväksyy, merkintä, joka tyydyttää molemmat, ja HotXLS:n API-kutsut, jotka tuottavat sen Delphistä

Miksi ODS-tiedosto näyttää hyvältä toisessa sovelluksessa ja rikki toisessa?

ODS-tiedosto näyttää hyvältä toisessa sovelluksessa ja rikki toisessa, koska Excel ja LibreOffice lukevat saman paketin eri osia. OpenDocument antaa kaavoille ja ehdollisille muotoiluille useamman kuin yhden laillisen kirjoitusasun, LibreOffice lisää oman laajennusnimiavaruutensa päälle, ja kukin kuluttaja poimii toteuttamansa osajoukon. Yhtä kuluttajaa vasten testattu kirjoittaja suppenee mieluusti merkintään, jonka toinen lukee hiljaisesti väärin

Kumpikaan sovellus ei ilmoita virhettä. LibreOffice näyttää #VALUE!-virheen soluissa, joiden kaavoja se ei osannut jäsentää; Excel avaa työkirjan ehdollinen muotoilu yksinkertaisesti poissa tai kaavana, joka on kirjoitettu uudelleen joksikin, mikä laskee arvoksi #NAME?:n tai vakion 0. Omaa tuotostaan kieräyttävä kirjoittaja ei koskaan näe mitään tästä. HotXLS komastui juuri tuohon ansaan kaavan nimiavaruuden kanssa: sen lukija sovitti of:-etuliitteen pelkkänä tekstinä, joten jokainen oma kierros meni läpi, kun LibreOffice näytti #VALUE!-virheen jokaisessa kaavasolussa

Ominaisuus	Excel 16 lukee	LibreOffice 26.2 lukee
Kokonainen sarake kirjoitettuna A:A	Lukee väärin muodoksi A:(A)	Sietää
Kokonainen sarake kirjoitettuna [.A:.A]	Kyllä	Kyllä
Ehdolliset muotoilut kohteessa <style:map>	Kyllä, ainoa muoto, jonka se lukee	Ohitetaan, kun calcext on läsnä
Ehdolliset muotoilut kohteessa calcext:conditional-formats	Ohitetaan	Kyllä, suosittu
calcext-arvosääntö calcext:operator-attribuutilla	Ohitetaan	Todaan "yhtä suuri kuin 0"
calcext-kaavasääntö kirjoitettuna is-true-formula(...)	Ohitetaan	Todaan arvovertailuna arvon 0 kanssa

OpenFormula ODS:ssä: esittele nimiavaruus, ja hoida sitten syntaksi kohdalleen

ODS-tiedoston kaavasolu on LibreOfficen luettavissa vain, kun table:formulan of:-etuliite ratkaisee esiteltyyn XML-nimiavaruuteen. Etuliite ei ole koristetta. of: kuvautuu osoitteeseen urn:oasis:names:tc:opendocument:xmlns:of:1.2, ja msoxl:, etuliite, jota HotXLS käyttää kaavoille, joita sen OpenFormula-kääntäjä ei mallinna, kuvautuu osoitteeseen http://schemas.microsoft.com/office/excel/formula. Ennen versiota v2.384.56 content.xml-juuri käytti molempia etuliitteitä esittelemättä niitä, eikä LibreOffice pystynyt tunnistamaan kaavakielioppia lainkaan

<!-- Ennen v2.384.56: etuliite käytössä, ei koskaan esitelty; LibreOffice näyttää #VALUE!-virheen -->
<office:document-content xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" ...>
  <table:table-cell table:formula="of:=SUM([.A1:.A3])" office:value-type="float" office:value="245"/>

<!-- Versiosta v2.384.56 alkaen: molemmat kaavanimiavaruudet esitelty juuressa -->
<office:document-content
    xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2"
    xmlns:msoxl="http://schemas.microsoft.com/office/excel/formula" ...>

Nimiavaruuden korjaamisen jälkeen lausekkeen itsensä on silti oltava kelvollista OpenFormulaa, kuten OpenDocument 1.3 Part 4 määrittelee. Ansat ovat paikat, joissa Excelin syntaksi ja OpenFormula näyttävät samalta mutta eivät ole sama:

• Soluviittaukset ovat hakasulkeisia ja pisteen etuliittämiä, ja $-merkit kuuluvat viittaukseen: [.$A$1] ja [.A$1:.$B2] ovat kelvollista OpenFormulaa. Ennen versiota v2.384.55 HotXLS:n kirjoittaja pudotti jokaisen $-merkin, joten absoluuttiset viittaukset palasivat suhteellisina ja menivät pieleen vasta, kun joku kopioi solun
• Kokonaisten sarakkeiden ja rivien on käytettävä hakasulkeista muotoa [.A:.A], [.$A:.$B], [.1:.1], [.$1:.$2]. Paljas of:=SUM(A:A) on LibreOfficen sietämä, mutta Excel 16 avaa sen muodossa =SUM(A:(A)) ja #NAME?-virheellä, ja muuttaa riviviittaukset ja $A:$B vakion 0. HotXLS kirjoittaa hakasulkeisen muodon versiosta v2.384.65 alkaen
• Funktion argumentit erotetaan merkillä ;, ei ,:llä
• Viittausunionit käyttävät ~-operaattoria: Excelin AREAS((A1,B2)) muuttuu muodoksi AREAS(([.A1]~[.B2])). Sen pilkun kääntäminen sen sijaan muodoksi ; muuttaa yhden unioniargumentin kahdeksi argumentiksi
• Inline-taulukot erottavat sarakkeet merkillä ; ja rivit merkillä |: Excelin {1,2;3,4} muuttuu muodoksi {1;2|3;4}. Ennen versiota v2.384.55 HotXLS tuotti muodon {1;2;3;4}, yhden rivin neljää arvoa

Pilkku on vaikea osa, koska yksi Excelin merkki kantaa kolmea merkitystä. Versiosta v2.384.55 alkaen HotXLS:n kirjoittaja seuraa sulkeiden pinoa kääntäessään: ( suoraan nimen jälkeen avaa funktiokutsun, jonka pilkut muuttuvat muodoksi ;; mikä tahansa muu ( on ryhmittelysulku, jonka pilkut muuttuvat muodoksi ~; ja {}in sisällä olevat pilkut ovat taulukon sarake-erottimia. Tuolla ja nimiavaruuskorjauksella LibreOffice 26.2 laski kaikki kahdeksan taulukko- ja unionikoe-kaavaa oikein, mukana INDEX ja AREAS unionien yli

uses
  lxHandleX;

var
  Book: TXLSXWorkbook;
  Sheet: TXLSXWorksheet;
begin
  Book := TXLSXWorkbook.Create;
  try
    Sheet := Book.Sheets.Add('Orders');
    Sheet.Cells[1, 1].Value := 120;
    Sheet.Cells[2, 1].Value := 80;
    Sheet.Cells[3, 1].Value := 45;
    Sheet.Cells[1, 2].Value := 0.2;

    // Kirjoitetaan muodossa of:=SUM([.A:.A]) versiosta v2.384.65 alkaen
    Sheet.Cells[1, 4].Formula := 'SUM(A:A)';
    // Kirjoitetaan muodossa of:=[.A1]*[.$B$1]; $-merkit selviävät versiosta v2.384.55 alkaen
    Sheet.Cells[2, 4].Formula := 'A1*$B$1';

    Book.SaveAsODS('orders.ods');
  finally
    Book.Free;
  end;
end;

Kaavat, joita kääntäjä ei mallinna, palaavat muotoon msoxl:= Excelin tekstin säilyessä muuttumattomana, minkä vuoksi msoxl-esittelylläkin on merkitystä. Nykyisessä kirjoittajassa kyseinen polku kattaa taulukkokohtaiset viittaukset kuten Sheet2!A1 ja jäsennellyt taulukkoviittaukset. HotXLS lukee msoxl:-kaavat takaisin tuonnissa, joten sen oma kierros pitää lausekkeen ehjänä, mutta miten toinen sovellus käsittelee niitä, on kirjoittajan hallinnan ulkopuolella. Jos kaava, josta kuluttajasi riippuvat, tulee ulos msoxl:-etuliitteellä, avaa tiedosto molemmissa sovelluksissa ennen toimittamista

Miksi Excel ei näe vain calcextina kirjoitettuja ehdollisia muotoiluja?

Excel 16 ei näe calcext-ehdollisia muotoiluja, koska se lukee ODS:n ehdolliset muotoilut yksinomaan solutyylien <style:map>-lapsista ja ohittaa calcext:conditional-formats-lohkon kokonaan. Kokeen, joka selvittää asian, tekee lyhyesti: ota LibreOfficen tallentama ODS, poista style:map-elementit, ja Excel lukee nolla sääntöä; poista sen sijaan calcext-lohko, ja Excel lukee yhä kaikki. LibreOffice käyttäytyy toisin päin. calcext on LibreOfficen laajennusnimiavaruus, ei osa ODF-standardia, ja kun calcext-sääntö on läsnä, LibreOffice ottaa sen ja ohittaa style:mapin

Ennen versiota v2.384.69 HotXLS kirjoitti vain calcextia, joten täydellisen hyvin korostava ODS-tiedosto avautui Excelissä ilman arvosääntöjä eikä lainkaan kaavasääntöjä. HotXLS kirjoittaa nykyään molemmat muodot. style:map-puoli käyttää OpenDocument-skeeman ehtokielioppia (ODF 1.3 Part 3), täsmällisillä kirjoitusasuilla, jotka Excel 16 ja LibreOffice 26.2 molemmat tuottavat tallentaessaan ODS:ää:

<!-- Yksinkertaistettu. Kantajatyyli jokaiselle A1:A50:n solulle (kaksi arvosääntöä) -->
<style:style style:name="ce3" style:family="table-cell">
  <style:map style:condition="cell-content()&gt;100"
             style:apply-style-name="CF_Hit"
             style:base-cell-address="Orders.A1"/>
  <style:map style:condition="cell-content-is-between(1,10)"
             style:apply-style-name="CF_Low"
             style:base-cell-address="Orders.A1"/>
</style:style>

<!-- Kantajatyyli jokaiselle C1:C50:n solulle (yksi kaavasääntö) -->
<style:style style:name="ce4" style:family="table-cell">
  <style:map style:condition="is-true-formula(COUNTIF([.$C:.$C];[.C1])&gt;1)"
             style:apply-style-name="CF_Dup"
             style:base-cell-address="Orders.C1"/>
</style:style>

style:mapin sudenkuoppa on, että se asuu solutyyleillä, joten se on solukohtaista. Jokaisen säännön alueen solun on kannettava mapin sisältävää tyyliä, tyhjät solut mukaan lukien, tai sääntö ei yksinkertaisesti kata kyseistä solua Excelissä. HotXLS kopioi jokaisen solun olemassa olevan muotoilutyylin, liittää mapit ja poistaa kantajatyylien kaksoiskappaleet alkuperäisen tyylin ja mapitekstin parilla, joten 500 solun alue, jolla on identtinen muotoilu, tuottaa yhä yhden tyylin. Kirjoittaja laajentaa myös kirjoitetun taulukon säännön alueeseen, mikä tarkoittaa, että säännön sisällä olevat tyhjät häntärivit tuotetaan pudottamisen sijaan. Versiosta v2.384.69 alkaen styles.xml kantaa myös tyhjän Default-solutyylin, joten style:apply-style-name="Default"llä on aina kohde

Calcext-kirjoitusasu, jonka LibreOffice oikeasti hyväksyy

LibreOffice hyväksyy calcext-arvosäännön vain, kun vertailuoperaattori on osa arvotekstiä, kuten >3 tai between(1,10), ja kaavasäännön vain, kun se on kirjoitettu muodossa formula-is(...). Molemmat kohdat maksoivat HotXLS:lle julkaisun, koska väärät kirjoitusasut tuottavat säännön, joka tuo ilman virhettä ja täsmää sitten vääriin soluihin

Ensimmäinen virhe oli calcext:operator-attribuutti calcext:value:n vieressä. Se lukee luontevasti, mutta se on keksitty: LibreOffice ei tunne kyseistä attribuuttia, joten se toi jokaisen arvosäännön "yhtä suuri kuin 0":na. Toinen oli is-true-formula(...), style:map-kirjoitusasun, paneminen calcext-ehtoon, jonka LibreOffice myös toi solu-arvovertailuna arvon 0 kanssa. Kaavakorjaus toimitettiin versiossa v2.384.66 ja arvokorjaus versiossa v2.384.69:

<!-- Väärin: LibreOffice ohittaa calcext:operatorin ja tuo "yhtä suuri kuin 0" -->
<calcext:condition calcext:apply-style-name="CF_Hit"
                   calcext:operator="greater-than" calcext:value="100"/>

<!-- Oikein: operaattori kulkee arvon sisällä -->
<calcext:condition calcext:apply-style-name="CF_Hit"
                   calcext:value="&gt;100" calcext:base-cell-address=".A1"/>
<calcext:condition calcext:apply-style-name="CF_Low"
                   calcext:value="between(1,10)" calcext:base-cell-address=".A1"/>

<!-- Oikein: kaavasäännöt käyttävät formula-isia, suhteelliset viittaukset ankkuroituna perussoluun -->
<calcext:condition calcext:apply-style-name="CF_Dup"
                   calcext:value="formula-is(COUNTIF([.$C:.$C];[.C1])&gt;1)"
                   calcext:base-cell-address=".C1"/>

Perussolu on se, mikä antaa suhteellisille viittauksille merkityksensä. HotXLS ankkuroi jokaisen säännön ensimmäisen alue-alueensa vasempaan yläkulmaan, joten C1:lle kirjoitettu kaava laskee muodossa C2, C3 ja niin edelleen aluetta alaspäin, täsmälleen niin kuin Excelin omassa ehdollisessa muotoilussa. Säännön lauseke kulkee saman kääntäjän läpi kuin solukaavat, joten taulukot, unionit, kokonaiset sarakkeet ja $-merkit tulevat ulos yllä kuvatuissa muodoissa. Delphi-puolella lisäät säännöt täsmälleen niin kuin tekisit sen .xlsx-tiedostolle

uses
  lxHandleX;

procedure AddOrderHighlights(Book: TXLSXWorkbook; Sheet: TXLSXWorksheet);
var
  Idx: Integer;
  Opts: TODSExportOptions;
begin
  // Arvosäännöt: style:map cell-content()>100 plus calcext-arvo ">100"
  Idx := Sheet.AddConditionalFormat('A1:A50', xlsxCfOpGreaterThan, '100');
  Sheet.ConditionalFormats[Idx].Style.SetFillBgColor($00C0C0FF); // BGR: vaalean punainen

  Idx := Sheet.AddConditionalFormat('A1:A50', xlsxCfOpBetween, '1', '10');
  Sheet.ConditionalFormats[Idx].Style.SetFontBold(True);

  // Kaavasääntö Excel-syntaksissa (pilkut erottimina, suhteellinen suhteessa C1:een):
  // style:map is-true-formula(...) ja calcext formula-is(...)
  Idx := Sheet.AddCondFormatExpression('C1:C50', 'COUNTIF($C:$C,C1)>1');
  Sheet.ConditionalFormats[Idx].Style.SetFillBgColor($00CCFFFF); // BGR: vaaleankeltainen

  Opts := TODSExportOptions.Create;
  try
    Opts.Generator := 'OrderExport 3.1';
    Book.SaveAsODS('orders.ods', Opts);
  finally
    Opts.Free;
  end;
end;

Excelin ja LibreOfficen ODS:n lukeminen takaisin Delphiin

Kun HotXLS avaa ODS-tiedoston, sen lukija hyväksyy molemmat ehdollisen muotoilun murteet ja molemmat calcext-kirjoitusasut, eikä se laske sääntöä kahdesti, kun tiedosto kantaa sitä molemmissa muodoissa. Oikeat tiedostot tulevat kolmelta kirjoittajalta, jokaisella omat tapansa:

• Vanha ja uusi calcext. calcext:operator-attribuutin sisältävät tiedostot, mukaan lukien HotXLS:n ennen versiota v2.384.69 kirjoittamat ODS:t, kulkevat yhä legacy-jäsennyksen läpi. Kaavaehdot tunnistetaan joko muodossa formula-is(...) tai is-true-formula(...)
• Excelin style:map-kirjoitusasu. Excel etuliittää ehdot muodossa of:, kuten of:cell-content-is-between(1,10), ja jättää perussolun pois arvosäännöissä. Molemmat hyväksytään
• Tyhjät solut. Excel ja LibreOffice panevat molemmat tyhjien solujen mapin sarakkeen oletustyyliin solun sijaan, joten lukija ratkaisee sarakkeiden oletustyylit toistetuille soluille ennen mapien keräämistä
• Alueiden rakentaminen uudelleen. Mapit kerätään solua kohden, joten taulukon lukemisen jälkeen lukija yhdistää saman ehdon ja perussolun jakavat solut takaisin alueiksi, ensin kutakin riviä pitkin ja sitten alaspäin täsmäävien sarakevälien mukaisesti, ja pudottaa calcextistä jo luetut säännöt

Korjaus v2.384.72 koskee lukutyylejä, ei sääntöjä. Excel 16 ja LibreOffice 26.2 kirjoittavat molemmat General-muodon lukutyylinä, jonka number:number-elementissä ei ole number:decimal-placesia, tyypillisesti <number:number number:min-integer-digits="1"/>. HotXLS:n lukija käsitteli puuttuvan määrän kahtena kiinteänä desimaalina, joten jokainen Default-tyylin arvo tuotiin muodossa 0.00 ja 1.5 näkyi muodossa 1.50. Versiosta v2.384.72 alkaen pelkkä lukuelementti ilman desimaaleja, ilman vähimmäisdesimaaleja, ilman ryhmittelyä ja korkeintaan yhdellä kokonaisluvun numerolla kuvautuu General-muotoon, ja yksin General jättää solun ilman lukumuotoa lainkaan. Sen ympärillä oleva teksti säilyy, kuten muodossa General" kg", ja ryhmitellyt luvut pitävät aiemman kuvauksen, koska Excelillä ei ole ryhmiteltyä General-muotoa

uses
  SysUtils, lxCondFormat, lxHandleX;

procedure DumpOdsRules(const FileName: string);
var
  Book: TXLSXWorkbook;
  Sheet: TXLSXWorksheet;
  Rule: TXLSXConditionalFormat;
  I: Integer;
begin
  Book := TXLSXWorkbook.Create;
  try
    if Book.Open(FileName) <= 0 then
      raise Exception.Create('cannot open ' + FileName);
    if Book.SourceFormat <> xlsxOpenDocumentSpreadsheet then
      raise Exception.Create('not an ODS package');

    Sheet := Book.Sheets[1]; // Sheets-indeksoija on ykköspohjainen
    for I := 0 to Sheet.ConditionalFormats.Count - 1 do
    begin
      Rule := Sheet.ConditionalFormats[I];
      case Rule.Kind of
        cfkCellIs:
          Writeln(Rule.Range, ' value rule ', Ord(Rule.Op), ' ',
            Rule.Formula1, ' ', Rule.Formula2);
        cfkExpression:
          Writeln(Rule.Range, ' formula rule ', Rule.Formula1);
      end;
    end;

    // Excelin General-tyylinen solu lukee takaisin ilman lukumuotoa
    // versiosta v2.384.72 alkaen, '0.00':n sijaan
    Writeln('A2 format: "', Sheet.Cells[2, 1].NumberFormat, '"');
  finally
    Book.Free;
  end;
end;

Sääntökaavat palaavat Excel-syntaksissa pilkkueroittimilla, samassa muodossa, jonka välittäisit funktiolle AddCondFormatExpression, joten HotXLS:n kirjoittama sääntö lukee takaisin identtisenä merkkijonona. Laajemmasta kuvasta siitä, mitä ODS-tuontipolku pitää ja pudottaa, kerrotaan oppaassa HotXLS ODS -avaus- ja tallennuskierros; siitä, miten Excelin ja LibreOfficen toistetut rivit laajennetaan tuonnissa, kerrotaan artikkelissa ODS:n toistetut rivit rivinkorkeusjaksoina

Mitkä ovat HotXLS:n ODS-ehdollisen muotoilun yhteentoimivuuden rajat?

Kaksoismerkintästrategia kattaa arvovertailusäännöt ja kaavasäännöt, ja pysähtyy siihen. Kaikki muu on yksipuolista tai ei kirjoiteta lainkaan:

• Värikaavat ja datapalkit kirjoitetaan vain calcext-elementteinä, joten LibreOffice näyttää ne eikä Excel
• Muut sääntötyypit, kuten kuvakesarjat, tekstisäännöt, top-N, keskiarvon ylittävät ja kaksoiskappalesäännöt, eivät saa ODS-tuotosta nykyisessä kirjoittajassa. Tekstisäännön voi yleensä muotoilla uudelleen kaavasäännöksi, esimerkiksi ISNUMBER(SEARCH("late",B2)) alueen B2:B200 yli, jolloin se tavoittaa molemmat sovellukset
• Kokonaisten sarakkeiden ja rivien säännöt kuten C:C levitetään vain kirjoitetun taulukkoalueen yli, kaikkien 1 048 576 rivin sijaan, joten Excel näkee nämä säännöt vain soluissa, jotka ovat olemassa tiedostossa
• Tiedostot, joissa on vain style:map. Kun tiedostossa ei ole calcext-lohkoa, HotXLS tulkitsee kaavasääntöjen suhteelliset viittaukset rakennetun alueen vasemmasta yläkulmasta, ei siirtymällä ilmoitetusta perussolusta
• Päällekkäiset säännöt LibreOfficesta. Kun yhden solun kattaa useita sääntöjä, LibreOffice kirjoittaa sen päälle vain ensimmäisen säännön mapin. Tällaisia tiedostoja ei voi lukea kokonaan pelkän style:mapin varassa, mikä on yksi syy lisää siihen, että lukija suosii calcextia, kun molemmat ovat olemassa

Prosessin raja merkitsee enemmän kuin mikään näistä. Näiden julkaisujen takana olleet viat menivät ohi kierrosten, jotka kirjoittivat ODS:n ja lukivat sen takaisin HotXLS:llä, ja jotkut olisivat läpäisseet myös manuaalisen tarkistuksen väärässä sovelluksessa: kokonaiset sarakkeet -kaavat toimivat LibreOfficessa, kun Excel näytti #NAME?:n, ja versiosta v2.384.66 kaavasäännöt toimivat LibreOfficessa, kun Excel näytti yhä ei yhtään sääntöä versioon v2.384.69 asti. Jos ODS-yhteentoimivuus on vaatimus, hyväksymistesti on tiedoston avaaminen Excelissä ja LibreOfficessa ja sen vertaaminen, mitä kumpikin näyttää. Sama kuria koskee tyylejä, joihin säännöt osoittavat; artikkeli HotXLS:n ehdollinen muotoilu ja tyylit kattaa, miten korostustyylit määritellään työkirjan puolella

Pikaopas: ODS, jonka molemmat sovellukset lukevat

• Esittele xmlns:of ja xmlns:msoxl content.xml-juuressa, tai LibreOffice näyttää #VALUE!-virheen jokaiselle kaavalle (HotXLS versiosta v2.384.56 alkaen)
• Kirjoita viittaukset muodossa [.A1], säilytä jokainen $ ja kirjoita kokonaiset sarakkeet ja rivit muodossa [.A:.A] ja [.1:.1] (versioista v2.384.55 ja v2.384.65 alkaen)
• Käytä ;-merkkiä argumenteille, ~-merkkiä viittausunionille ja |-merkkiä inline-taulukon rivien välissä
• Kirjoita jokainen arvo- tai kaavasääntö <style:map>:nä jokaisen katetun solun tyyliin Exceliä varten ja calcext-ehtona LibreOfficelle (versiosta v2.384.69 alkaen)
• Calcextissa pane operaattori arvoon (>3, between(1,10)) ja kirjoita kaavasäännöt muodossa formula-is(...) perussolulla (versioista v2.384.66 ja v2.384.69 alkaen)
• Odotat tuonnissa General-lukutyyliä ilman number:decimal-placesia; HotXLS lukee sen General-muotona versiosta v2.384.72 alkaen
• Tarkista jokainen uusi vientiprofiili avaamalla tiedosto sekä Excelissä että LibreOfficessa, ei koskaan vain toisessa

HotXLS on natiivi Delphi- ja C++Builder-laskentataulukkokirjasto, joka lukee ja kirjoittaa XLS-, XLSX- ja ODS-muodot ilman asennettua Exceliä tai LibreOfficeta; täysi lähdekoodi, ominaisuusluettelo ja lisensointi ovat HotXLS Delphi -laskentataulukkokomponentin sivulla