Vedlegg 4:

Konvertering

Innledning

Dette er mine arbeidsnotater fra diverse tester av konvertering mellom ODF og OOXML. Videre ser jeg på konvertering av det nedarvede Microsoft-formatet .doc til hhv ODF og OOXML.

Disclaimer: Jeg har (ennå) ikke tilgang til profesjonelt valideringsverktøy. Kontroll av konverteringen er derfor basert på kontroll gjennom maskinell sammenligning av XML PCDATA i den originale filen mot XML PCDATA i den konverterte filen (med et egenutviklet verktøy), etterfulgt av subjektiv inspeksjon av resultatet. Dette er selvsagt ikke holdbart i en kritisk sammenheng – men det er likevel bedre enn Rambøll og ECON, som sannsynligvis ikke har forankret sine estimater vedrørende konvertering i noen empiri overhode.

De fleste testene er utført på dokumenter på redigerbart format lastet ned fra kommunale nettsteder. Det gjøres nærmere rede for utvalg og metode til sist i dette vedlegget.

I tillegg er det et eget avsnitt som drøfter å arbeide med (og konvertere) av matematisk notasjon. Dette er neppe en innholdstype som forekommer hyppig på forvaltningens nettsteder, men denne typen innhold er kjent for å skape problemer, og er derfor interessant å undersøke.

Konvertering: Resultat

Tabellen nedenfor viser resultatet av testing av konvertering av i alt 44 dokumenter lastet ned fra kommunale nettsteder.

• 20 dokumenter var av type .doc, og ble konvertert til både OOXML og ODF.
• 20 dokumenter var av type ODF, og ble konvertert til OOXML.
• 4 dokumenter var av type OOXML, og ble konvertert til ODF.

Resultatet framgår av de to neste tabellene.

Testing av konvertering til OOXML

Parameter		.doc-OOXML		ODF-OOXML		Totalt
Totalt:	Antall:	20		20		40	100 %
	Grad A:	18	90 %	16	80 %	34	85 %
	Grad B-E:	1	5 %	2	10 %	3	8 %
	Grad F:	1	5 %	2	10 %	3	8 %
R-O:	Antall:	18	90 %	16	80 %	34	85 %
R-W:	Antall:	2		4		6
	Grad A:	1	50 %	2	50 %	3	50 %
	Grad B-E:	1	50 %	0	0 %	1	17 %
	Grad F:	0	0 %	2	50 %	2	33 %

Av tabellen over framgår det at både ved konvertering fra .doc og fra ODF til OOXML kan det oppstå problemer som kan gi informasjonstap.

Av tabellen går det fram at 85 % av dokumentene er av type R-O (mottaker har ikke behov for å redigere). Disse kan bulkkonverteres til PDF uten fare for informasjonstap.

De resterende dokumentene (type R-W) er ulike former for skjemaer som der mottaker for å fylle ut skjema tenger å ha behov for å kunne redigere dokumentet. Her er konverteringen langt mer kritisk, fordi en automatisk konvertering til PDF ikke vil gi ønsket resultat. Her er det ikke funnet problemer med konvertering .doc-OOXML.

For konvertering fra ODF til OOXML er det klart at avkrysningsbokser ikke fungerer etter konverteringen. I slike tilfelle må dokumentet justeres manuelt etter konvertering.

Testing av konvertering til ODF

Parameter		.doc-ODF		OOXML-ODF		Totalt
Totalt:	Antall:	20		4		24	100 %
	Grad A:	16	80 %	3	75 %	19	79 %
	Grad B-E:	4	20 %	1	25 %	5	21 %
	Grad F:	0	0 %	0	0 %	0	0 %
R-O:	Antall:	18	90 %	2	50 %	20	83 %
R-W:	Antall:	2		2		4
	Grad A:	1	50 %	2	100 %	3	75 %
	Grad B-E:	1	50 %	0	0 %	1	25 %
	Grad F:	0	0 %	0	0 %	0	0 %

Av tabellen over framgår det at verken ved konvertering fra .doc eller fra ODF til OOXML oppsto det under testingen problemer av så alvorlig karakter at den kan oppstå informasjonstap. Dette er selvsagt ingen garanti for at slike problemer ikke eksisterer. Det indikerer imidlertid at sannsynligheten for at det skal oppstå problemer som fører til informasjonstap ved konvertering til ODF, er mindre enn sannsynligheten for at det skal oppstå slike problemer ved konvertering til OOXML.

I min beregning av kostnadene med å ta bruk åpne format på statlige nettsider (Vedlegg 1), har jeg lagt til grunn at 83 % av dokumentene kan bulkkonverteres til PDF. Det betyr ar de resterende 17 % må konverteres til ODF. I mitt testsett på 24 dokumenter har jeg ikke funnet ett eneste dokument som ikke lot seg konvertere automatisk til ODF med et resultat i området grad A-E. Mer omfattende tester vil sikkert avdekke problemer, slik at det reelle tallet er noe større enn 0 %. Men det neppe i nærheten av 40 % (ECONs estimat for 2009).

Tidsforbruk

Maskinell kontroll av en konvertering kan gjøres i bulk og tidsforbruket er i så fall begrenset til tiden det tar å laste opp dokumentene som skal kontrolleres til en kontroll-tjener. Selve kontrollen kan skje uten bruk av arbeidstid.

Mitt forholdsvis primitive verktøy for å sjekke resultatet av en konvertering flagger 34 % av dokumentene med et mulig problem. Av disse har 16 prosentpoeng varierende grad av defekter, mens 18 prosentpoeng er uten synlige defekter (dvs. falske positive). Selv med en så stor andel falske positive mener jeg bruk av slike verktøy vil spare tid. I testperioden gikk jeg grundig gjennom alle konverterte dokumenter (også de der verktøyet indikerte at konverteringen var uten problemer, på jakt etter falske negative. Jeg fant ingen slike.

Visuell inspeksjon tar ikke mye tid pr. dokument. De fleste dokumenter er korte (1-2 sider), og avvik er som regel lette å få øye på. Mitt verktøy gir adgang til tekstlige kontekst for avvik, slik at i lengre dokumenter kan man raskt komme fram til «problemområder» vha. søk. Jeg brukte i gjennomsnitt ca. tre minutter pr. dokument til visuell inspeksjon og gradering.

Tiden som går til å rette opp feil dersom automatisk konvertering ikke gir ønsket resultat er selvsagt avhengig av hvor store avvik man tolererer før man griper inn og konverterer manuelt. Jeg mener at man i en overgangsperiode kan tåle avvik helt opp til og med grad E, slik at kun feil av grad F må rettes gjennom manuell inngripen.

Men for å få en føling med tidsforbruket for å rette avvik rettet jeg alle avvik jeg kom over under utprøvingen. Tiden det tok pr. feil varierte fra ca. 1 sekund (flytte en illustrasjon fra en side til en annen vha. cut&:paste), til ca. 20 sekunder (lås skjema). Mitt erfaringsmateriale er forholdsvis begrenset, men at dette skal ta 10 minutter pr. dokument i gjennomsnitt (ECONs estimat) er svært lite sannsynlig.

Defekter

Nedenfor er mine (foreløpige) funn av hva slags defekter utprøvingen avdekket. For hver defekt har jeg oppgitt min (subjektive) bedømmelse av defekten på min graderingsskala.

Ren tekst

Testing har så langt ikke avdekket annet enn mindre (grad A-C) layoutmessige avvik ved konvertering av ren tekst mellom ODF og OOXML, og omvendt.

.doc–OOXML

For konvertering fra .doc til OOXML er det med Convert-kommandoen i Microsoft Word 2007 er det observert en del større avvik (se eksempel under).

Et fragment av dokumentet http://www.stavanger.kommune.no/saksdok.doc ser slik ut når det vises i Microsoft Office 2003:

Etter konvertering til OOXML ser samme fragment slik ut:

Informasjon er ikke tapt, men det er en del å utsette på den grafiske gjengivelsen (grad E).

Problemet løses ved følgende manuell operasjon: Home → Clear formatting etterfulgt av re-applisering av riktig format (i dette tilfellet Numbering). Tidsforbruk for manuell operasjon: ca. 5 sekunder pr, instans.

Skjema

En andel av de redigerbare dokumentene er skjema som skal fylles ut på datamaskinen. Disse kan med andre ord ikke konverteres til pdf. For skjemaer er det altså mer kritisk at automatisk konvertering gir et tilfredsstillende resultat, enn for andre typer dokumenter.

Andel skjema i testsett: 18 % (8 av 44 dokumenter)

Testing har så langt ikke avdekket annet enn mindre (grad A-C) layoutmessige avvik ved konvertering av skjemaer fra .doc/OOXML til ODF.

ODF–OOXML

Ved konvertering fra ODF til OOXML med Suns plugin-konverter opphører tilsynelatende avkrysningsbokser (FORMCHECKBOX) å fungere. De vises i det konverterte dokumentet, men det har ingen effekt å krysse av (grad F).

Årsaken er at i Microsoft Word 2007 må et dokument være «låst» for at et skjema skal være aktivt. Det automatiske verktøyet konverterer skjemaet, men låser ikke dokumentet. Problemet løses ved å lagre dokumentet som OOXML, deretter lese det inn igjen, utføre følgende manuelle operasjon: Developer → Protect Document → Restrict Formatting and Editing → Allow only this type of editing → Filling in forms → Start Enforcing Protection, og lagre på nytt. Tidsforbruk for manuell operasjon: ca. 20 sekunder pr. dokument.

Illustrasjoner

Plassering av flytende illustrasjoner er et kjent problem med Microsoft Office 2003. Ved re-paginering kan en slik illustrasjon «flyter» over til en annen side, med uforutsigbart resultat. Det virker som dette dessverre ikke er løst i Microsoft Office 2007, slik som eksemplet nedenfor (hentet fra http://www.stavanger.kommune.no/saksdok.doc) viser.

Hele side 19 i originalen består av et skannet dokument, som er lagt inn som en bitkart-illustrasjon. Slik vises dette i Microsoft Office 2003:

Etter konvertering til OOXML er dokumentet re-paginert, og illustrasjonen har flyttet seg over på side 20. Her er det interferens fra en annen illustrasjon (som befant seg øverst på side 20 i originalen). Denne er imidlertid liten, slik at dette ikke fullt ut forklarer hvorfor halve siden er blitt uleselig. Dette er et eksempel på en defekt som innebærer informasjonstap (grad F).

Problemet løses ved følgende manuelle operasjon: Flytt illustrasjonen tilbake på den siden den opprinnelig befant seg: Cut → Paste. Tidsforbruk for manuell operasjon: ca. 1 sekund pr. instans.

Figuren under viser siden etter konvertering til OpenOffice.org Writer. Her er pagineringen intakt, og dermed ødelegges ikke visingen av den skannede siden.

Bitkart-illustrasjonen er skannet i en oppløsning som egner seg for utskrift. Alle tre kontorverktøyene må derfor re-skalere for å vise illustrasjonen på skjerm. De to versjonene av Microsoft Word har helt klart en bedre algoritme for dette (sannsynligvis bicubic interpolasjon), mens OpenOffice.org 2.3.1 benytter en mindreverdig skaleringsalgoritme (sannsynligvis nearest neighbour). Teksten i OpenOffice.org Writer er lesbar på skjerm, men jeg vil si at dette er et vesentlig kosmetisk avvik (grad D). Ved utskrift er det imidlertid ingen synlig forskjell.

Som en kuriositet kan nevnes at dersom vi lagrer den versjonen av dokumentet som er konvertert fra .doc som ODF, og så konverterer denne fra ODF til OOXML, så er alt tilsynelatende i orden igjen. Man får, i alle fall for dette dokumentets del, en bedre resultat ved å konvertere fra .doc til OOXML via ODF, enn å konvertere direkte .doc-OOXML!

Forretningsgrafikk

[kommer]

WordArt–Fontwork

Microsoft Word har en feature som kalles «WordArt», og som produserer en distinkt type «dekorativ» typografi. OpenOffice.org har en lignende feature som kalles «Fontwork». Ved konvertering fra OOXML til ODF gjøres «WordArt» om til «Fontwork». Ofte endrer dekorasjonen utseende ved en slik konvertering.

Avviket illustreres under med et fragment fra http://www.malvik.kommune.no/vikhammerskole/PROSJEKTET.VERDEN/Asia%207B/Industri.docx. Det første bildet er en skjermdump av originalen slik det vises i Microsoft Office 2007. Det andre bildet viser samme utsnitt etter konvertering til ODF i OpenOffice.org:

En slik defekt er av meg gradert som grad C (middels kosmetisk avvik).

Matematisk notasjon

Uheldigvis betjener ODF og OOXML seg av ulike markeringsspråk for matematisk notasjon. ODF benytter MathML (Mathematical Markup Language), som er en standard for markering av matematikk definert av W3C. I OOXML benytter et annet format som Microsoft kaller OMML (Office Mathematical Markup Language). Det har så langt gjort det umulig for applikasjoner med utgangspunkt i hhv. ODF og OOXML å forstå hverandres matematiske notasjon.

.doc–OOXML

OMML er nytt i i Microsoft Office 2007. I Microsoft Word 2003 (og tidligere?) representeres matematisk notasjon som et innbakt (embedded) binært objekt som håndteres av en separat applikasjon.

Eksempler på slike er verktøy for matematisk notasjon er (Microsoft Equation 3.0)og ulike tredjepartsløsninger (eksempel: MathType). Anskaffer man samme applikasjon til Microsoft Office 2007 kan man redigere disse her.

Jeg har bare testet med Microsoft Equation 3.0 og har ikke funnet noen måte å konvertere nedarvet matematisk notasjon fra denne til OMML.

ECMA-376 åpner for slike innbakte objekter, men sier at i så fall er lagringsformat og tolkning (semantikk) opp til applikasjonen. Et slikt innbakt objekt faller altså utenfor et standard dokumentformat, og derfor utenfor rammen av dette notatet.

.doc–ODF

Ikke testet, siden nedarvede binære formater ikke er relevante.

OOXML–.doc

Som tidligere nevnt støttes OMML-basert matematisk notasjon ikke av tidligere versjoner av Microsoft Office. Microsoft tilbyr en gratis Compatibility Pack som konverterer mellom versjonene. Denne pakken tolker OMML og produserer et bilde som gjengir notasjonen som bitkart-grafikk. Denne grafikken bør ikke redigeres (se under).

Compatibility Pack støtter såkalt round-tripping.

OOXML–ODF

Figuren under viser matematisk notasjon opprinnelig laget i OOXML/OMML. Den er konvertert til ODF vha. Suns plugin og deretter lest inn i OpenOffice.org Writer:

Som det framgår av figuren, har dette resultert i at det har blitt laget et bilde som gjengir notasjonen som bitkart-grafikk. Denne grafikken kan ikke redigeres.

Å lese ODF-dokumentet inn igjen i Microsoft Office 2007 gir oss ikke noen annet enn et bitkart-grafikk. Det er skuffende at Suns plugin ikke støtter såkalt round-tripping av OMML.

ODF–.doc

Lagrer vi som .doc i OpenOffice.org Writer og åpner i Microsoft Office 2003 og 2007, ser vi et (noe defekt) bitkart-bilde i Microsoft Office 2003. Bildet kan ikke redigeres som matematisk notasjon (kun som bitkart-bilde).

Det er imidlertid ikke slik at OpenOffice.org Writer lagrer notasjonen som et bitkart. Som det framgår av skjermdumpene under tegnes notasjonen ulikt i Microsoft Office 2003 (første skjermdump) og Microsoft Office 2007) andre skjermdump):

Men ingen av dem klarer å gjengi notasjonen tilfredsstillende. Parenteser, plusstegn, rottegn, samt den greske bokstaven π er erstattet med vertikale streker. Jeg vet i skrivende stund ikke hva dette skyldes.

Såkalt round-tripping fungerer, også om det gjøres bilderedigering (skalering, rotering, etc.) på bitkart-utgaven av notasjonen. Det innebærer på den annen side at slike endringer går tapt.

ODF–OOXML

Sun tilbyr et plugin (ODF Plugin 1.1) som lar Microsoft Word lese og skrive ODF.

Formlene «embeddes» som redigerbare OpenOffice.org-objekter som kan redigeres ved hjelp av en redigeringsmodul som er en del av Suns plugin.

Figurene nedenfor viser ulike skjermdumper med matematisk notasjon. Den første er originalen fra OpenOffice.org Writer.

Den neste skjermdumpen er hentet fra Microsoft Word 2007, etter konvertering. Notasjonen er redigerbar, og Suns redigeringsmodul er en del av nevnte plugin. Legg merke til at den grafiske representasjonen i redigeringsprogrammet er like godt (eller dårlig jf. symbolet «∞») som originalen.

Den neste skjermdumpen er fra Microsoft Word 2007 etter at vi har lukket redigeringsmodulen:

Som det framgår av den siste figuren er tegning (utenfor redigeringsmodulen) ikke tilfredsstillende. Defektene er identiske til de jeg observerte når jeg tok i samband med konvertering til .doc

Såkalt round-tripping fungerer, også om det gjøres bilderedigering (skalering, rotering, etc.) på bitkart-utgaven av notasjonen. Det innebærer på den annen side at slike endringer går tapt.

Utvalg og metode

Utvalg

Alle filene som inngår i undersøkelsen er lastet ned fra kommunale nettsteder.

I alt 44 dokumenter ble lastet ned. En komplett oversikt over hvilke urler som er lastet ned finnes i arkivet econ00.tar.gz (dl_list.txt).

Nedlastingen skjedde 23. mars 2008.

Filer på .doc-format

Det befinner seg i skrivende stund (mars 2008) omlag 156 000 dokumenter på .doc-formatet på kommunale nettsteder. Disse ble søkt opp i Google, og lastet ned i samme rekkefølge som de presenteres av Google (dvs. PageRank-sortert). Nær-duplikater (for eksempel møtereferater fra ulike møter basert på samme dokumentmal) ble eliminert fra resultatsettet med mindre konverteringen var av grad F). Dokumenter som i utgangspunktet var defekte (lot seg ikke åpne i Word 2003, eller hadde informasjonstap i utgangspunktet) ble ikke undersøkt nærmere.

Så langt er 20 slike filer undersøkt.

Filer på OOXML-format

I testperioden fantes det bare fire dokumenter på kommunale nettsteder på OOXML-formatet .docx. Samtlige 4 er undersøkt. Ingen av dem viste seg å ha behov for manuell konvertering ved konvertering fra OOXML til ODF.

Filer på ODF-format

Det befinner seg i skrivende stund (mars 2008) omlag 117 dokumenter på ODF-formatet på kommunale nettsteder. Disse ble søkt opp i Google, og lastet ned i samme rekkefølge som de presenteres av Google (dvs. PageRank-sortert). Nær-duplikater (for eksempel møtereferater fra ulike møter basert på samme dokumentmal) ble eliminert fra resultatsettet med mindre konverteringen var av grad F).

Så langt er 20 slike filer undersøkt.

Metode

Følgende primære konfigurasjon er benyttet:

• Microsoft Windows XP 2002 SP2
• Microsoft Word 2007 SP1 + Sun ODF Plugin 1.1
• Microsoft Word 2003 SP3 + Microsoft Compatibility Pack
• OpenOffice.org Writer 2.3.1

Dersom konverteringen resulterte i informasjonstap (grad F) ble dokumentet forsøkt konvertert på nytt i OpenXML/ODF Translator Add-in for Office 1.1. Ingen av disse forsøkene ga bedre resultat, slik at alle data i undersøkelsen er basert på Sun ODF Plugin 1.1.

De ulike konverteringene er utført som følger:

.doc-OOXML:

Dokument åpnes i Microsoft Office 2007 med Open-kommandoen og konverteres med Convert-kommandoen. Det lagres deretter vha. Save-kommandoen.

.doc-ODF:

Dokument åpnes i OpenOffice.org Writer med Open-kommandoen. Det lagres deretter som ODF vha. Save As-kommandoen.

OOXML-.doc:

Dokument åpnes i Microsoft Office 2007 med Open-kommandoen. Det lagres deretter som .doc vha. Save As-kommandoen. (Kun testet i samband med med matematisk notasjon.)

OOXML-ODF:

Dokument åpnes i Microsoft Office 2007 med Open-kommandoen. Deretter konverteres til ODF vha. Sun plugin i kombinasjon med Save As-kommandoen.

ODF-.doc:

Dokument åpnes i OpenOffice.org Writer med Open-kommandoen og lagres som .doc med Save As-kommandoen. (Kun testet i samband med med matematisk notasjon.)

ODF-OOXML:

Det lages en kopi av ODF-dokumentet. Dokument åpnes i Microsoft Office 2007 med Sun plugin i kombinasjon med Open-kommandoen og konverteres med Convert-kommandoen. Det lagres det vha. Save-kommandoen.

Evaluering av konvertering gjøres som følger:

Etter at dokumentene er konvertert (som beskrevet over) og lagret, åpnes de på nytt i de respektive verktøy og originalen sammenlignes med den konverterte utgave.

Dersom begge formatene er XML-baserte (dvs. ingen av dem er .doc) gjøres først en maskinell sammenligning av XML PCDATA i den originale filen mot XML PCDATA i den konverterte filen (vha. egenutviklet verktøy i XSLT). Verktøyet rapporterer null dersom det ikke er avvik, og eller et positivt heltall som gir en viss indikasjon på størrelsen på avviket. Dette heltallet loggføres. Verktøyet rapporterer også om dem tekstlige konteksten for avvik, slik at det er mulig (vha. søk) å finne igjen konteksten i dokumentene som bør undersøkes særlig nøye med tanke på avvik.

For visuell inspeksjon benyttes følgende skala:

• Grad A: Intet merkbart synlig avvik.
• Grad B-E: Ulike grader av kosmetiske avvik (men uten informasjonstap).
• Grad F: Manglende funksjonalitet (f.eks. skjema som ikke lar seg utfylle). Layoutmessige eller andre avvik som innebærer informasjonstap.

Begge dokumentene inspiseres og konverteringen graderes i hht. skalaen over. Dersom den automatiske kontrollen avslørte avvik søkes det etter kontekst, og konteksten undersøkes særlig nøye med tanke på gradering. Graden loggføres.

Til sist inspiseres dokumentet inspiseres også med tanke på anvendelse, og klassifiseres som følger:

• R-O: Read-Only – mottaker har ikke behov for dokumentet på et redigerbart format.
• R-W: Read-Write – filen må kunne endres av mottaker.

Denne klassifikasjonen loggføres.

Erfaring med konvertering

To konvertere mellom ODF og OOXML er p.t. tilgjengelig:

• Sun ODF Plugin 1.1
• OpenXML/ODF Translator Add-in for Office 1.1

Den første er utviklet av Sun Microsystems, men er tilgjengelig gratis. Den andre er utviklet av en gruppe frivillige som fri programvare. Prosjektet er imidlertid sponset av Microsoft.

Sun ODF Plugin 1.1 holder profesjonell kvalitet. Konvertering gikk raskt og jeg observerte ingen ustabilitet. I tillegg de feil som er beskrevet tidligere observerte jeg følgende uregelmessigheter:

• Man får ingen spesifikk advarsel når konverteren støter på elementer den ikke kan håndtere.
• ODF-OOXML: Skalering og posisjonering er av og til upresis inntil dokumentet lagres. Det arter seg slik at elementer f.eks. overlapper etter konvertering. Når man så lagrer dokumentet blir skalering og posisjonering igjen «riktig».
• ODF-OOXML: Ved lagring av .docx fjernes den opprinnelige .odt-fila. Dette er svært uheldig design – særlig fordi det er nødvendig å lagre for å evaluere resultatet av konverteringen (jf. forrige punkt). Dersom konverteringen går galt, har man ikke lenger originalen å bearbeide!

Den Microsoft-sponsede konverteren OpenXML/ODF Translator Add-in for Office 1.1 er også stabil. Forøvrig:

• Verktøyet er svært uferdig og burde ikke ha versjonsnummer 1.1. En rekke innholdselementer forsvinner når dokumenter konverteres.
• Man får ingen spesifikk advarsel når konverteren støter på elementer den ikke kan håndtere.

Figuren under viser et utsnitt fra et dokument som blant annet inneholder en overskrift laget ved hjelp av WordArt og en formel skrevet i OOXML sin matematiske notasjon OMML.

Figuren under viser samme utsnitt etter konvertering til til ODF med OpenXML/ODF Translator Add-in for Office 1.1 Dette er et eksempel på en defekt som innebærer informasjonstap (grad F).

I utprøvingen har jeg primært holdt meg til Suns plugin. Den alternative konverteren virker for uferdig til at den har særlig praktisk anvendelse.

Round-tripping

Bruk av XML-lagringsformat gir utstrakt mulighet for såkalt round-tripping. Det innebærer at en applikasjon A gir data til en annen applikasjon B kan B bevare informasjon den ikke forstår (uendret) i en innkapslet XML-container selv om B ikke har tilstrekkelig funksjonalitet til å presentere eller endre denne informasjonen. Når så B leverer dokumentet tilbake til A (eller en annen applikasjon med samme funksjonalitet som A), så er informasjonen intakt.

En typisk anvendelse av round-tripping er måten matematisk notasjon håndteres av Office 2003 og Office 2007. Office 2003 forstår ikke OMML (XML-formatet som brukes til å representere matematisk notasjon i Office 2007), og kan derfor ikke tilby redigering av slik matematisk notasjon. I stedet erstattes notasjonen med et bilde som ikke kan redigeres. Men når dokumentet konverteres tilbake til OOXML er også OMML intakt og den matematiske notasjonen kan redigeres igjen.

Innholdsfortegnelse

• Notat: Formater til besvær
• Vedlegg 1: Åpne format på statlige nettsider
• Vedlegg 2: Kostnader: Konvertering av nye dokumenter
• Vedlegg 3: Andre kostnader
• Vedlegg 4: Konvertering
• Etterord: Om å analysere en elefant
• Referanseliste og takk

---

Copyright © 2008 Gisle Hannemyr. Noen rettigheter reservert. Dette verket er tilgjengelig under en Creative Commons Navngivelse-Ikkekommersiell-DelPåSammeVilkår 3.0 Lisens.

---