Amikor a HotXLS munkalapot PDF-be exportál automatikus címkézéssel, az alternatív szöveget hordozó munkalapképek mostantól önálló /Figure szerkezetelemekként bocsátódnak ki Unicode /Alt bejegyzéssel, sűrű oldalhelyi megjelölt-tartalom azonosítókkal és pontos szülőfa-bejegyzésekkel. Alternatív szöveg nélküli képek dekoratív artefaktok maradnak, és a diagramok is artefaktok maradnak. Az a pontos hatókör számít: az informatív képeket elérhetővé teszi egy képernyőolvasó számára, és nem ugyanaz, mint a teljes PDF/UA megfelelés
A mögötte lévő mechanika érdekesebb, mint a funkció leírása, mert kettőjük azon részletek fajtája, amelyek csendben olyan szerkezetileg érvényes PDF-et produkálnak, amelynek szerkezete a rossz tartalomra mutat
Mi számít informatív képnek?
Csak egy nem üres AltText. A TXLSXImage.AltText tulajdonság oda-vissza viszi a kép nem vizuális tulajdonságainak OOXML descr attribútumát, amely az a hely, ahová az Excel azt a szöveget tárolja, amelyet a felhasználó az alt szöveg panelbe gépel. Az az egyetlen jelzés a fájlban, hogy a szerző informatívnak tartotta a képet, nem dekorációnak, tehát az az egyetlen jelzés, amelyben az exportáló bízik
Két közeli kihagyást szándékosan nem fogadnak el. A cím mező, amely a leírástól elkülönítve tárolódik, nem helyettesítő: a cím az objektum neve, nem annak szöveges megfelelője, és annak /Alt-ba való előléptetése olyan dokumentumot produkálna, amely átmenne egy automatizált ellenőrzésen, miközben „3. kép”-et jelent be egy képernyőolvasónak. Egy üres leírás sem helyőrzővel kitöltendő rés; azt jelenti, hogy a kép artefakt marad, ami a helyes kimenet egy logó vagy elválasztó vonal esetében. A diagramok egyelőre szintén artefaktok maradnak, mert egy diagram szöveges megfelelője az adata, és annak szintézise a sorozatokból találmány lenne, nem kinyerés
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];
// Auditáljon exportálás előtt: egy leírás nélküli kép
// dekoratív artefaktként exportálódik
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;Miért van szüksége az oldalnak egyetlen MCID osztóra?
Mert a szülőfa megjelölt-tartalom azonosítóval indexelt tömb, és két osztó két bejegyzést produkál, amelyek ugyanazt a helyet követelik. A címkézett PDF mindkét irányban köti össze a tartalmat a szerkezettel. A tartalomoldalon az oldal tartalomfolyamának egy szakaszát BDC és EMC operátorok csomagolják be, amelyek azon az oldalon belül egyedi /MCID számot hordoznak. A szerkezetoldalon az oldal szótára /StructParents kulcsot hordoz, amely a dokumentum /ParentTree egy sorát nevezi meg, és az a sor olyan tömb, amelynek az n indexű eleme az n MCID-t birtokló szerkezetelem
Egy munkalapoldal táblázatcellákat és mostantól ábrákat tartalmaz. Ha a cellacímkéző a nullától számolja az azonosítóit, és az ábracímkéző is a nullától számol, az első ábra követeli azt a helyet, amelyet az első cella már birtokol. Semmi a keletkező fájlban nem elég rosszul formált ahhoz, hogy egy elemző elutasítsa: a szerkezetfa érintetlen, a megjelölt tartalom kiegyensúlyozott, és egy validátor szülőfával rendelkező dokumentumot lát. Amit egy képernyőolvasó kap, az képként bejelentett táblázatcella, vagy cella szövegével bejelentett kép. Az exportáló ezért egy oldal szintű, mindkét címkéző által osztott számlálóból oszt, és az oldalrekordot csak akkor fagyasztja be, amikor az oldalobjektum száma ismert, mert a szülőfa sor nem írható, mielőtt az az oldal, amelyre hivatkozik, identitáshoz jutott
A Figure-nek a teljes látható példányt kell körülölelnie
A naiv elhelyezés az a Do operátor körülölelése, amely a kép XObjectet hívja, mivel az az operátor, amely a képet rajzolja. Az nem elég. Egy munkalapképet gyakran árnyékkal mögötte és kivágási úttal körülötte rajzolnak, és azok a jelek a látható objektum részét képezik. A /Figure hatókörön kívül hagyva megjelöletlen tartalommá válnak, ami pontosan az az állapot, amelyet egy szerkezetaudit megjelöl
Ezért a megjelölt-tartalom hatókör az árnyék előtt nyílik, és a kép rajzolása után zárul, a kivágást is lefedi. A megosztás ott marad meg, ahol a megosztás helyes: ugyanazt a képhasznos terhet mutató két cella továbbra is egy kép XObjectre hivatkozik, mert az erőforrás szintű optimalizálás, és semmi köze a szemantikához. Amit minden látható példány kap, az a saját MCID-je és a saját szerkezeteleme, mert ugyanazon logó két előfordulása két dolog, amelyekkel egy olvasó találkozik. A képelhelyezés és az objektumokat pozicionáló EMU geometria a képgeometriai cikkben van tárgyalva
Olvasási sorrend egy munkalapoldalon
Az olvasási sorrend döntés, amelyet az exportálónak meg kell hoznia, mert egy táblázatnak nincs szerkesztett folyamata úgy, ahogyan egy dokumentumnak van. A követett szabály stabil és könnyen elmagyarázható: minden oldalhoz előbb a táblázat jön, majd az ábrák rajzolási sorrendben. Egy olvasó ezért hallja az oldal táblázati tartalmát, majd a képeit, nem pedig úgy, hogy a képek a rajzobjektumok fájlbeli pozícióinál vannak közbeszúrva
Az a sorrend oldalonkénti, nem dokumentumonkénti, ami egy olyan munkafüzeten számít, amely tucatszámra lapoz: minden oldal szerkezetága önellátó, tehát az oldalak között mozgó olvasó nem ugrik vissza egy korábbi táblázatba. Ha az első helyen azt kell irányítania, hogyan lapoz a munkalap, az oldalbeállítás és a nyomtatási terület kapcsolatát a védelmi és oldalbeállítási cikk írja le
Mit tanúsít ez, és mit nem
Tanúsítja, hogy az informatív képek elérik a segítő technológiát a szerző által szolgáltatott leírással, és hogy a tartalom-szerkezet leképezés helyes, nem csupán jelen lévő. Nem teszi a kimenetet PDF/UA megfelelővé, és úgy leírni azt olyan állítás lenne, amelyet az implementáció nem tud támogatni: a diagramok továbbra is artefaktok, és egy teljes megfelelőségi állítás minden szerkezettípus, minden betű és a dokumentum metaadatainak egésze auditját követeli
Ha az Ön követelménye archiválási vagy megfelelőségi profil, nem pedig akadálymentesítési javulás, az más exportkonfiguráció és más ellenőrzéskészlet, amelyet a PDF/A archiválási export cikk ír le. A kettő egyesül, de más auditornak válaszolnak
Egy gyakorlati javaslat egy jelentésvezetékhez: auditálja az alternatív szöveget ott, ahol a munkafüzet keletkezik, nem exportáláskor. A generátor tudja, mit ábrázol minden diagramkép vagy beágyazott vázlat, és valós leírást írhat a AltText-be; egy export idejű menet csak azt tudja megmondani, hogy a leírás hiányzik. A HotXLS XLS, XLSX, ODS és CSV formátumokat olvas és ír natívan Delphi és C++Builder alól Excel-függőség nélkül, és az exportkonfigurációs lehetőségei a HotXLS Delphi spreadsheet component terméklapon találhatók