Kun HotXLS vie laskentataulukon PDF:ään automaattinen taggaus käytössä, laskentataulukon kuvat, jotka kantavat vaihtoehtotekstiä, emittoivat nyt itsenäisinä /Figure-rakenne-elementteinä Unicode-/Alt-merkinnällä, tiheillä sivukohtaisilla marked-content-tunnisteilla ja täsmällisillä vanhempipuumerkinnöillä. Kuvat ilman vaihtoehtotekstiä pysyvät koristeellisina artefakteina, ja kaaviot pysyvät artefakteina myös. Tuo täsmällinen laajuus merkitsee: se tekee informatiiviset kuvat näytönlukijan saavutettaviksi, eikä se ole sama asia kuin täysi PDF/UA-vaatimustenmukaisuus
Taustalla oleva mekaniikka on kiinnostavampi kuin ominaisuuden kuvaus, koska kaksi niistä on sellaista yksityiskohtaa, joka tuottaa hiljaisesti rakenteellisesti pätevän PDF:n, jonka rakenne osoittaa väärään sisältöön
Mikä lasketaan informatiiviseksi kuvaksi?
Vain ei-tyhjä AltText. Ominaisuus TXLSXImage.AltText kiertää OOXML:n descr-attribuutin kuvan ei-visuaalisissa ominaisuuksissa, mikä on paikka, johon Excel tallentaa tekstin, jonka käyttäjä kirjoittaa alt-tekstipaneeliin. Se on ainoa signaali tiedostossa, että tekijä piti kuvaa tiedon kantajana koristelun sijaan, joten se on ainoa signaali, johon vientitoiminto luottaa
Kahta lähes osuvaa ei hyväksytä tarkoituksella. Otsikkokenttä, tallennettuna erilleen kuvauksesta, ei ole korvike: otsikko on nimi objektille, ei sen tekstuaalinen vastine, ja sen ylentäminen kohteeseen /Alt tuottaisi dokumentin, joka läpäisee automatisoidun tarkistuksen ilmoittaen kuitenkin ”Kuva 3” näytönlukijalle. Tyhjä kuvaus ei myöskään ole aukko, joka täytetään paikkamerkillä; se tarkoittaa, että kuva pysyy artefaktina, mikä on oikea lopputulos logolle tai jakoviivalle. Kaaviot pysyvät myös artefakteina toistaiseksi, koska kaavion tekstuaalinen vastine on sen data ja sellaisen syntetisoiminen sarjoista olisi keksimistä eikä poimintaa
uses
lxHandleX, lxPDF;
var
Book: TXLSXWorkbook;
Sheet: TXLSXWorksheet;
Exporter: TXLSPDFExport;
I: Integer;
begin
Book := TXLSXWorkbook.Create;
try
Book.Open('regional-review.xlsx');
Sheet := Book.Sheets.ByPos[0];
// Auditoi ennen vientiä: kuva ilman kuvausta
// viedään koristeellisena artefaktina
for I := 0 to Sheet.Images.Count - 1 do
if Sheet.Images[I].AltText = '' then
Sheet.Images[I].AltText := DescribeImage(Sheet.Images[I].Name);
Exporter := TXLSPDFExport.Create;
try
Exporter.TagMode := xlsPdfTagsAutomatic;
Exporter.DocumentLanguage := 'en-US';
Exporter.SaveAsPDF(Sheet, 'regional-review.pdf');
finally
Exporter.Free;
end;
finally
Book.Free;
end;
end;Miksi sivu tarvitsee yhden MCID-varaajan?
Koska vanhempipuu on taulukko, joka indeksoidaan marked-content-tunnisteella, ja kaksi varaajaa tuottaa kaksi merkintää, jotka vaativat samaa paikkaa. Tagattu PDF yhdistää sisällön rakenteeseen molempiin suuntiin. Sisältöpuolella sivun sisältövirran jakso kääritään BDC- ja EMC-operaattoreihin, jotka kantavat /MCID-numeroa, joka on uniikki kyseisellä sivulla. Rakennepuolella sivusanakirja kantaa avainta /StructParents, joka nimeää rivin dokumentin /ParentTreessa, ja kyseinen rivi on taulukko, jonka alkio indeksissä n on rakenne-elementti, joka omistaa MCID n
Laskentataulukon sivu sisältää taulukkosoluja ja nyt kuviota. Jos solutaggaaja laskee tunnisteensa nollasta ja kuviotaggaaja laskee myös nollasta, ensimmäinen kuvio vaatii paikan, jonka ensimmäinen solu jo omistaa. Mitään tuloksena syntyvässä tiedostossa ei ole riittävästi vääristynyttä, jotta jäsentin hylkäisi sen: rakennepuu on ehjä, marked content on tasapainossa, ja validoija näkee dokumentin, jolla on vanhempipuu. Mitä näytönlukija saa, on taulukkosolu ilmoitettuna kuvana tai kuva ilmoitettuna solun tekstillä. Vientitoiminto varaa siksi yhdestä sivutason laskurista, jota molemmat taggaajat jakavat, ja jäädyttää sivutietueen vasta, kun sivuobjektinumero on tiedossa, koska vanhempipuuriviä ei voi kirjoittaa ennen kuin sivu, johon se viittaa, on saanut identiteetin
Figure-elementin on käärittävä koko näkyvä ilmentymä
Naiivi sijoittelu on kääriä Do-operaattori, joka kutsuu kuvan XObjectin, koska se on operaattori, joka piirtää kuvan. Se ei riitä. Laskentataulukon kuva piirretään usein varjon kanssa takanaan ja leikkauspolun kanssa ympärillään, ja ne merkinnät ovat osa näkyvää objektia. Jätettynä /Figure-vaikutusalueen ulkopuolelle niistä tulee merkitsemätöntä sisältöä, mikä on täsmälleen se tila, jonka rakenneauditointi liputtaa
Marked-content-vaikutusalue avautuu siis ennen varjoa ja sulkeutuu kuvan piirtämisen jälkeen kattaen myös leikkauksen. Jakaminen säilytetään siellä, missä jakaminen on oikein: kaksi solua, jotka näyttävät saman kuvapayloadin, viittaavat yhä yhteen kuva-XObjectiin, koska se on resurssitason optimointi eikä sillä ole mitään tekemistä semantiikan kanssa. Mitä jokainen näkyvä ilmentymä saa, on oma MCID ja oma rakenne-elementti, koska saman logon kaksi esiintymää eri paikoissa ovat kaksi asiaa, joita lukija kohtaa. Kuvien sijoittelu ja EMU-geometria, joka sijoittaa nämä objektit, käsitellään artikkelissa kuvageometria
Lukujärjestys laskentataulukon sivulla
Lukujärjestys on päätös, jonka vientitoiminnon on tehtävä, koska laskentataulukolla ei ole kirjoitettua virtaa niin kuin dokumentilla. Omaksuttu sääntö on vakaa ja helppo selittää: jokaisella sivulla taulukko tulee ensin, sitten kuviot piirtojärjestyksessä. Lukija kuulee siksi sivun taulukkomuotoisen sisällön ja sitten sen kuvat sen sijaan, että kuvat lomitettaisiin sillä sijainnilla, jonka piirtoobjektit sattuivat miehittämään tiedostossa
Tuo järjestys on sivua kohden eikä dokumenttia kohden, mikä merkitsee työkirjassa, joka sivuttaa kymmeniksi sivuiksi: jokaisen sivun rakennehaara on itsenäinen, joten sivujen välillä liikkuvalla lukijalla ei ole hyppäämistä takaisin aiempaan taulukkoon. Jos tarvitset hallintaa siihen, miten taulukkovälilehti sivuttaa ensinnäkin, sivuasetuksen ja tulostusalueen vuorovaikutus on kuvattu artikkelissa suojaus ja sivuasetus
Mitä tämä sertifoi ja mitä se ei
Se sertifoi, että informatiiviset kuvat saapuvat avustavaan teknologiaan tekijän toimittaman kuvauksen kanssa ja että sisällön ja rakenteen välinen kartoitus on oikea eikä ainoastaan läsnä. Se ei tee tulosteesta PDF/UA-yhteensopivaa, ja sen kuvaaminen niin olisi väite, jota toteutus ei voi tukea: kaaviot ovat yhä artefakteja, ja täysi vaatimustenmukaisuuslausuma vaatisi auditoinnin jokaisesta rakennetyypistä, jokaisesta fontista ja dokumentin metatiedoista kokonaisuutena
Jos vaatimuksesi on arkistointi- tai vaatimustenmukaisuusprofiili pikemminkin kuin saavutettavuuden parantaminen, kyseessä on eri vientikonfiguraatio ja eri tarkistusjoukko, mistä kerrotaan artikkelissa PDF/A-arkistointivienti. Kaksi yhdistyvät, mutta ne vastaavat eri auditoijille
Yksi käytännön ehdotus raportointiputkelle: auditoi vaihtoehtoteksti siinä vaiheessa, jossa työkirja tuotetaan, ei vientihetkellä. Generaattori tietää, mitä kukin kaaviokuva tai upotettu kaavio edustaa, ja voi kirjoittaa oikean kuvauksen kohteeseen AltText; vientihetken ajo voi vain kertoa, että kuvaus puuttuu. HotXLS lukee ja kirjoittaa muodot XLS, XLSX, ODS ja CSV natiivisti Delphistä ja C++Builderista ilman Excel-riippuvuutta, ja sen vientikonfiguraatiovaihtoehdot on lueteltu HotXLS Delphi spreadsheet -komponentin tuotesivulla