> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/fi/lisaa-aiheita/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md). # Johdatus tagitettuihin PDF-tiedostoihin: sisäiset rakenteet ja saavutettavuuden haasteet ## Päivitys: tammikuu 2026 Katso [Overleafin ohjeet tagattujen PDF-tiedostojen luomiseen](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs). Se [LaTeX-tiimi](https://latex-project.org/) on julkaissut uusia ominaisuuksia, jotka mahdollistavat automaattisen PDF-tagauksen, joka on PDF:n saavutettavuuden keskeinen vaatimus. Nämä uudet ominaisuudet ovat saatavilla Overleafissa [TeX Live 2025](http://\(https//www.overleaf.com/blog/tex-live-2025-is-now-available), ja uudempia päivityksiä on saatavilla jatkuvassa TeX Live -julkaisussa, joka on saatavilla kautta [Overleaf Labsissa](https://www.overleaf.com/labs/participate). On nyt mahdollista tuottaa LaTeX-lähdekoodista tagattu PDF, joka on WCAG 2.1 -tason AA mukainen, noudattamalla [käyttäjädokumentaatiotamme](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs) käyttämällä Overleafissa saatavilla olevia TeX Live -julkaisuja. Alla oleva vuoden 2020 artikkeli, vaikka sitä ei ole päivitetty LaTeX:n saavutettavuutta koskevilla uusimmilla tiedoilla, on edelleen luettavissa mielenkiinnon vuoksi ja taustatietona PDF-tagauksesta. *** ## Mitä tämä artikkeli käsittelee? Tämän artikkelin tavoitteena on tarjota johdanto tagattuun PDF:ään sekä yleiskatsaus joihinkin ohjelmistojen kohtaamiin teknisiin haasteisiin, mukaan lukien TeX-ytimet ja LaTeX, joiden tavoitteena on tuottaa tagattuja ja saavutettavia PDF-tiedostoja. Saavutettavuus, erityisesti PDF:ien saavutettavuus, on laaja ja monimutkainen aihe, johon liittyy myös teknisiä haasteita, joihin ei aina ole yhtä ainoaa, yleisesti hyväksyttyä ratkaisua — kuten miten esittää monimutkaista matematiikkaa PDF:issä saavutettavalla tavalla: MathML:n vai LaTeX-koodin avulla? Vaikka emme voi syventyä jokaiseen aiheeseen perusteellisesti ja joudumme yksinkertaistamaan monia yksityiskohtia, voimme kurkistaa PDF-tiedostojen sisälle osoittaaksemme, mitä PDF:n tagaus todella tarkoittaa. Overleaf toivoo, että tästä artikkelista on hyödyllinen johdanto, joka tarjoaa riittävästi taustaa, jotta lukijat ymmärtävät paremmin tekniset haasteet ja saavat tukea jatkoluvulle ja tutkimiselle tagatusta PDF:stä ja saavutettavuudesta. Tämän artikkelin resurssit sisältävät: * [8 minuutin videon](#video-showing-the-logical-structure-of-a-tagged-pdf) tagatun PDF:n tutkimiseen, jonka LaTeX on tuottanut; * [Overleaf-projektin](#using-luatex-an-example-in-the-overleaf-gallery) välilyöntimerkkien käytön tutkimiseen LuaTeXissä; * [äänitallenteita](#tagged-yes-but-the-reading-order-is-incorrect) jotka osoittavat PDF:n saavutettavuusongelmia. ## Johdanto Digitaalisen sisällön saavutettavuuden varmistamista tunnustetaan perustellusti tärkeäksi osaksi sisällön tuottamista ja levittämistä. Lisäksi hallitukset, mukaan lukien [Yhdistynyt kuningaskunta](https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps) ja [Yhdysvallat](https://www.hhs.gov/sites/default/files/Intro%20to%20Accessibility%20and%20508.pdf), säätävät lakeja, jotka edellyttävät heidän lainkäyttöalueellaan tuotetun sisällön olevan määriteltyjen saavutettavuuskriteerien mukaista. Yhteensopivuus sisällön jakelun kautta HTML-muodossa ei ole kohtuuton rasite, mutta vaaditun saavutettavuustason varmistaminen PDF-muodossa jaettaville asiakirjoille voi olla merkittävä tekninen haaste — riippuen ohjelmistosta, jota käytetään PDF-tiedostona tuotettavan sisällön luomiseen. PDF syntyi 1990-luvun alussa ratkaisuksi luotettavan asiakirjansiirron ympärillä oleviin ongelmiin, ja historia on osoittanut sen valtavan menestykseksi. PDF on kuitenkin myös monimutkainen tiedostomuoto, joka syntyi ennen kuin asiakirjojen sisällön saavutettavuuden tarve tunnustettiin ja hyväksyttiin laajasti. Siitä huolimatta PDF-määritys on ajan myötä kehittynyt tarjoamaan ominaisuuksia, jotka mahdollistavat ja tukevat saavutettavien PDF-asiakirjojen tuottamista käyttämällä PDF:n “tyyliteltyä” muunnelmaa, jota Adobe kutsuu *tagatuksi PDF:ksi*. Käytännössä tagattujen—*ja täysin saavutettavien*—PDF-tiedostojen tuottaminen asettaa merkittäviä lisäteknisiä vaatimuksia ohjelmistolle, joka tuottaa PDF:ää — ja siihen kuuluvat TeX-ytimet sekä LaTeX-ekosysteemi makroineen ja lisäosineen. ## PDF:n synty lopullisena digitaalipaperina Se [Kannettavan asiakirjamuodon (PDF) synty](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) juontaa ajalta, jolloin asiakirjojen siirto tietokoneiden välillä oli vaikeuksien täyttämää, usein tiedostomuunnosten aiheuttamien sivujen uudelleenasettelun ja muiden eroavaisuuksien vuoksi, joita pahensivat eri käyttöjärjestelmissä käytetyt yhteensopimattomat fontit ja tekstikoodaukset (erityisesti Windowsissa ja Macintoshissa). Tämän asiakirjan kirjoittaja työskenteli tuolloin kustannusalalla ja muistaa elävästi noiden haasteiden kanssa painimisen! PDF suunniteltiin ratkaisemaan tiedostonjakamisen ongelmia tuomalla käyttöön universaali, lopullisen muodon (muokkaamaton) digitaalinen paperi, joka mahdollisti itsenäisten asiakirjojen saumattoman siirtämisen mukana tulevine fontteineen, joita tarvittiin niiden näyttämiseen. Käyttäjät saattoivat lopulta siirtää kaikenlaisia asiakirjoja kohtuullisella varmuudella siitä, että vastaanottajat riippumatta tietokonealustasta pystyisivät avaamaan ja lukemaan ne — asiakirjojen eheys säilyi ja sotkuiset sivujen uudelleenasettelut sekä fonttien yhteensopivuus/saatavuus jäivät menneisyyteen. ### Digitaalipaperi: hyväksi kaikille käyttäjille? PDF:n tausta digitaalipaperin muotona oletti luonnollisesti painettujen sivunumeroiden, typografian tai suunnitteluelementtien käytön visuaalisina vihjeinä sisällön selaamiseen — näytöllä tai paperilla. Nämä visuaaliset vihjeet/mekanismit ovat tietenkin merkityksettömiä ihmisille, joilla on vaikea näkövamma. Nykyään digitaalisen sisällön parempi saavutettavuus tunnustetaan perustellusti tärkeäksi osaksi sisällön tuottamista ja levittämistä. PDF:n haasteena oli tarjota mekanismeja, jotka helpottavat ei-visuaalista pääsyä sisällön sisään suljettuun “säiliöön”, joka oli alun perin suunniteltu jäljittelemään painetun sivun visuaalista mediaa. Ensimmäinen PDF-määrityksen versio (PDF 1.0) oli [julkaistu virallisesti 15. kesäkuuta 1993](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) ja sitä seurasi uusia versioita päivityksineen, jotka vuonna 2001 (PDF 1.4) sisälsivät “tagatun PDF:n” käyttöönoton, joka [“...mahdollisti avustavien teknologioiden käyttäjien”](https://www.adobe.com/accessibility/pdf.html). PDF-määrityksen myöhemmät versiot ovat laajentaneet ja parantaneet PDF:n ominaisuuksia, huipentuen viimeisimpään julkaisuun (PDF 2.0), joka, perustuen [raportteihin](https://www.pdfa.org/tagged-pdf-2-0/), on uudistanut saavutettavuusominaisuudet merkittävästi — vaikka PDF 2.0:aa ei vielä tueta hyvin TeX-ytimissä. ## Sisältö PDF-tiedostojen sisällä Ymmärtääksemme näihin liittyvät ongelmat kannattaa tarkastella, miten PDF-tiedostot itse asiassa esittävät sisältämänsä sivun sisällön. Syvällä PDF-tiedoston sisällä kunkin sivun sisältö sijaitsee kyseisen sivun *sisältövirrassa*: PDF-operaattorien (“komentojen”) sarjassa, joka sijoittaa tekstiä tai grafiikkaa tiettyyn sivun kohtaan renderöintiä (näyttämistä) varten ohjelmistolla, jota käytetään *katsomaan* PDF:ää. Käytännössä sisältövirta tarjoaa graafisen kuvauksen tai “reseptin”, joka kertoo PDF:n katselusovelluksille, miten kukin sivu “piirretään” — määritellen, mitä sivulla näytetään ja missä. Luonnollisesti tämä operaattorijoukko sisältää ohjeet valita tietyt fontit tietyllä koolla, valita värit, määritellä viivan paksuudet, piirtää viivoja, käyriä ja niin edelleen — kaiken, mitä tarvitaan täydellisen graafisen kuvauksen tarjoamiseksi sivun visuaalista esitystä varten. Tiedostokoon pienentämiseksi PDF:n sisältövirrat pakataan ja tallennetaan kompaktissa binaarimuodossa, mutta jos käytössäsi on sopiva ohjelmisto, kuten Adobe Acrobat Pro DC, voit käyttää sitä tarkastellaksesi sivun sisältövirtojen “purkamatonta” pelkkää tekstiä sisältävää versiota. Mietitään, miten PDF-operaattorit voisivat “piirtää” taulukon: PDF:n sisältövirta sisältäisi sopivan operaattorijonon, joka tuottaisi vaaka- ja pystysuoria viivoja, valitsisi eri fontteja ja tulostaisi tekstiä sivun eri kohtiin taulukon sisällön muodostamiseksi. Havainnollistamiseksi tarkastellaan hyvin yksinkertaista tagaamatonta PDF-asiakirjaa, joka sisältää vain perustason taulukon ja tekstiä — luotu Microsoft Wordissa syistä, jotka käyvät ilmeisiksi myöhemmin artikkelissa. Tässä on kuvakaappaus yksinkertaisesta PDF:stämme: ![Microsoft Wordissa luotu taulukko](/files/47d74ef265973bc6b6e6c3cf6eca442875d01982) Jos poimimme tämän tiedoston (purkamattoman) sivun sisältövirran ja liitämme ensimmäiset rivit tekstieditoriin, voimme tiivistää joitakin PDF-operaattoreita saadaksemme kuvan siitä, miten PDF-tiedostot “kuvaavat” tälle sivulle näytettävää sisältöä. ![Kuva PDF-tiedoston sisältövirrasta](/files/2214f293aa4cf200b0bd988fb7b388490ba4e63e) Jos sinulla on käytössäsi Adobe Acrobat Pro DC, voit käyttää sitä listataksesi PDF-sivun sisältövirrassa olevat operaattorit. Tässä on Acrobatin *sisäinen PDF-rakenne* näkymä samasta PDF:stä, joka tarjoaa hyödyllisesti yhden rivin kuvauksen jokaisesta operaattorista, jota käytetään yksittäisen sivumme perustaulukon “piirtämiseen” — huomaa, että nämä lyhyet kuvaukset on tarjonnut Adobe Acrobat Pro DC; ne eivät *sisällä* ole itse PDF-tiedostossa: ![Kuva Adobe Acrobat Pro DC:ssä tarkastellusta PDF:n sisältövirrasta](/files/48e59c9a93df36e54e62696c5718cf695b34f675) Huomaa kuitenkin, että yksikään näistä piirto-ohjeista (operaattoreista) ei tallenna mitään “merkitystä” tai “kuvausta” siitä, mitä ne oikeasti tuottavat: ne ovat vain joukko grafiikkaoperaattoreita, joiden tuloksena syntyy se, minkä *näkevä tarkkailija tunnistaa* taulukoksi. Selvästi vaikeasti näkövammaisille ei ole toimiva tapa päästä käsiksi tähän sisältöön katsomalla PDF:n sisältövirrassa olevien graafisten operaattorien tuloksena syntyvää taulukkoa. Tarvitaan mekanismi, jolla PDF-tiedostot sisältävät sopivan ei-visuaalisen (koneellisesti luettavan) kuvauksen kyseisestä taulukosta — ja tietenkin kaikesta muusta sisällöstä, joka sisältyy PDF-tiedoston sivuille. Jotta sisältöön voidaan päästä käsiksi ei-visuaalisesti, PDF-tiedostojen on sisällettävä lisätietoa, joka liittää “merkityksen” tai semantiikan kokoelmiin tai ryhmiin operaattoreita, joita käytetään tietyn sisällön “piirtämiseen”. Välttämättä tämä “merkityksen” antamisen tai tarjoamisen periaate on ulotettava kaikkiin PDF:ssä oleviin sisältömuotoihin: tämä mekanismi on olemassa ja sitä kutsutaan *tagaukseksi* PDF:ää tuottaen PDF:n “muunnelman”, jota kutsutaan, ei yllättäen, *tagatuksi PDF:ksi*. ## Tagatun PDF:n esittely Tagattu PDF on nimi tietynlaiselle PDF-tiedostolle, joka sisältää lisätietoja (ja tietorakenteita), joita ei ole tagaamattomissa PDF-tiedostoissa. Vaikka tagatun PDF:n taustalla olevat periaatteet/ideat ovat tiivistettävissä yleiskuvauksena, täydelliset yksityiskohdat ovat monimutkaisia ja vievät monia sivuja PDF:n virallisessa määrityksessä. Adobe suunnitteli tagatun PDF:n saavuttaakseen useita tavoitteita, joihin kuului sisällön tekeminen saavutettavaksi näkövammaisille käyttäjille, mutta siihen sisältyy myös seuraava luettelo, joka on otettu kohdan 10.7 lähteestä [Adoben PDF 1.7 -määrityksestä](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf): * tekstin ja grafiikan yksinkertainen poiminta liittämistä varten muihin sovelluksiin; * tekstin ja siihen liittyvän grafiikan automaattinen uudelleenasettelu niin, että ne sopivat erikokoiselle sivulle kuin alkuperäisessä asettelussa oletettiin; * tekstin käsittely esimerkiksi hakemista, indeksointia ja oikeinkirjoituksen tarkistusta varten; * muuntaminen muihin yleisiin tiedostomuotoihin (kuten HTML, XML ja RTF) säilyttäen asiakirjan rakenne ja perusmuotoilu. Lisäksi tagattu PDF edellyttää myös: * PDF-sisällön tekstin esittämistä muodossa, joka voidaan muuntaa Unicodeksi; * sananrajat on esitettävä eksplisiittisesti — huomaa, että TeX-ytimet eivät käytä välilyöntimerkkejä sanojen erottamiseen, vaan TeX:n joustavaa välitystä, jota kutsutaan liimaksi (katso alla); * todellinen (“oikea”) sisältö erotetaan asettelun ja sivutuksen artefakteista. Tagatun PDF:n taustalla on kaksi keskeistä käsitettä, joita tarkastelemme: * sisällön loogisen rakenteen määrittely PDF-tiedostossa; * PDF-sisällön merkintä (tagaus) standardien sisältötyyppien joukolle. ## Looginen rakenne Pidemmissä asiakirjoissa sisältö on yleensä jaettu pienempiin sisältökokonaisuuksiin; esimerkiksi kirjat jaetaan tyypillisesti lukuihin, jotka puolestaan jaetaan osioihin ja alalukuihin, joissa on kappaleita, taulukoita, kuvaajia/kaavioita, luetelmia tai numeroituja listoja, alaviitteitä ja viitteitä ja niin edelleen. Tällaisen kirjan tai muun asiakirjatyypin sisällön rakenne ja organisointi tunnetaan sen *loogisena rakenteena*. Käsitys asiakirjan loogisesta rakenteesta on tärkeä PDF:n saavutettavuudessa, mutta käsitteenä looginen rakenne voi tuntua hieman epämääräiseltä ja hankalalta ymmärtää. Seuraava määritelmä lähteestä [Encyclopedia of Database Systems](https://link.springer.com/referenceworkentry/10.1007%2F978-0-387-39940-9_213) tarjoaa hyödyllisen näkemyksen: > “Looginen rakenne viittaa siihen, miten asiakirjan tieto on järjestetty; se määrittelee tiedon hierarkian ja asiakirjan eri osien välisen suhteen. Looginen rakenne osoittaa, miten asiakirja on rakennettu, toisin kuin mitä asiakirja sisältää.” Huomaa, että tämä loogisen rakenteen määritelmä ei viittaa tarkasti *miten* siihen, missä tämä rakenteellinen tieto on fyysisesti tallennettu; vain siihen, että se tarjoaa esityksen asiakirjan rakenteesta ja organisoinnista. Tarkat yksityiskohdat siitä, miten asiakirjan looginen rakenne tallennetaan tai esitetään, riippuvat toteutuksesta: ohjelmistosta, jota käytetään sen luomiseen ja käsittelyyn. ### Looginen rakenne PDF:issä PDF-määritys tarjoaa mekanismeja, joiden avulla asiakirjan looginen rakenne voidaan tallentaa PDF-tiedostoon — ohjelmiston käytettäväksi, joka esimerkiksi saattaisi haluta viedä PDF:n sisällön muihin muotoihin, kuten XML:ään, HTML:ään tai Microsoft Wordiin. Nämä vientiprosessit tarvitsevat luodakseen oikein rakennetun tekstiasiakirjan, joka vastaa kohdevientimuodon sääntöjä — tämä onnistuu parhaiten, kun vientiä ohjaa PDF:ään tallennettu looginen rakenne. Lisäksi PDF-tiedoston looginen rakenne on olennainen avustavalle ohjelmistolle, joka esimerkiksi saattaa haluta suorittaa tekstistä puheeksi -toimintoja ja lukea sisällön ääneen näkövammaiselle henkilölle. Tekstistä puheeksi -prosessin on varmistettava, että sisältö luetaan ääneen oikeassa järjestyksessä, muuten tuloksena olisi järjettömiä tuloksia. Huomaa myös, että itse sivun käsite ei välttämättä merkitse mitään saavutettavuussovelluksille, joita kiinnostaa vain PDF:n sisältö ja asiakirjan rakenne, ei visuaalinen jakaminen ja esittäminen sivunkokoisiin palasiin. #### Sisältökohteiden nimeäminen PDF-asiakirjan loogisen rakenteen tallentaminen edellyttää, että eri *tyypeille* sisältökohteista, joita tyypillisessä PDF-asiakirjassa todennäköisesti esiintyy — tunnistetaan sisältöosat, jotka edustavat otsikoita, kappaleita, taulukoita, luetteloita ja niin edelleen. Lisäksi joillakin sisältökohteilla, kuten sisällysluetteloilla, numeroiduilla/luetelmamerkeillä varustetuilla listoilla ja taulukkomateriaalilla, on varsin monimutkaiset omat rakenteensa, joten tarvitaan myös ohjeita/sääntöjä määrittelemään, miten nämä monimutkaisemmat sisältökohteet rakentuvat — niiden alirakenne. Lisäksi on tarpeen tunnistaa selvästi kaikki PDF-sisältö, joka avustavan ohjelmiston tulisi jättää huomiotta PDF:ää käsitellessään; esimerkiksi sivun ylätunnisteet ja alatunnisteet ovat sivutuksen artefakteja, jotka sisältävät tekstiä, joka on tarpeetonta vaikeasti näkövammaisille: tämä sisältö tulisi jättää huomiotta. PDF:n käyttämät mekanismit asiakirjan loogisen rakenteen määrittämiseksi on suunniteltu joustaviksi, joten periaatteessa eri sovellukset, jotka luovat ja käsittelevät PDF-tiedostoja, voisivat käyttää sisältötyyppien nimiä millä tahansa valitsemallaan käytännöllä. Kuitenkin asiakirjavaihdon maksimoimiseksi ja jotta eri PDF-käsittelysovellukset tuottaisivat yhdenmukaisia tuloksia, Adobe määritteli joukon standardinimiä sisältökohdille, joita PDF:n luontiohjelmiston tulisi noudattaa. PDF-määrityksessä näihin standardinimiin viitataan tageina, mistä syntyy käsite *tagatusta* PDF:stä. ### PDF-sisällön merkintä: kurkistus “konepellin alle” Jotta keskustelu olisi hieman vähemmän abstrakti, tarkastelemme lyhyesti tagattujen PDF-tiedostojen sisäistä rakennetta — emme kuitenkaan voi käydä läpi kaikkia yksityiskohtia, koska tagattu PDF on niin laaja ja monimutkainen aihe. #### Merkityn sisällön sekvenssit: tagatun PDF:n rakennuspalikoita Alimmalla tasolla prosessi, jossa tallennetaan PDF-sivulla olevan sisällön merkitys (eli sen sisältövirrassa), alkaa *merkityn sisällön sekvensseistä* joita käytetään tunnistamaan (antamaan “merkitys”) PDF-operaattorien ryhmille tai klustereille. Merkityn sisällön sekvensseille annetaan numeerinen tunniste, jota kutsutaan sen `MCID:ksi` (*merkityn sisällön tunniste*) joka on kokonaisluku, joka kulkee 0:sta johonkin enimmäisarvoon N kullakin sivulla. Nämä `MCID:ksi` arvot tarjoavat tavan yksilöllisesti tunnistaa tietyn sivun sisältövirrassa olevia operaattorijonoja. Selvennykseksi: jokaisella sivulla `MCID:ksi` tunnisteet alkavat 0:sta ja kasvavat peräkkäin johonkin enimmäisarvoon, joka riippuu siitä, kuinka monta merkityn sisällön sekvenssiä kyseisen sivun sisältövirrassa on. Merkityn sisällön sekvenssit ovat käytännössä perustason “rakennuspalikoita”, joita käytetään kokoamaan korkeamman tason tietorakenteita, joita kutsutaan *rakenneosiksi*. Nämä rakenneosat sisältävät tagin, joka on nimi, jota käytetään tunnistamaan, mitä sisältötyyppiä ne edustavat. #### Esimerkki rakenneosista Hyppäämme tässä hieman eteenpäin, mutta esimerkki on syytä tarkastella. Oletetaan, että sinulla on 3 pientä tekstikatkelmaa sivun sisällöstä ja jokainen niistä on tunnistettu sisältövirrassa eri merkityllä sisältösekvenssillä. Jokainen näistä kolmesta tekstikatkelmasta voidaan paketoida omaan rakenneosaan tagin kanssa, ja kaikki kolme voidaan “linkittää toisiinsa” käyttämällä toista rakenneosaa, joka edustaa korkeamman tason sisältökohdetta, kuten sisällysluettelon riviä. ![Kuva, joka selittää rakenneosia ja merkityn sisällön sekvenssejä](/files/a7cca482b8e2a3094e76938b3b97714ed3ca4d5d) Vanhempi–lapsi-suhteen avulla rakenneosien kokoelmat yhdistetään luomaan linkitettyjä tietorakenteita, jotka edustavat monimutkaisempia tietoelementtejä, kuten numeroituja ja luetelmamerkeillä varustettuja listoja, taulukoita, matematiikkaa ja niin edelleen. Lopulta koko PDF-tiedostossa olevat rakenneosakokoelmat linkitetään vielä toisiinsa ja yhdistetään luomaan PDF-asiakirjan looginen rakenne — palaamme tähän myöhemmin artikkelissa. ### Mikä on merkitty sisältösekvenssi? Yllä olevassa keskustelussa käytimme yksinkertaista tagaamatonta PDF-asiakirjaa, joka sisälsi taulukon (luotu Microsoft Wordissa), mutta jos käsitämme Wordille käskyn luoda tagattu PDF, voimme nähdä, että sivun sisältövirrassa on ilmestynyt lisämerkintää. Tässä tarkastelemme vain sisältövirran ensimmäisiä rivejä (riviä on satoja), mutta huomaa lisäoperaattorien, kuten `/P <> BDC` ja `EMC` olemassaolo, joita käytetään merkityn sisältösekvenssin tunnistamiseen. Emme tutki merkityn sisältösekvenssin koko syntaksia, vaan viittaamme lukijaa sivulle 862 kohdassa [Adoben virallinen PDF 1.7 -määritys](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf). ![Kuva, joka näyttää merkityn sisällön sekvenssit tagatun PDF:n sisältövirrassa](/files/b612fb6fe55c334570b321959fb3c290348ff267) Helppoa viittaamista varten näytämme jälleen tagaamattoman version: ![Kuva, joka näyttää PDF:n sisältövirran](/files/2214f293aa4cf200b0bd988fb7b388490ba4e63e) Kohdassa *tagaamaton* PDF, operaattorit kuten `/P <> BDC` ja `EMC` puuttuvat, mutta jäljellä olevat operaattorit ovat muuttumattomia: tagaamattomasta PDF:stä puuttuu lisämerkintä, jota käytetään tiettyjen operaattorijonojen/kokoelmien tunnistamiseen. Taas voimme käyttää myös Adobe Acrobatin *sisäinen PDF-rakenne* ominaisuutta tarkastella merkityn sisällön sekvenssejä sisältövirrassa — tässä olemme korostaneet ne vihreällä reunuksella: ![Kuva, joka näyttää merkityn sisällön sekvenssit Adobe Acrobat Pro DC:ssä tarkastellussa tagatun PDF:n sisältövirrassa](/files/73a9090b4a952894858e70105435c9c718c00808) Huomaa, että jotkin sisällön osat on merkitty `/Artifact` joka tunnistaa PDF-sivun materiaalin, joka tulisi *jättää huomiotta* avustavien ohjelmistojen, kuten niiden, jotka lukevat ääneen näkövammaisille ihmisille, toimesta. Seuraava kuvakaappaus näyttää ensimmäisen merkityn sisältösekvenssin laajennetun näkymän — sen, jolla on `MCID:ksi` arvo `0`. Merkityn sisältösekvenssin loppu tunnistetaan PDF-operaattorilla `EMC`. ![Kuva, joka näyttää merkityn sisältövirran kattamien operaattorien yksityiskohdat](/files/dfce3955405e0fd9efa578d193ba6766f6068f06) ### Loogisen rakenteen tallentaminen Kuten todettu, yksittäisten sisältökohteiden (kappaleiden, listojen, taulukoiden jne.) kuvauksen tarjoamisen lisäksi saavutettavien PDF:ien on sisällettävä koko asiakirjan esitys sen loogisen rakenteen muodossa. Yksittäiset saavutettavan sisällön osat on linkitettävä yhteen luodakseen täydellisen, navigoitavan ja saavutettavan asiakirjan — samalla tavalla kuin yksittäinen HTML-asiakirja rakennetaan kappaleista, grafiikasta ja taulukoista verkkosivun muodostamiseksi. Lisäksi on olennaista, että PDF-asiakirjan looginen rakenne varmistaa, että koko sisältöä voidaan selata oikeassa *lukujärjestyksessä*, riippumatta siitä, missä järjestyksessä sivun sisältö on kirjoitettu PDF-sivun sisältövirtoihin. Tutkimme lukujärjestystä tarkemmin alla. #### Looginen rakenne: rakenneosien “puu” Totesimme, että PDF:t käyttävät jotakin nimeltä *rakenneosa* esittämään yksittäisiä sisältökohteita, ja että rakenneosa sisältää tagin, joka tunnistaa, mitä sisältötyyppiä se edustaa. Asiakirjan loogisen rakenteen esittämiseksi kaikki rakenneosat linkitetään toisiinsa vanhempi–lapsi-suhteiden avulla ja järjestetään “rakennepuuksi”. Sisäisesti tagatut PDF-tiedostot sisältävät objektin nimeltä `StructTreeRoot` joka sisältää (osoittaa) rakenneosia, jotka toimivat lähtökohtana tai “juurena” asiakirjan loogisen rakenteen puulle. Yleensä rakennepuun “juuri” alkaa yhdellä rakenneosalla, joka on tagattu `Document` joka sisältää lukuisia *lapsi* rakenneosia, jotka yhdessä edustavat asiakirjan koko sisältöä. Kaikkien ohjelmistojen, jotka on suunniteltu tuottamaan saavutettavia PDF:iä tagauksen avulla, on rakennettava tämä hyvin monimutkainen tietorakenne (ja muita!) — ja siihen kuuluvat TeX-ytimet ja LaTeX. Esimerkki tällaisesta asiakirjan rakennepuusta (`StructTreeRoot`) näkyy seuraavassa kuvakaappauksessa tagatusta PDF:stä, joka on avattu Adobe Acrobat Pro DC:ssä: ![Kuva, joka näyttää StructTreeRootin tagatussa PDF:ssä](/files/43eb6703c354c98f60fd545f856de42547e6c72e) Vertaa yllä olevaa rakennetta tagaamattomaan PDF-versioon: ![Kuva, joka näyttää StructTreeRootin puuttumisen tagaamattomasta PDF:stä](/files/6f3c34d6120b136506a7ca06d52bfde483d738d0) ### PDF:ien loogisen rakenteen tutkiminen Aloitamme joillakin grafiikoilla tiivistääksemme, mitä olemme käsitelleet, ja päätämme videolla, joka käyttää Adobe Acrobat Pro DC:tä näyttämään lisää yksityiskohtia tagatun PDF-tiedoston loogisesta rakenteesta. Ensin aloitamme kaaviolla, joka näyttää yleiset periaatteet: PDF-sivun, jonka sisältövirtaa on merkitty merkityn sisällön sekvensseillä (MCS). ![Grafiikka, joka näyttää merkityn sisällön sekvenssien käsitteen PDF-asiakirjan sivuilla](/files/8a03049175ff8d9c95f7eaff9daae6ee51341eb9) Nämä MCS:t yhdistetään myöhemmin *rakenneosiksi* joista muodostuu perusta suuremmille sisältötyypeille, jotka puolestaan linkitetään edelleen toisiinsa tallentaakseen PDF:n loogisen rakenteen objektin nimeltä `StructTreeRoot`. ![Grafiikka, joka näyttää tagatun PDF-tiedoston loogisen rakenteen](/files/a4eb3dc9c4c7a4f10bf309370922638176aa0224) #### Video, joka näyttää tagatun PDF:n loogisen rakenteen Seuraava video (8 minuuttia) käyttää Adobe Acrobat Pro DC:tä viedäkseen sinut “opastetulle kierrokselle” tutustumaan LaTeXilla tuotetun tagatun PDF-tiedoston loogisen rakenteen yksityiskohtiin. Videossa käytetty tagattu PDF-tiedosto on nimeltään `tagpdf.pdf`, joka on erinomainen esimerkki ja sisältää dokumentaation kokeelliselle LaTeX-paketille [`tagpdf`](https://ctan.org/pkg/tagpdf?lang=en). Paketin `tagpdf` tavoitteena on tarjota “työkaluja tagauksen ja saavutettavuuden kokeilemiseen pdfLaTeXilla ja LuaTeXillä”. {% embed url="" %} ### Huomautus tagauksesta ja joustavuudesta HTML-määritys tarjoaa suuren määrän ennalta määriteltyjä tageja verkkosivujen rakentamiseen, mutta se sallii myös joustavuutta siinä, miten yhdistät niitä valitun HTML-asiakirjan luomiseksi. Samoin Adoben tagatun PDF:n määritys tarjoaa joukon ennalta määriteltyjä taginimiä, mutta asettaa hyvin vähän rajoituksia sille, miten yhdistät nämä tagit esittääksesi monimutkaisia sisältökohteita PDF:ssä — suunnittelun vuoksi joustavuutta on paljon. Lisäksi missä tahansa yhtä laajassa ja monimutkaisessa määrityksessä kuin PDF, on väistämätöntä, että kirjoitettuun määritykseen hiipii joitakin epäselvyyksiä tai selkeyteen liittyviä ongelmia. Tällaisen monimutkaisen määrityksen toteuttamisesta vastaavien ohjelmistokehittäjien on ehkä tehtävä “harkintaratkaisuja” sitä tulkitessaan, koska heidän edessään on muuttaa kirjoitettuja kuvauksia toimivaksi koodiksi. Tagatun PDF:n luontainen joustavuus yhdessä määritysten (tai saavutettavuusstandardien) tulkinnan kanssa vaikuttaa luonnollisesti asiakirjojen luontisovellusten kehittäjiin: mitä tagiyhdistelmiä pitäisi käyttää käyttäjän luoman sisällön esittämiseen, kun se viedään tagattuun PDF-tiedostoon? Jos huomioidaan käyttäjien rajaton kyky rakentaa kaikenlaista sisältöä hyödyntämällä asiakirjanluontiohjelmiston ominaisuuksia, voit nähdä, että saavutettavien tagattujen PDF:ien automaattinen tuottaminen on melkoinen haaste! Ehkäpä tagattujen PDF:ien tuottamisen väistämättömiä monimutkaisuuksia, jotka täyttävät täysin saavutettavuusstandardit, heijastaen verkko on täynnä “ohjeita”, “vinkkejä” ja “parhaiden käytäntöjen” neuvoja tagattujen PDF:ien luomiseen esimerkiksi Adobe InDesignin tai Microsoft Wordin kaltaisilla ohjelmilla. Lisäksi PDF Association on tuottanut hyödyllisen asiakirjan nimeltä [Tagged PDF Best Practice Guide](https://www.pdfa.org/wp-content/uploads/2015/12/StructureElementsBestPracticeGuide_2016-01-19.pdf) joka on kirjoitettu auttamaan kehittäjiä, jotka kohtaavat tagatun PDF:n ja PDF/UA:n toteuttamisen haasteita. ## Onko sinulla PDF, mutta onko se saavutettava? Sen määrittämiseksi, noudattaako tietty PDF-tiedosto vaadittuja saavutettavuusstandardeja, kuten PDF/A tai PDF/UA (katso alla), se on *vahvistettava* käyttämällä sovittua validointiprosessia tai ohjelmistotyökalua. Validointi tapahtuu kuitenkin yleensä sen jälkeen, kun asiakirja on valmis, mutta sen saattaa tehdä ei asiakirjan kirjoittaja vaan organisaation tai tahon saavutettavuusasiantuntijat, joka vaati yhteensopivuutta. Jos PDF ei läpäise validointia, se saattaa vaatia taitavaa manuaalista puuttumista Adobe Acrobat Pro DC:llä tagauksen korjaamiseksi (jos mahdollista). Vaihtoehtoisesti se saattaa joutua palaamaan kirjoittajalle alkuperäisen asiakirjan muokkaamista varten, mahdollisesti välttämällä niiden luontiohjelmiston ominaisuuksien käyttöä, jotka aiheuttivat ongelmat — mikä voi olla erittäin vaikea toteuttaa, koska se saattaa olla kirjoittajan hallinnan ulkopuolella. ### Lukujärjestys ja sisällön järjestys Kuten todettu, todella saavutettavien PDF:ien tuottaminen asettaa lisäteknisiä vaatimuksia luontiohjelmistolle ja mahdollisesti myös asiakirjojen kirjoittajille pakottamalla “kirjoituskurin” siihen, miten he käyttävät/soveltavat luontiohjelmiston ominaisuuksia. Vaikka tagattu PDF on mekanismi, joka *mahdollistaa* täysin saavutettavien PDF:ien tuottamisen, pelkkä PDF:n tagaus ei *sisällä* tarkoita automaattisesti, että se olisi täysin saavutettava, kuten näemme alla olevassa esimerkissä. Tuottaakseen täysin saavutettavia PDF:iä kaikki PDF:n sisältökohteet tulisi tagata, jotta luodaan looginen rakenne, joka varmistaa, että sisältöön voidaan päästä käsiksi ja se voidaan lukea oikeassa järjestyksessä — tätä kutsutaan *lukujärjestyksessä*lukujärjestykseksi *lukujärjestyksessä* : tämä voi vaikuttaa “ilmeiseltä”, mutta kun ohjelmisto kirjoittaa PDF-tiedoston, se voi tulostaa grafiikkaa ja tekstiä sivun sisältövirtoihin missä tahansa järjestyksessä, jonka se valitsee. Esimerkiksi oletetaan, että sivu alkaa tekstillä, jota seuraa taulukko ja päättyy grafiikkaan, mikä antaa luonnollisen 1. teksti 2. table 3. grafiikan Kun tällainen sivu kirjoitetaan PDF:ään, ohjelmisto voisi aloittaa sisältövirran operaattoreilla, jotka piirtävät taulukon, sitten tuottaa operaattoreita grafiikan luomiseksi, minkä jälkeen operaattoreita tekstille, mikä sisältövirrassa tuottaisi *sisällön järjestyksen* : tämä voi vaikuttaa “ilmeiseltä”, mutta kun ohjelmisto kirjoittaa PDF-tiedoston, se voi tulostaa grafiikkaa ja tekstiä sivun sisältövirtoihin missä tahansa järjestyksessä, jonka se valitsee. Esimerkiksi oletetaan, että sivu alkaa tekstillä, jota seuraa taulukko ja päättyy grafiikkaan, mikä antaa luonnollisen 1. table 2. grafiikan 3. teksti Tietenkin kaikki sijoitetaan oikeaan kohtaan, kun kyseinen sivu katsotaan. Täysin näkeville lukijoille se järjestys, jossa nämä kohteet on tallennettu sivun sisältövirtaan, ei ole kiinnostava: he kokevat valmiiksi renderöidyn sivun, jossa kaikki on oikeilla paikoillaan. Jos kuitenkin avustavan ohjelmiston pitäisi tukeutua kohteiden järjestykseen sisältövirrassa (sisällön järjestykseen), se kohtaisi vaikeuksia, jos sisällön järjestys poikkeaa luonnollisesta lukujärjestyksestä; esimerkiksi ääneen lukemiseen tarkoitetut työkalut lukisivat materiaalin väärässä järjestyksessä. Onneksi avustava ohjelmisto voi käyttää tagatun PDF:n loogista järjestystä (rakennetta), joka on järjestettävä heijastamaan järjestystä, jossa sisältö pitäisi lukea. Näistä syistä asiakirjan loogista rakennetta kuvaava tieto tallennetaan erillään varsinaisesta sisällöstä, joka näytetään näkyvillä sivuilla, jotta > “...loogisten sisältöelementtien järjestys ja sisäkkäisyys voivat olla täysin riippumattomia grafiikkaobjektien järjestyksestä ja sijainnista asiakirjan sivuilla.” (sivu 856 lähteestä [The PDF Reference, kuudes laitos, marraskuu 2006](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf)) Käytännössä lukujärjestystä säilyttävän loogisen järjestyksen takaaminen on paljon haastavampaa kuin miltä se saattaa näyttää, joten käytetään yksinkertaista, vaikkakin keksittyä, esimerkkiä, joka antaa viitteitä mukana olevista ongelmista. #### Väärä lukujärjestys: Esimerkki Microsoft Wordia käyttäen Asiakirjan kirjoittaja saattaa käyttää valitsemansa luontiohjelmiston ominaisuuksia saavuttaakseen tietyn visuaalisen vaikutelman — kuten taulukoiden käyttämistä tietyn tekstiasettelun luomiseksi. Esimerkiksi seuraava kuvakaappaus näyttää Microsoft Word -asiakirjan, jota käytettiin aiemmissa esimerkeissä. Se sisältää taulukon, jota on käytetty vierekkäisten numeroitujen kappaleiden joukon luomiseen. Mutta kun kyse on tämän sisällön tagauksesta, miten sitä pitäisi käsitellä: tagattuna taulukkona vai numeroituna listana? Molemmat näistä sisältötyypeistä edellyttävät monimutkaista tagausrakennetta, jotta ne voidaan esittää oikein. Seuraavassa kuvassa huomaa numeroitujen kappaleiden tarkoitetun lukujärjestyksen: sarake sarakkeelta, ei rivi riviltä. ![Microsoft Wordissa luodun taulukon kuva](/files/38a8bfb049b2c4b3702fbbc7086a2b5230e2dc48) Jos pyydämme Wordia tallentamaan tämän asiakirjan PDF-tiedostoksi sen sisäänrakennetun viennin avulla — ei Acrobat PDFMaker -liitännäisen avulla — voimme käskeä sen luomaan tageilla merkityn PDF:n: ![Microsoft Wordin vientiprosessin asetukset-valintaikkuna](/files/331ee7fce6005c2b11de6d5fa515707b97817f86) Miten Word siis merkitsee tämän asettelun? Seuraavassa hyvin lyhyessä videossa (14 sekuntia) käytämme Adobe Acrobat Pro DC:tä tarkastellaksemme Microsoft Wordin tuottamaa merkintärakennetta. {% embed url="" %} Tässä asiakirjassa Word on luonut tageilla merkityn PDF-asiakirjan, joka käyttää `Table` -tagia, joka sisältää kaksi alitagia: `THead` taulukon otsikkorivin ryhmää varten sekä `TBody` esittämään taulukon rungon riviryhmää. `THead` ja `TBody` molemmat sisältävät `TR` tageja yksittäisten sisältörivien esittämiseksi. `TR` tagit sisältävät edelleen tageja, jotka edustavat kussakin solussa olevaa numeroitua luettelokohtaa. Seuraava näyttökuva näyttää syvälle sisäkkäisen merkintärakenteen ja vastaavasti monimutkaisen loogisen rakenteen, jota tarvitaan jopa tämän äärimmäisen yksinkertaisen asiakirjan esittämiseen! ![Kuva, joka näyttää syvälle sisäkkäisen merkintärakenteen ja Microsoft Wordissa luodun yksinkertaisen taulukon loogisen rakenteen](/files/682accba9b0ef15a54bc11fa3c3cbc9055c7e360) TeXin ja LaTeXin tuottamiin PDF-tiedostoihin verrattuna tämä Word-esimerkki on äärimmäisen yksinkertainen asiakirja, mutta silti sen esittämiseen tarvitaan monimutkainen looginen rakenne. Kuvittele, kuinka paljon monimutkaisempi merkintä tarvitaan LaTeXilla tuotettuihin PDF-tiedostoihin, jotka sisältävät monimutkaista matematiikkaa ja taulukoita! #### Tageilla merkitty, kyllä, mutta lukemisjärjestys on väärä Vaikka Word tuottaa [tagatuksi PDF:ksi](https://assets.ctfassets.net/nrgyaltdicpt/3vcgZmG5mkCPYUPTjV30CF/4c34ae919212fa19e979e4cf852e66c1/ReadAloud.pdf) se osoittaa yhden perushaasteista, joita kaikki täysin saavutettavia PDF-tiedostoja tuottamaan pyrkivät sovellukset kohtaavat: sisällön tarkoitetun lukemisjärjestyksen oikea esittäminen. Luotaessa tageilla merkittyä PDF:ää Wordin sisäiset prosessit päättivät kirjoittaa vastaavan sisältövirran tulostamalla taulukon rivi kerrallaan, ei sarake kerrallaan. Täysin näkevälle PDF:n katsojalle näillä matalan tason yksityiskohdilla ei ole merkitystä: taulukko näkyy oikein. Näkövammaisille Wordin looginen asiakirjarakenne tuottaa kuitenkin väärän tuloksen, koska toivottua lukemisjärjestystä (sarake kerrallaan) ei säilytetä: sisältö luetaan ääneen väärässä järjestyksessä. Seuraava äänite on tuotettu Adobe Reader DC:n “Read Out Loud” -ominaisuudella. Kuten huomaat, teksti luetaan ääneen väärässä järjestyksessä: rivi kerrallaan, ei sarake kerrallaan: ![Microsoft Wordissa luotu taulukko](/files/66e5bab97ef35fc953d7feed0ffd7dcf7fbf8cfd) Kuten edellä todettiin, tämä esimerkki on jokseenkin keinotekoinen, mutta se osoittaa hyvin, kuinka helposti ohjelmisto-ominaisuuksien yhdistelmillä voidaan laukaista saavutettavuusongelmia — mutta miten asiakirjan tekijän odotetaan tietävän tämän etukäteen? On todennäköistä, että tämä ongelma havaittaisiin vasta, jos tuloksena syntyvä PDF käy läpi käytännön saavutettavuustestit — esimerkiksi avustavan ohjelmiston avulla. Tällaiset asiakirjat voisivat mahdollisesti läpäistä PDF/A-vaatimustenmukaisuus- ja validointitestit mutta epäonnistua “todellisessa maailmassa” käytettäessä. Tämän kaltaisen PDF-tiedoston oikean lukemisjärjestyksen varmistaminen edellyttäisi taitavaa käsityötä kehittyneillä PDF:nmuokkaustyökaluilla, kuten Adobe Acrobat Pro DC:llä: aikaa vievä ja kallis prosessi. Vaihtoehtoisesti asiakirjan tekijä voisi pidättäytyä käyttämästä tätä tiettyä sisällön esittämisen tai asettelun muotoa — mutta vain jos hän tietäisi sen olevan ongelmallinen! ### Sivujen erottamiseen sanojen välillä käytettävät välilyöntimerkit Kun kirjoitat tekstiä tekstinkäsittelyohjelmiin tai tekstieditoreihin, käytät välilyöntimerkkiä merkitäksesi yhden sanan loppua ja seuraavan alkua. Jos myöhemmin luot tällaisesta asiakirjasta PDF:n, kirjoittamasi välilyöntimerkit tietenkin tulostuvat ja muodostavat osan PDF:ään tallennetusta tekstistä. TeX-moottorit eivät kuitenkaan käytä välilyöntimerkkejä sanojen erottamiseen ladotussa tekstissä; sen sijaan ne muuntavat välilyöntimerkit joustavaksi väliksi, jota kutsutaan liimaksi (katso tämä [Overleafin artikkelista](/latex/fi/syvalliset-artikkelit/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md) lisätietoja TeXin laatikoista ja liimasta). TeX-moottorien luomien PDF-sivujen sisältövirrassa yksittäisten sanojen erottaminen saavutetaan siirtymällä eri kohtaan sivulla ja aloittamalla seuraavan sanan teksti — sen sijaan, että kyseinen väli tuotettaisiin välilyöntimerkillä. Lisäksi TeX-moottorien latoessa tekstikappaleiden sanojen välinen tila vaihtelee riviltä riville TeXin rivinjakoalgoritmin vuoksi. Tämä vaihtelu heijastuu PDF-sivujen sisältövirtaan kirjoitettuihin sijaintitietoihin. Tällä TeXin ladonnan piirteellä on vaikutuksia tekstin kopioimiseen ja liittämiseen sen PDF-tiedostoista sekä avustavaan ohjelmistoon, joka yrittää lukea ääneen TeX-moottorien tuottamiin PDF:iin ladottua tekstiä. Avustavan ohjelmiston on jäsennettävä PDF-sivun sisältövirta poimiakseen käsiteltävän tekstin. Tällaisen ohjelmiston on selvästi jollakin tavalla tunnistettava sanojen alku ja loppu — ilmeisin ratkaisu on käyttää välilyöntimerkkiä. Tätä taustaa vasten saavutettavuusstandardit edellyttävät, että yksittäiset sanat päätetään selvästi (esim. välilyöntimerkeillä), mikä on TeX-moottoreille ongelmallista niiden käyttämän sanojen välisen liiman vuoksi. #### Mutta kaikki ei ole menetettyä! Vuonna 2014 pdfTeX esitteli kaksi uutta primitiiviä saavutettavuuden tukemisen parantamiseksi mahdollistamalla välilyöntimerkkien käytön sanojen välissä tuottamissaan PDF-tiedostoissa: * `\pdfinterwordspaceon` * `\pdfinterwordspaceoff` Nämä komennot käyttävät “näennäistä fonttia”, joka sisältää vain välilyöntiglyyfin. Yksityiskohdat ja esimerkki löytyvät pdfTeX-käyttöohjeen sivulta 29 [pdfTeX User Manual](http://texdoc.net/texmf-dist/doc/pdftex/manual/pdftex-a.pdf). #### LuaTeXin käyttö: Esimerkki Overleaf-galleriassa LuaTeX ei tue näitä pdfTeXin primitiivejä, mutta se voidaan ohjelmoida saavuttamaan hyvin samankaltaisia tuloksia kuin pdfTeX käyttämällä LuaTeXin niin sanottua callback-mekanismia. Overleaf-projekti liiman muuntamiseksi välilyöntimerkeiksi on saatavilla Overleaf-galleriassa otsikolla [LuaTeXin käyttö sanojen välisen liiman muuntamiseen välilyönneiksi ja kernaukseksi](https://www.overleaf.com/latex/examples/using-luatex-to-convert-interword-glue-to-spaces-and-kerns/sfdkdkybrvkv). Jos ladot LaTeX-koodisi LuaTeXillä (eli Overleafin LuaLaTeX-kääntäjävaihtoehdolla), voit Lua-koodia käyttämällä jälkikäsitellä ladotun kappaleen, etsiä siitä mahdollisen sanojen välisen liiman ja korvata sen välilyöntimerkillä sekä sopivalla kernillä. Välilyöntimerkin leveydestä saatu väli voidaan lisätä siihen (tai sitä voidaan vähentää) laskemalla sopiva kerniarvo, jotta sanojen välisen liiman tuottama väli säilyy, jolloin ladotun tuloksen ulkoasu ei muutu. Ymmärtääksesi, mitä eroa tällä on saavutettavuusohjelmiston käyttäjille, kuuntele tämä äänite, joka on tallennettu Adobe Reader DC:n *Read Out Loud* -ominaisuudella. Siinä kaksi projektin tekstiriviä luetaan ääneen ennen liiman muuntamista välilyönneiksi ja sen jälkeen. Huomaa, kuinka rivin toinen lukukerta, jossa käytetään välilyöntejä, luetaan nopeasti ja sujuvasti verrattuna riviin, jossa käytetään sanojen välistä liimaa. Overleaf-projekti on tavallinen TeX-tiedosto, joka käännetään LuaTeXillä ja tarjotaan vain kokeelliseen käyttöön; sitä ei ole tarkoitettu täysipainoiseksi, tuotantotason ratkaisuksi. Pääasiassa se on suunniteltu auttamaan ymmärtämään teknisiä kysymyksiä, jotka liittyvät saavutettaviin PDF-tiedostoihin. Tuossa projektissa käytetty Lua-koodi perustuu paljon aiempaan Overleaf-artikkeliin [Laatikot ja liima: lyhyt, mutta visuaalinen, johdanto LuaTeXillä](/latex/fi/syvalliset-artikkelit/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md). Huomautus: Yksinkertaisuuden vuoksi projekti käyttää omaa hyvin minimaalista OpenType-fonttilataajaansa, joka on johdettu tästä koodista: . ### Muut saavutettavuusongelmat ja tageilla merkitty PDF Vaikka merkintä mahdollistaa PDF:n sisältämien kohteiden tunnistamisen, jotkin sisältötyypit, kuten grafiikka tai monimutkainen matematiikka, tarvitsevat lisätietoja tai -aineistoa, jotta ne voidaan saattaa avustavia ohjelmia käyttävien näkövammaisten saavutettaviksi. Jotta saavutettavuus saadaan aikaan ja sitä voidaan tukea monenlaisille sisältötyypeille, PDF-määritys tarjoaa mahdollisuuden liittää sisältökohteisiin “Alternate Descriptions” tai “ActualText” -tietoja, jotka tarjoavat sopivia tekstimuotoisia kuvauksia tai muita koneellisesti luettavia esityksiä. Esimerkiksi MathML on määritelty tätä tarkoitusta varten PDF 2.0 -määrittelyssä. #### Onko se “oikeaa sisältöä” vai pelkkä artefakti? Näkövammaisille sisällön jakaminen ja näyttäminen suorakulmaisissa, sivun kokoisissa paloissa aiheuttaa ei-toivottuja sivuvaikutuksia, kuten sanojen tavuttamista. Lisäksi sivun suunnittelun tai asettelun piirteet, joita käytetään parantamaan visuaalista esitystä, ovat täysin merkityksettömiä niille, jotka eivät näe niitä. Näistä syistä PDF-sisällön merkinnässä on tunnistettava, että jotkin PDF:n sisällä olevat sisällöt tulisi käsitellä *artefaktina* visuaalisesta esityksestä tai sivutuksesta. Esimerkiksi sivunumerot, sivun ylä- ja alatunnisteet, varjostetut taustat tai muut suunnitteluvihjeet on tunnistettava, jotta sisältöä käsittelevä saavutettavuusohjelmisto tietää ohittaa ne. ## Yleiskatsaus PDF/A-standardeihin Pyyntöihin tuottaa saavutettavia PDF-tiedostoja viitataan yleensä ISO-standardiin nimeltä [ISO 19005](https://www.iso.org/standard/38920.html), johon viitataan yleisemmin PDF/A:na. Koska PDF/A on kuitenkin *perhe* standardien joukko, pelkkä “PDF/A-vaatimustenmukaisuus” ei ehkä määritä täysin todellisia vaatimuksia. Jotta nähdään miksi, aloitetaan lyhyellä katsauksella PDF/A:han PDF Associationin verkkosivustolta [PDF Associationin verkkosivustolta](https://www.pdfa.org/resource/iso-19005-pdfa/) (käytetty 21. toukokuuta 2020), jossa ISO 19005 (PDF/A) kuvataan seuraavasti: > “ISO 19005:n ensisijainen tarkoitus on määritellä PDF:ään perustuva tiedostomuoto, joka tunnetaan nimellä PDF/A ja joka tarjoaa mekanismin sähköisten asiakirjojen esittämiseen tavalla, joka säilyttää niiden staattisen visuaalisen ulkoasun ajan myötä riippumatta tiedostojen luomiseen, tallentamiseen tai renderöintiin käytetyistä työkaluista ja järjestelmistä. > > ISO 19005:n toissijainen tarkoitus on määritellä kehys sähköisten asiakirjojen loogisen rakenteen ja muun semanttisen tiedon esittämiseen vaatimukset täyttävissä tiedostoissa. > > Toinen ISO 19005:n tarkoitus on tarjota kehys sähköisten asiakirjojen kontekstin ja historian tallentamiseen metatietoina vaatimukset täyttävissä tiedostoissa.” On selvää, että PDF/A:lla on useita keskeisiä tavoitteita. ### PDF:n kehitys ja kasvu Se [PDF 1.0 -määrittely](https://web.archive.org/web/20150617123515/http://acroeng.adobe.com/PDFReference/PDF%20Reference%201.0.pdf) julkaistiin vuonna 1993 ja sisälsi vain 230 sivua. 13 vuotta myöhemmin määrittely [Adoben PDF-versiolle 1.7](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf) on reilusti yli 1000 sivua! Ajan myötä PDF-määrittelyn koko ja monimutkaisuus on kasvanut tukien ominaisuuksien lisäämisen myötä: se kattaa uusia teknologioita sekä yhä kehittyneempien PDF-pohjaisten työnkulkujen ja käyttötapausten vaatimuksia eri markkinoilla ja yhteisöissä. On kuitenkin todennäköistä, ettei mikään käyttäjä tai käyttäjäjoukko koskaan hyödynnä kaikkia mahdollisuuksia: PDF:n on katettava kaikki osa-alueet varmistaakseen, että se pystyy palvelemaan mahdollisimman laajan markkinan tarpeita. Esimerkiksi monia PDF-ominaisuuksia, jotka on suunniteltu tukemaan korkeatasoista kaupallista tulostusta, ei tarvita tavallisessa päivittäisessä toimistokäytössä dokumentaation tallennus- tai jakomuotona. ### PDF/A: “takaisin perusasioihin” PDF:lle PDF/A:n keskeisenä tavoitteena on varmistaa, että vaatimukset täyttävät PDF-tiedostot soveltuvat pitkäaikaiseen arkistointiin tai sisältävät sellaista sisältöä, joka on saavutettavissa erilaisia avustavia teknologioita käyttäville ihmisille näiden PDF:ien “kuluttamiseksi”. Näiden tavoitteiden saavuttamiseksi PDF/A rajoittaa vaatimukset täyttävissä PDF-tiedostoissa sallittujen PDF-ominaisuuksien joukkoa ja kieltää sellaisten ominaisuuksien käytön, jotka voisivat vaarantaa arkistoitavuuden tai saavutettavuuden. Voit ajatella PDF/A:ta standardien joukkona, joka määrittää, miten vaatimukset täyttävät PDF-tiedostot käyttävät *osa* täyden PDF-määrittelyn osajoukkoa tuottaakseen tiedostoja, jotka soveltuvat pitkäaikaiseen arkistointiin tai joiden sisältö on saavutettavaa. PDF/A:n rajoitukset mahdollistavat PDF-tiedostojen käytön “arkistoitavana digitaalisena paperina”, joka on riippumaton PDF:n lukuun käytetystä teknologiasta ja käyttöympäristöstä. Vaatimukset täyttävissä PDF-tiedostoissa ei tulisi olla mitään, jonka käyttäytyminen on “toteutusriippuvaista” — eli riippuu niistä ohjelmistoista tai käyttöjärjestelmistä, joita käytetään niiden katseluun tai käsittelyyn. PDF-tiedostojen on myös oltava *täydellisiä*: keskeiset asiakirjaresurssit on upotettava tiedostoon — kuten fontit tai väriprofiilit. ### PDF/A-versiot ja vaatimustasot PDF/A-standardista on olemassa eri *versiot* versioita, joista kukin vastaa tiettyä virallisen PDF-määrittelyn versiota (PDF 1.4, 1.7 ja 2.0). Lisäksi on olemassa erilaisia *vaatimustasoja* , jotka määrittävät, mitä PDF/A-standardin osa-aluetta tai osa-alueita PDF-tiedosto noudattaa. Siksi väittäessäsi tai vaatiessasi “PDF/A-vaatimustenmukaisuutta” sinun tulisi ajatella PDF-tiedostoja, jotka ovat vaatimustenmukaisia **PDF/A-** Esimerkiksi * PDF/A-1a: tarkoittaa PDF/A:n versiota 1, vaatimustasoa a * PDF/A-2b: tarkoittaa PDF/A:n versiota 2, vaatimustasoa b Tarkastelemme näitä hieman tarkemmin. #### PDF/A-versiot PDF/A-standardi on ISO:n alaisuudessa ja julkaistu ISO 19005 -nimisenä standardina. Kuten todettiin, PDF-määrittely on kehittynyt ajan myötä, mikä puolestaan on edellyttänyt ISO 19005:n päivityksiä, minkä seurauksena alla oleva taulukko syntyi: | | | | | ---------------- | ----------------- | ------------------------- | | **PDF/A-versio** | **ISO-standardi** | **Perustuu PDF-versioon** | | PDF/A-1 | ISO 19005-1:2005 | PDF 1.4 | | PDF/A-2 | ISO 19005-2:2011 | PDF 1.7 | | PDF/A-3 | ISO 19005-3:2012 | ISO 32000-1 (PDF 1.7) | Tätä kirjoitettaessa (huhti/toukokuu 2020) päivitetty PDF/A-4 (ISO 19005-4) on [valmisteilla](https://www.iso.org/standard/71832.html). #### PDF/A-vaatimustasot Kolmen PDF/A-version (PDF/A-1, PDF/A-2 ja PDF/A-3) lisäksi on kolme *vaatimustasoja*: * Taso A (saavutettava) saavutettavuuteen (sisältää tason B arkistointivaatimukset) * Taso B (perustaso) arkistointiin * Taso U (Unicode) (= arkistointi sekä Unicode tekstille) Tässä lyhyt kuvaus näistä vaatimustasoista: * **Taso B (perustaso)** on PDF/A-yhteensopivuuden vähimmäisvaatimus. Se määrittelee vaatimukset, joilla varmistetaan, että vaatimukset täyttävät PDF-asiakirjat soveltuvat pitkäaikaiseen arkistointiin — että niitä voidaan aina katsella tai tulostaa luotettavasti riippumatta tietystä ohjelmistosta, työkaluista tai käyttöjärjestelmistä. * **Taso A (saavutettavuus)** sisältää tason B vaatimustenmukaisuuden vaatimukset, mutta lisäksi edellyttää tageilla merkityn PDF:n käyttöä loogisen rakenteen ja lukemisjärjestystietojen tarjoamiseksi sekä Unicodea asiakirjan tekstin käyttämisen mahdollistamiseksi. * **Taso U (Unicode)** vaatimustenmukaisuus lisättiin PDF/A-2:een, ja se rakentuu tason B varaan edellyttämällä lisäksi Unicodea asiakirjan tekstille, mutta se ei mene yhtä pitkälle kuin taso A, koska se ei edellytä rakenneinformaatiota. PDF/A-versiot ja vaatimustasot voidaan tiivistää taulukkoon: | | | | | | --------------------- | ------------------------------------------ | -------- | -------- | | **Vaatimustaso** | **PDF/A-** | | | | Taso A (saavutettava) | PDF/A-1a | PDF/A-2a | PDF/A-3a | | Taso B (perustaso) | PDF/A-1b | PDF/A-2b | PDF/A-3b | | Taso U (Unicode) | Ei sovellu (ei ollut olemassa PDF/A-1:lle) | PDF/A-2u | PDF/A-3u | ### PDF/UA (“yleinen saavutettavuus”) Vaikka PDF/A-standardin taso A -vaatimustenmukaisuus määrittelee joitakin vaatimuksia saavutettaville PDF-tiedostoille, toinen ISO-standardi nimeltä [ISO 14289](https://www.iso.org/standard/64599.html), johon viitataan nimellä PDF/UA, menee pidemmälle. PDF/UA vahvistaa saavutettavuusvaatimuksia ja selkeyttää PDF/A-standardien sisältämiä ohjeita, ja siitä on tullut ensisijainen standardi saavutettaville PDF-tiedostoille. #### Matterhorn-protokolla Lukijoita, joita kiinnostaa syventyä PDF/UA-vaatimustenmukaisuuteen, saattaa kiinnostaa [Matterhorn-protokolla](https://www.pdfa.org/resource/the-matterhorn-protocol-1-02/) , joka on “luettelo kaikista mahdollisista tavoista epäonnistua PDF/UA-vaatimustenmukaisuudessa”. ### Validointiohjelmisto Tarkistaaksesi, noudattaako PDF-tiedosto jotakin tiettyä standardia, se on *vahvistettava* validointiohjelmistolla, joka käy PDF:n läpi ja tarkistaa, vastaavatko sen sisältö ja rakenne kyseisen standardin vaatimuksia — kuten PDF/UA:n tai PDF/A-*x*a:n (jossa *x* = 1, 2 tai 3). Huomaa, että PDF-tiedostojen validointi — niiden käsitteleminen valitulla validointityökalulla — voi tuottaa diagnostiikkaviestejä tai varoituksia, jotka voivat olla epäasiantuntijalle varsin kryptisiä — ehkä jonkin matalan tason PDF-datan (tai rakenteen) vuoksi, joka ei täytä kyseistä standardia. Monille tekijöille näiden varoitusten tulkitseminen ja niiden muuntaminen käytännön korjaukseksi heidän asiakirjaansa tai asiakirjoihinsa voi olla varsin haastavaa. #### Ilmainen validointiohjelmisto * [veraPDF](https://verapdf.org/) joka heidän verkkosivustonsa mukaan (käytetty 28. toukokuuta 2020) on “tarkoitukseen rakennettu, avoimen lähdekoodin tiedostomuodon validaattori, joka kattaa kaikki PDF/A-osat ja vaatimustasot”. * (vain Windowsille) [PDF Accessibility Checker (PAC 2024)](https://pac.pdf-accessibility.org/en/download) joka on “...ilmainen PDF:n saavutettavuuden tarkistustyökalu, jota on kokeiltu ja testattu vuodesta 2010 lähtien”. #### Kaupallinen validointiohjelmisto * [Adobe Acrobat](https://acrobat.adobe.com/uk/en/acrobat/pricing.html) tarjoaa joukon PDF-validointitestejä sekä työkalut ei-vaatimustenmukaisten PDF-tiedostojen merkintöjen muokkaamiseen ja korjaamiseen. ### PDF Association: erinomainen tietolähde Se [PDF Association](https://www.pdfa.org/) tuottaa monia *erinomaista* resursseja PDF/A:sta, PDF/UA:sta ja monista muista PDF:ään liittyvistä aiheista — mukaan lukien videoita heidän [YouTube-kanavallaan](https://www.youtube.com/user/ThePDFAssociation/playlists) sekä artikkeleita ja ilmaisia teknisiä julkaisuja heidän verkkosivustollaan. Yksi tällainen julkaisu on [PDF/UA pähkinänkuoressa](https://www.pdfa.org/resource/pdfua-in-a-nutshell/) joka tarjoaa korvaamattoman johdannon PDF/UA-standardiin ja sen vaatimuksiin. ## Saavutettavat PDF-tiedostot TeX-moottoreista ja LaTeXista Toivottavasti edellä käydyt keskustelut ovat osoittaneet, että täysin saavutettavien ja oikein merkittyjen PDF-tiedostojen tuottaminen on vaativa tekninen haaste. Lisäksi jopa yksinkertainen Microsoft Word -esimerkki osoitti, että tekijät voivat hyvin helposti käyttää ohjelmisto-ominaisuuksien yhdistelmiä, jotka johtavat tageilla merkittyihin PDF-asiakirjoihin, jotka eivät täytä saavutettavuuskriteerejä. Tekijätyökaluna LaTeX tarjoaa kirjoittajille lähes rajattoman joustavuuden luotavien asiakirjojen laajuudessa ja monimutkaisuudessa — mikä saattaa olla juuri se syy, miksi se alun perin valitaan. LaTeX tukee myös laajennettavuutta tuhansien lisäosapakettien kautta, joita tekijät voivat käyttää osana asiakirjojaan. Kaiken tämän lisäksi tekijöillä on vapaus kirjoittaa uusia TeX- tai LaTeX-makroja tai määritellä olemassa olevia uudelleen saavuttaakseen tiettyjä vaikutuksia. Mutta ehkä tällä vapaudella ja joustavuudella on hintansa, koska kaikkien niiden LaTeX-pakettien ja makrojen lukemattomien vuorovaikutusten tuottama sisältö on “jollakin tavalla” orkestroitava, jos LaTeXin halutaan generoivan automaattisesti oikein merkityt ja saavutettavat PDF-tulosteet. Käytännössä LaTeXin tarjoama laajennettavuus, teho, monipuolisuus ja tekijän “vapaus” asettavat teknisiä haasteita täysin saavutettavien tageilla merkittyjen PDF-asiakirjojen saumattomalle ja läpinäkyvälle (“automaattiselle”) tuottamiselle, joka on PDF/UA- tai PDF/A-{1|2|3}a-standardien mukaista. Laajempi TeX- ja LaTeX-yhteisö pyrkii kovasti vastaamaan näihin haasteisiin, ja TeX User Group (TUG) koordinoi tutkimus- ja kehitystyötä PDF:n saavutettavuuden ja PDF-standardien [työryhmän](https://www.tug.org/twg/accessibility/). Siellä on [keskustelulista](https://tug.org/mailman/listinfo/accessibility) , joka tarjoaa tavan kiinnostuneille osapuolille keskustella tageilla merkittyjen PDF-tiedostojen tuottamisesta TeXin ja LaTeXin avulla. Näissä keskusteluissa on hyvä muistaa, että LaTeX ei itse asiassa ole suoritettava ladontaohjelma, vaan se on suuri kokoelma kehittyneitä makroja (komentoja), jotka on kirjoitettu alemmantason kielellä nimeltä TeX. Huolellisesti laaditun LaTeX-asiakirjasi ja lopullisen ladotun PDF:n välissä on ohjelmistoa nimeltä TeX-moottori, jonka tehtävänä on “suorittaa” LaTeX-komentojen (eli makrojen) kokoelma, jota käytetään asiakirjasi kirjoittamiseen ja rakentamiseen — muuntaen ne asiakirjasi ladotuksi esitykseksi, joka tallennetaan PDF-tiedostona. TeX/LaTeX-ekosysteemiin uudet tulijat hämmentyvät usein, ja aivan ymmärrettävästi, niiden työkalujen runsaista salaperäiseltä kuulostavista nimistä, joihin he törmäävät: TeX, LaTeX, pdfTeX, pdfLaTeX, XeTeX, XeLaTeX, LuaTeX ja LuaLaTeX. Jos sinä tunnet samoin, apua on saatavilla Overleaf-artikkelissa [Mitä nimi kertoo: opas TeXin moniin muotoihin](/latex/fi/syvalliset-artikkelit/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md) joka selittää kaikkien näiden termien alkuperän ja merkityksen. TeX-moottorit, kuten pdfTeX, XeTeX tai LuaTeX, ovat ohjelmistoluokka nimeltä *asiakirjakääntäjät*: ne ottavat LaTeX-koodisi ja kääntävät sen ladottuun muotoonsa “muuntamalla” LaTeX-makrot (komennot) takaisin niiden alemman tason TeX-kielen ohjeiksi, jotka “suoritetaan” ladotun tuloksen tuottamiseksi. TeX-pohjaiset ladontajärjestelmät pystyvät tuottamaan poikkeuksellisen monimutkaista sisältöä — mukaan lukien edistynyt matematiikka, nuottikirjoitus, kemialliset rakenteet, grafiikka ja kehittynyt monikielinen ladottu teksti. Varmistaakseen, että nämä monimutkaiset asiakirjat täyttävät saavutettavuusstandardit ja -säädökset, TeX-moottoreiden sekä LaTeX-makrokokoelman ja LaTeX-pakettien on tuotettava asianmukaisesti merkittyjä PDF-tiedostoja upottamalla suuri määrä lisätietoa luomiinsa PDF-tiedostoihin. Vaikka TeX-moottorit voivat luoda äärimmäisen monimutkaisia PDF-tiedostoja, niiden sisäisillä prosesseilla, algoritmeilla ja funktioilla ei ole *sisäänrakennetussa* ominaisuuksia *jotka on erityisesti suunniteltu* tukemaan tageilla merkittyjen ja saavutettavien PDF-tiedostojen tuottamista. Sen sijaan merkinnän ja saavutettavuuden tuki on toteutettava monimutkaisella makro-ohjelmoinnilla, joka “injektoi” lisätietoja TeX-moottorien tuottamiin PDF-tiedostoihin — luoden PDF:ssä tallennetut merkityn sisällön jaksot, rakenneosat ja loogisen rakenteen tietorakenteet `StructTreeRoot`. Ja tässä se “orkestrointi” korostuu: LaTeXin ytimen (kernel) koodi yhdessä tuhansien pakettien ja lukemattomien tekijän luomien makrojen koodin kanssa pitäisi toimia hyvin huolellisesti yhdessä varmistaakseen, että makrojen suoritus tuottaa tuloksena syntyvän asiakirjan sisällön oikean merkinnän. Tämän “orkestroinnin” pitäisi olla luotettavaa — riippumatta siitä, miten tekijät valitsevat käyttää ja yhdistellä LaTeXin ominaisuuksia, komentoja ja toiminnallisuutta, sen pakettijärjestelmää ja TeX-makrojen voimaa. ### Tekijöiden tarpeet Useimmille LaTeX on vain työkalu, jonka avulla voit luoda kauniisti ladottuja asiakirjoja ja valita vapaasti paketteja auttamaan tavoitteen saavuttamisessa. Suurin osa LaTeX-tekijöistä haluaa yksinkertaisesti, että heidän asiakirjansa “toimivat”: että ne ladotaan ilman virheitä, jotta he voivat toimittaa väitöskirjansa, artikkelinsa tai raporttinsa tai saattaa päätökseen sen kauan odotetun kirjan. Ei ole kohtuutonta, että LaTeXin käyttäjät odottavat valitsemansa LaTeX-pakettien kokoelman elävän rauhanomaisesti rinnakkain ja toimivan saumattomasti ja läpinäkyvästi yhdessä tarjotakseen komennot ja ominaisuudet, joita asiakirjojen tuottamiseen tarvitaan. Samaa toiveikkuutta löytyy todennäköisesti, kun edessä on vaatimus tuottaa LaTeXista tageilla merkitty PDF: sen pitäisi “vain toimia”, läpinäkyvästi ja mahdollisimman vähällä tekijän puuttumisella. Valitettavasti olemme vielä kaukana kokemuksesta “Hei, presto! merkintä vain tapahtuu riippumatta siitä, mitä kummallista teen”. Saavutettavuuden teknisten vaatimusten yhdistäminen tageilla merkittyyn PDF:ään ja LaTeX-tekijyyden vapauteen on lähtökohtaisesti monimutkaista, ja ehkä on väistämätöntä, että jonkinlainen “tekijäkurinalaisuus” voi olla tarpeen, jos tekniset haasteet halutaan saada käytännön toteutuksen ja ratkaisun kannalta hallittaviksi. Erillinen, mutta siihen liittyvä kysymys on, että väärä merkintä ei ehkä näy lainkaan lopullisessa PDF:ssä: visuaalisesti se voi näyttää täydelliseltä ja todennäköisesti tulostuu myös ongelmitta, mutta tekijän tietämättä merkintä voi olla “rikki”, ja se havaitaan vasta myöhemmin PDF/A-vaatimustenmukaisuuden/validoinnin epäonnistumisen ja/tai lisäkäytännön testauksen kautta esimerkiksi ruudunlukijoiden kaltaisilla saavutettavuusohjelmilla. ### Overleafissa tuotetut PDF-tiedostot Overleaf tarjoaa käyttäjäyhteisölleen selainpohjaisen LaTeX-editorin sekä projekti- ja asiakirjahallintatyökalut, jotka helpottavat yhteistoiminnallista kirjoittamista — kaikki rakennettuna tavallisen TeX Live -asennuksen päälle. Käytännössä Overleaf antaa käyttäjien “ajaa LaTeXia etänä” verkkoselaimen kautta, tarjoten eristekerroksen täyden TeX Live -järjestelmän hallinnan ja ylläpidon monimutkaisuuksilta. Se, että Overleaf käyttää tavallista TeX/LaTeX-asennusta, tarkoittaa, että Overleafin editorissa kirjoitetusta LaTeX-koodista tuotetut PDF:t luodaan täsmälleen samoilla teknologioilla, joita on missä tahansa muussa saman version TeX Live -asennuksessa — mukaan lukien käyttäjien paikallisille laitteille asentamat kokoonpanot. Ainoa ero on, että Overleafin LaTeX-koodia kääntävät ja käsittelevät TeX-moottorit toimivat etäpalvelimilla, eivät paikallisilla koneilla. Overleaf kyllä linearisoi TeX:n tuottaman PDF:n tehokasta selaimeen lataamista/näyttöä varten, mutta tuo prosessi ei liity itse PDF-sisällön saavutettavuuteen. Saavutettavien PDF-tiedostojen tuottaminen Overleafin kautta perustuu tavallisiin TeX-moottoreihin sisäänrakennettuihin ominaisuuksiin sekä sopivien LaTeX-makropakettien saatavuuteen, joita käyttäjät voivat hyödyntää osana asiakirjaansa. Overleafilla luotujen LaTeX-asiakirjojen on pysyttävä yhteensopivina muiden TeX- ja LaTeX-asennusten kanssa, koska käyttäjien on usein vietävä LaTeX-projektinsa Overleafista toimittaakseen ne monenlaisiin kustantajien tai lehtijärjestelmien käyttöön. Overleaf-kohtaisten ominaisuuksien lisääminen sen LaTeX-asiakirjoihin tai taustalla oleviin TeX-moottoreihin rajoittaisi vakavasti käyttäjien vapautta käyttää työtään muualla. Overleaf tunnistaa ja tukee tarvetta tuottaa TeX/LaTeX-tekijäjärjestelmillä täysin saavutettavia PDF-tiedostoja: käytämme aikaa saavutettavuusongelmien tutkimiseen, TeX-moottorien uusimpien kehityssuuntien ja kokeellisten LaTeX-pakettien, jotka tukevat tageilla merkittyä PDF:ää, tutkimiseen. Lopulta tämän kirjoitushetkellä ei ole olemassa “suoraan paketista” -ratkaisua, jota LaTeX-tekijät voisivat käyttää (kautta `\usepackage`) tuottaakseen saumattomasti ja läpinäkyvästi täysin saavutettavia ja PDF/UA-vaatimusten mukaisia PDF-tiedostoja yleisistä LaTeX-asiakirjoista. Kun tällaiset ratkaisut tulevat saataville TeX Live -päivitysten kautta, ne tulevat tietenkin saataville myös Overleafin käyttäjäyhteisölle. ### Joitakin LaTeX-paketteja merkinnän ja saavutettavuuden tutkimiseen Monille ihmisille, [tex.stackexchange](https://tex.stackexchange.com/) on monille ensimmäinen osoite apua varten TeXiin, LaTeXiin tai ConTeXtiin liittyvissä asioissa. Se on upea resurssi ja sisältää monia kysymyksiä aiheesta [saavutettavuus](https://tex.stackexchange.com/questions/tagged/accessibility?tab=Newest) ja saavutettavien PDF-tiedostojen tuottamisesta LaTeXin avulla. Jos luet ja selaat näitä kysymyksiä sekä niitä seuraavaa vastausten ja kommenttien virtaa, vain yksi johtopäätös on väistämätön: tällä hetkellä ei ole täydellistä, tuotantotason ratkaisua täysin saavutettavien, standardien mukaisten, tageilla merkittyjen PDF-tiedostojen automaattiseen luomiseen kaikentyyppisistä LaTeX-asiakirjoista. On kuitenkin olemassa joitakin paketteja, jotka tukevat merkintää — tosin ehkä rajoitetussa käyttötilanteiden ja asiakirjatyyppien joukossa. Seuraava luettelo on tarkoitettu lukijoille, jotka haluavat tutkia LaTeX-pohjaista PDF-merkintää: * [`tagpdf` paketti](https://ctan.org/pkg/tagpdf) (Ulrike Fischer): erittäin kykenevä paketti, joka on suunniteltu kokeilemaan PDF-merkintää. Tukee pdfTeX:iä ja LuaTeX:iä ja tarjoaa erittäin hyödyllistä ja kiinnostavaa dokumentaatiota, joka sisältää erinomaisia huomautuksia TeX-moottorien kautta tuotettujen PDF-tiedostojen luomisen teknisistä haasteista; se on erittäin suositeltavaa luettavaa kaikille, jotka haluavat ymmärtää paremmin asiaan liittyvät ongelmat. Tuleva suunta todennäköisesti LuaTeX. * [`axessibility` paketti](https://ctan.org/pkg/axessibility?lang=en) (Boris Doubrov ja Torinon yliopisto): tarjoaa kaavojen saavutettavuuden PDF-tiedostoissa avustavien teknologioiden avulla. * [`saavutettavuus` paketti](https://ctan.org/pkg/accessibility) (Andy Clifton): luo tageilla merkittyjä ja rakenteisia PDF-tiedostoja. CTAN-muistiinpanojen mukaan tämä paketti on “tarkoitettu KOMA-Script-asiakirjaluokkien käyttäjille”. * [`accsupp` paketti](https://ctan.org/pkg/accsupp) (Heiko Oberdiek): kokeellinen paketti PDF-tiedostojen saavutettavuuden tukemisen parantamiseen. Lisäksi huomionarvoinen viite on vuoden 2018 artikkeli [Implementing PDF standards for Mathematical Publishing](http://web.science.mq.edu.au/~ross/TaggedPDF/PDF-standards-v2.pdf) jonka on kirjoittanut tohtori Ross Moore Macquarien yliopiston matematiikan laitokselta. Tässä artikkelissa tohtori Moore sisällyttää lyhyen katsauksen LaTeXissa tapahtuvan PDF-merkinnän haasteista: > “Vaikeuden pääasiallinen lähde piilee siinä tavassa, jolla eri ympäristöt voivat vaikuttaa toisiinsa. LaTeXissa on monia tilanteita, joissa yhtä ympäristöä tai rakennetta ei oikeastaan ole saatu päätökseen ennen kuin seuraava on alkanut. Kyse ei siis ole vain start- ja finish-tagien asettamisesta jokaisen tarjotun sisältöpalasen ympärille. Sen sijaan on ymmärrettävä erilaisten ympäristöjen ja muiden rakenteiden hienovaraisuudet, miten ne todella alkavat ja päättyvät ympäröivän materiaalin luomassa kontekstissa.” Tohtori Moore on myös nykyinen [`pdfx`](https://ctan.org/pkg/pdfx) paketin ylläpitäjä sekä TeX/LaTeXilla tuotetun tageilla merkityn PDF:n asiantuntija ja uranuurtaja. Hänen työnsä kannattaa ehdottomasti etsiä — mukaan lukien tämä YouTube-video, joka tarjoaa kiinnostavia näkemyksiä: {% embed url="" %} #### Huomautus pdfx-paketista Se [`pdfx`](https://ctan.org/pkg/pdfx) paketti (Ross Moore ym.) tarjoaa erinomaista tukea PDF/A-1|2|3b:lle (arkistointi) ja muille vaihtoehdoille, mutta ei vielä tuota tageilla merkittyä PDF:ää. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://overleaf-pro.ayaka.space/latex/fi/lisaa-aiheita/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.