Tyske forskere: Umuligt at konvertere frit mellem ODF og OOXML

Ja, der er jo nogle af os, der vil sige, at det har vi vidst i flere år - men jeg håber da, at det nu endeligt når frem til politikerne, så de stopper med at tale om "interoperabilitet imellem dokumentformater".

Den manglende mulighed for konvertering er jo netop for helvede grunden til, at vi ikke skal stille os tilfredse med fattigmandsunderstøttelse af hverken ODF eller OOXML i de gængse kontorpakker.

Ja, der er jo nogle af os, der vil sige, at det har vi vidst i flere år - men jeg håber da, at det nu endeligt når frem til politikerne, så de stopper med at tale om "interoperabilitet imellem dokumentformater".

For at være retfærdig så synes jeg dog heller ikke at selve rapporten antyder at det er et sensationelt resultat at de er kommet frem til.

Men hvis en sådan rapport pludselig kan få nogle politikere og andre folk der har deltaget i debatten om OOXML/ODF igennem længere tid til at sige, "Hov har I hørt at det sidste nye er at de nu har fundet af at...." så er det da godt nok lidt chokerende. Men forklarer jo samtidigt også hvorfor så mange har fundet det fuldstændigt unaturligt at vi ikke kunne nøjes med ODF som standard.

Jesper,

Så, så, ikke bande...

Vil man kunne stille dig tilfreds med rigmandsunderstøttelse ?

Hvis man nu valgte et format, vil det så ikke betyde, at der indenfor en årrække, ikke vil være behov for konverteringer ?

På den måde slipper man også for overskrifter som:

"Microsoft i offensiven: ODF-specifikationen halter, ikke vores implementering "

For hvis den halter, så må man arbejde på at udbedre det brækkede ben, istedet for bare at pege fingre !

Det skal bemærkes der i Fraunhofers arbejdsgruppe deltog personer fra Microsoft (men ikke fra 'modparten'). Desuden er der i rapporten fra Fraunhofer en acknowledgement til Microsoft (og der er en debat gående på at MS har (med-)finansieret undersøgelsen.

For os (eksempelvis mig fra DTU) som deltog i DS' behandling af OOXML (med undtagelse af de personer som blev/bliver aflønnet af et Microsoft firma), er der ingen tvivl om at OOXML ikke er en reel åben standard, og at ODF er klart det bedste bud på en åben standard for dokumentformater. Dette bekræftes også af det forhold, at flere af vore nabolande netop har valgt ODF (og fravalgt OOXML), og af at en internetafstemning viste for nylig at mere end 80 pct ville foretrække ODF fremfor OOXML. Og jeg er helt enig i, at konvertering mellem to de to foreliggende dokumentstandarder altid vil give problemer. Som bl.a. den meget kyndige Robert Wier fra IBM har sagt det for nylig, så er dokumentformater ikke raket-videnskab. Når de alligevel volder problemer er det fordi, at 'nogen' vil at det skal være sådan. Kære politiker: Se nu at få valgt ODF. Det er klart det bedste valg - og det valg der sikrer, at mine oldebørn kan læse de dokumenter jeg skriver i dag.

Hej Kim,

Jesper,

Så, så, ikke bande...

:o)

Vil man kunne stille dig tilfreds med rigmandsunderstøttelse ?

Hvis man nu valgte et format, vil det så ikke betyde, at der indenfor en årrække, ikke vil være behov for konverteringer ?

Nej, for præmissen for dit udsagn er, at hvis blot man valgte ODF, så ville OOXML forsvinde. Det har jeg bare meget svært ved at forestille mig. "Gevinsten" ved ikke at vælge OOXML er nemlig, at alt det pres, vi har lagt på Microsoft for at overgive OOXML til ISO, deltage i standardiseringsarbejdet, at varsle udvidelser til dokumentformatet i deres programmer 10-15 måneder i forvejen for en ny version af deres kontorpakke (hvornår er det sidst sket?) ... det forsvinder nu som dug for solen.

OG hvis vi nu endeligt skulle vælge ét af de åbne dokumentformater - skulle vi så vælge det, der beviseligt giver problemer for 90% af brugerne, eller skulle vi vælge det, der beviseligt giver problemer for 10% af brugerne?

Og en sidebemærkning: Til Konkurrencestyrelsens pressebriefing for et par uger siden, understregede man (og det var vist her, Morten Kjærsgaard var faldet i søvn), at det ikke er ulovligt at have en dominerende markedsposition. Henrik Jensen havde nogle kommentarer om præcist den detalje, nemlig at I forsøger at straffe Microsoft - uden retssag - for at være "for store". Retssikkerhedsmæssigt synes jeg faktisk, at det er en krænkende holdning - det svarer til, at man i Folketinget besluttede, at fordi Arla var "for store", så forbød man dem at køre i deres lastbiler øst for Valby bakke.

Det dutter sgu ikke :o)

fnis

Det skal bemærkes der i Fraunhofers arbejdsgruppe deltog personer fra Microsoft (men ikke fra 'modparten'). Desuden er der i rapporten fra Fraunhofer en acknowledgement til Microsoft (og der er en debat gående på at MS har (med-)finansieret undersøgelsen.

Nu forstår jeg bedre, hvorfor det du skriver så sjældent giver mening ... det er fordi du får din viden fra Roy Schestowitz.

http://boycottnovell.com/2009/08/20/fraunhofer-report-on-ooxml/

Du bruger endda næsten de samme ord :o).

Det skal bemærkes der i Fraunhofers arbejdsgruppe deltog personer fra Microsoft (men ikke fra 'modparten'). Desuden er der i rapporten fra Fraunhofer en acknowledgement til Microsoft (og der er en debat gående på at MS har (med-)finansieret undersøgelsen.

Men nu er det jo en forholdsvis konkret rapport, med gode referencer til afsnit i standarderne m.v. så hvis man vil så kan man godt med lidt knofedt
selv efterprøve det hele. Og der er jo mange enkeltstående facts alá "ODF understøtter X men det gør OOXML ikke" og "OOXML understøtter Y men det gør ODF ikke" som man nemt selv kan verificere i standarderne. Altså hvis man ønsker at bruge en lille smule tid på det før man drager en konklusion.

For øvrigt nu siger du at modparten slet ikke deltog hvem definerer du som modparten?

Florian Reuter fra Novell (tidligere Sun) får da en acknowledgement på lige fod med Microsoft manden. Florian Reuter er mangeårig udvikler på OpenOffice.org med blandt andet ansvar for importfiltre til doc, wordml, odt (text-delen af ODF) og desuden medlem i ODF TC. For øvrigt er jeg stødt på hans navn i en rapport fra vores egen danske konkurrencestyrelse om interoperabilitet, så jeg tror han bliver brugt flittigt som ekspert på dette område.

ingen tvivl om at OOXML ikke er en reel åben standard,

Lige så lidt tvivl er der dog om at ingen har kunne fremlægge reelle beviser for det.

Ret utroligt i vores ellers oplyste samfund hvor stort set alt der er interessant det bliver lækket på internettet før eller siden, men den famøse liste over elementer i OOXML som kun Microsoft kan implementere / kun kan implementere på windows, den ser ud til at forblive en hemmelighed for altid.

Nu forstår jeg bedre, hvorfor det du skriver så sjældent giver mening ... det er fordi du får din viden fra Roy Schestowitz.

http://boycottnovell.com/2009/08/20...

Jeg synes faktisk det giver super god mening.

Domænet er jo boycottnovell.com, så det er jo egentligt ekstremt logisk at de nævner acknowledgment til Microsoft manden men frastår fra at nævne acknowledgement til Novell manden der er mangeårig OpenOffice.org udvikler og ODF TC medlem :-D

Hej Henrik,

Ret utroligt i vores ellers oplyste samfund hvor stort set alt der er interessant det bliver lækket på internettet før eller siden, men den famøse liste over elementer i OOXML som kun Microsoft kan implementere / kun kan implementere på windows, den ser ud til at forblive en hemmelighed for altid.

Ja, men heldigvis er det jo efterhånden sådan, at "listen" kun findes i hovederne på fire personer - nemlig Morten Kjærsgaard fra IBM, Henrik Madsen fra DTU, Roy Schestowitz fra - nåja, ham selv samt Pamela Jones fra Groklaw.net . Det synes jeg siger ret meget om "listen" ... og personsammenfaldet siger vist resten.

OG hvis vi nu endeligt skulle vælge ét af de åbne dokumentformater - skulle vi så vælge det, der beviseligt giver problemer for 90% af brugerne, eller skulle vi vælge det, der beviseligt giver problemer for 10% af brugerne?

Uden at tage stilling til om MS Office har en markedsandel på 90%, så vil jeg stille spørgsmålstegn ved at du regner med at denne dominerende position forsætter i al uendelighed.

De sidste år har jeg observeret at flere og flere hjemmebrugere dropper deres piratkopi af MS Office og skifter til OpenOffice. Ikke fordi OO er bedre, men fordi den er gratis og "god nok". Jeg ser ingen grund til at den udvikling ikke forsætter, uanset hvad det offentlige vælger af dokumentstandard.

Løsningen er ganske enkel: Det offentlig skal aldrig kommunikere med borgerne med OOXML eller ODF. De skal bruge PDF. Hvis der er tale om en formular der skal udfyldes, eller lignende, så skal der benyttes en webformular.

Internt i forvaltningen kan de bruge det format de lyster. Men udveksles der dokumenter mellem separate enheder bør man vælge ODF. Af den simple grund at der er flere produkter at vælge mellem, hvilket øger konkurrencen.

Man kan dårligt lave en licitation på levering af office programmel som skal have god understøttelse af OOXML, når der kun findes en leverandør der kan det. En licitation på ODF er der mange der kan byde på, inklusiv Microsoft.

Hej Baldur,

Uden at tage stilling til om MS Office har en markedsandel på 90%, så vil jeg stille spørgsmålstegn ved at du regner med at denne dominerende position forsætter i al uendelighed.

Det skulle den helst heller ikke ... og det er her jeg mener, at OOXML er et bedre redskab end ODF.

De sidste år har jeg observeret at flere og flere hjemmebrugere dropper deres piratkopi af MS Office og skifter til OpenOffice. Ikke fordi OO er bedre, men fordi den er gratis og "god nok". Jeg ser ingen grund til at den udvikling ikke forsætter, uanset hvad det offentlige vælger af dokumentstandard.

Ja - og sådan har jeg det også derhjemme. Vi har faktisk ikke et eneste Microsoft-program i huset. Men det ændrer ikke ved, at hvis en kontorpakke ikke er kompatibel med markedslederen, så er den ikke relevant. Derfor er der ingen tvivl om, at uanset om vi i Danmark vælger OOXML fra eller ej, så vil der blive fin OOXML-understøttelse i samtlige konkurrenter til Microsoft Office.

Nu forstår jeg bedre, hvorfor det du skriver så sjældent giver mening ... det er fordi du får din viden fra Roy Schestowitz.

http://boycottnovell.com/2009/08/20...

Nu læste jeg lige lidt mere indgående hvad Roy faktisk skriver og det er faktisk lidt et imponerende studie udi hvor "farligt" at internettet kan være når man søger information.

Han konkluderer jo at nu bruger Microsoft nogle af deres partnere (Fraunhofers i det her tilfælde med rapporten) til at rose/lovprise (Praise er hans valgte ord) og markedsføre OOXML.

Men hvis man læser rapporten så finder man en total mangel på nogen som helst form for lovprisning eller markedsføring af hverken OOXML eller ODF, ingen stillingtagen til om standarderne er gode eller dårlige eller mere eller mindre modne, ingen argumenter for om man bør vælge det ene eller det andet o.s.v.

Så der kan absolut ikke være nogen tvivl om at enten så har Roy læst rapporten men vælger bevidst at lyve, sikkert med den formodning at en stor del af læserne alligevel bare kommer forbi for at finde lidt hurtig snavs om Microsoft/Novell/OOXML og alligevel ikke læser rapporten, og ellers så har han simpelthen bare ikke læst rapporten men synes alligevel han burde konkludere på dens indhold.

Men uanset hvad så virker det sikkert og masser af folk labber det i sig og spreder rundt til andre debatfora på internettet indtil det til sidst står så mange steder at det jo med garanti må være sandhed.

Er det ikke lidt uinteressant at fremhæve områder hvor forskellige værktøjer ikke helt håndterer spidsfindige detaljer på samme måde?
Jeg mener selv om vi kun har en standard vil de forskellige værktøjsleverandører altid skulle lave noget, der differentierer dem fra konkurrenterne. Hvilket kræver at de implementerer noget funktionalitet, som ikke lige er understøttet af format-standarden - eller i det mindste ikke er understøttet ens i alle værktøjer.
Så når vi taler om standard for formater så er det for mig at se primært for at sikre langtidsholdbarheden af den viden, der ligger i vores dokumenter, og for at sikre at holdbarheden ikke er afhængig af en enkelt værktøjsleverandørs handlinger.
Så har jeg selvfølgelig opdaget at debatten har udviklet sig til, at det ville da være dejligt om man kunne få fuld interoperabilitet.
Ja og det ville også være dejligt hvis alle jordens mennesker havde lige så mange penge som Bill Gates, men det er desværre også lige så urealistisk.
Det er vel det den tyske undersøgelse slår fast - og som Jesper inleder med så er det yesterday's news.
Selvfølgelig er det det - for reelt er det jo bare god gammeldags sund fornuft.
Og hvis standardformatet skal vælges for at sikre holdbarheden - ja så mener jeg ODF er det bedste valg alene ud fra hvem der de facto står bag de to standarder der er tale om.

Og hvis standardformatet skal vælges for at sikre holdbarheden - ja så mener jeg ODF er det bedste valg alene ud fra hvem der de facto står bag de to standarder der er tale om.

Hvad så med alle de dokumenter der findes baseret på de lukkede binære office formater eller ECMA-OOXML, hvad med langtidsholdbaren af dem?

Da de ikke kan konverteres til ODF uden tab af indhold/formatering og brugerne ikke i alle tilfælde kan leve med dette så gør vi jo også binære office formater / ECMA-OOXML, ikke til langtidsholdbare, men så i hvert fald til noget som brugerne skal kunne benytte i rigtig mange år frem.

Med OOXML der er den fordel (og det er jo hele grundlaget for OOXML) at de brugere der har et behov for at bevare deres eksisterende dokumenter de har en ganske nem mulighed for at komme af med deres lukkede binære office formater ved at konvertere dem til OOXML.

Hvis/når OpenOffice.org, Symphony m.v. for alvor kommer til at understøtte OOXML, så vil disse brugere jo pludselig befinde sig i en situation hvor at de kan komme fra doc/xls/ppt -> OOXML -> alternativ til MS Office og derfor er med på "langtidsholdbarhed / frit valg" vognen

Henrik,

Jeg er ikke helt sikker på at du har ret i dine betragtninger om konverteringer til OOXML eller til ODF og hvad der er nemmest. Men du har da sikkert ret i, at hvis man har gemt sit dokument med et MS tool så er OOXML sikkert en nemmere vej fremad og da et stort flertal er i den situation i dag kan det kortsigtet være fristende og nemt at følge MS-linien.

Men det er så nøjagtig det, der skræmmer mig for upåagtet al snakken om åbenhed og standarder så tror jeg at det vil betyde at vores arkivalier populært sagt er pantsat til Microsoft.

Og det er den situationen jeg synes er uheldig for samfundet - og ups så kom jeg til det igen - så derfor har jeg den politiske overbevisning at et klart valg af ODF vil være bedre for vores fælles fremtid.

Jeg er ikke helt sikker på at du har ret i dine betragtninger om konverteringer til OOXML eller til ODF og hvad der er nemmest.

Forklar mig venligst hvordan du kommer frem til det?

Vi har en ODF standard som aldrig nogen sinde har været påtænkt skulle være bagudkompatibel med disse gamle dokumenter og så har vi en OOXML standard hvor et af de væsentligste formål har været at være bagudkompatibel med disse gamle dokumenter.

Vi har en MS Office 2007 som i dag gemmer i et ECMA-OOXML format. Man kan åbne et doc/xls/ppt dokument med MS Office og gemme det ned i ECMA-OOXML med meget høj fidelity.

Så man kan altså konvertere fra doc/xls/ppt til ECMA-OOXML. ISO OOXML Transitional er næsten identisk med denne ECMA-OOXML dvs. man kan altså også konvertere fra ECMA-OOXML (og derved fra doc/xls/ppt) til ISO OOXML Transitional ganske let.

Og prøv også at føre tanken en gang videre. Hvis det virkelig var så ganske let at komme fra de gamle binære office formater + ECMA OOXML til ODF, så er IBM, Sun (Oracle) m.fl. da, undskyld udtrykket, rent forretningsmæssigt nogle komplet idioter, når de ikke har lavet et brugbart (dvs. forholdsvis høj grad af fidelity) konverteringsværktøj.

Med et sådan konverteringsværktøj i hånden kunne de for det første langt nemmere overbevise alle om at OOXML er unødvendigt (de ville jo kunne bevise at ODF er lige så eller endda mere bagudkompatibelt med eksisterende dokumenter end OOXML) og for det andet så havde de et gudeværktøj i hånden når de skulle ud at sælge OpenOffice.org (StarOffice) / Symphony til eksisterende MS Office kunder.

Hej Jan,

upåagtet al snakken om åbenhed og standarder så tror jeg at det vil betyde at vores arkivalier populært sagt er pantsat til Microsoft.

Du virker jo som en meget fornuftig mand, så kan du ikke prøve at forklare mig, at når nu

... OOXML (i alle afskygninger) er overgivet til standardiseringsorganisationer

... og OOXML vedligeholdes ikke bare "i" men "af" ISO i et åbent forum via en åben proces, hvor alle har mulighed for at deltage

... og OOXML vedligeholdes i et forum, hvor Microsoft ikke har stemmeret og formel indflydelse

... og der ikke er bindinger til MS-specifikke teknologier/platforme (nej, Christian, heller ikke til SharePoint)

... og OOXML er underlagt samme patent-klausuler som ODF

... og der er INTET, der forhindrer Microsofts konkurrenter i at implementere OOXML - som i øvrigt Lotus Symphony, OpenOffice.org, NeoOffice, iWorks, WordPerfect allerede har gjort det

... hvordan kan du så konkludere, at vores arkivalier er "pantsat til Microsoft"?

Hej Baldur,

udveksles der dokumenter mellem separate enheder bør man vælge ODF. Af den simple grund at der er flere produkter at vælge mellem, hvilket øger konkurrencen.

Man kan dårligt lave en licitation på levering af office programmel som skal have god understøttelse af OOXML, når der kun findes en leverandør der kan det. En licitation på ODF er der mange der kan byde på, inklusiv Microsoft.

Det er jo faktisk præcist den (del)konklusion Konkurrencestyrelsen kom frem til.

Det er rart at se, at jeg ikke er den eneste, der er enige med Konkurrencestyrelsen og deres rapport.

:o)

Hej Jesper

jeg tillod mig lige at holde weekend, men jeg vil da gerne svare.

Faktuelt set har du ret - OOXML er åbent og alle kan da bare lave løsninger til det. Der er ingen begrænsninger - altså lige bortset fra de forretningsmæssige beslutninger.

Kan man tjene penge på at lave det eller må man forudse, at man kommer til at kæmpe kampen på Microsofts hjemmebane og derfor står med ryggen mod muren?

Jeg tror (og indrømmet det er et spørgsmål om tro) at på sigt så vil mange leverandører tabe lysten til at være med på dette marked og dermed fortsætter Microsoft deres nuværende monopol og min frygt vil vise sig at være begrundet.

At leverandørerne har disse overvejelser finder jeg veldokumenteret af hele formatdebatten. Jeg mener de fleste har jo kæmpet hårdt mod OOXML og hvis det var så nemt som du påstår var der vel ingen grund tl at tage de kampe, vel?

Men lad os tales ved om 10 år.

Hej Henrik

Jeg arbejde i en periode med OpenOffice og havde absolut ingen problemer med at åbne gamle Microsoft dokumenter, så den bagud kompatibilitet du efterlyser findes faktisk i disse tools.

Jeg kom fra en arbejdsgiver, hvor alt var Microsoft og jeg blev forbløffet over hvor nemt det var at skifte og hvor gnidningsløst jeg kunne kommunikere med partnere i andre organisationer - bortset fra en lille sjov detalje.

Jeg kunne åbne alt hvad jeg modtog - men jeg måtte gang på gang konstatere at mine partnere med MS platforme ikke kunne åbne mine ODF dokumenter, hvorfor jeg lærte mig selv at vælge MS formater når jeg skulle kommunikere mine dokumenter ud af "miljøet". Hvilket absolut ikke gav mig problemer. Derfor blev jeg OpenOffice og ODF fan.

Og så selvfølgelig fordi jeg aldrig har været begejstret for Microsoft og deres monopol.

Hej Jan,

jeg tillod mig lige at holde weekend, men jeg vil da gerne svare.

No problem :o)

Faktuelt set har du ret - OOXML er åbent og alle kan da bare lave løsninger til det. Der er ingen begrænsninger - altså lige bortset fra de forretningsmæssige beslutninger.

Godt - jeg er glad for, at vi fik sat det på plads. Nu kan man jo blot håbe, at OSL, ORACLE og Sun/IBM-partnere som DTU lytter med.

:o)

Kan man tjene penge på at lave det eller må man forudse, at man kommer til at kæmpe kampen på Microsofts hjemmebane og derfor står med ryggen mod muren?

Ja, vel begge dele. Hele idéen er jo, at man netop har mulighed for at kæmpe på Microsofts hjemmebane, hvis man implementerer OOXML. For ved implementering af OOXML får man nemlig fuld kompatibilitet med Microsoft Office - noget du ikke får med hverken .DOC eller .ODF.

... og vupti - pludseligt er det absolut bedste argument for ikke at skifte fra Microsoft Office væk som dug fra solen. For Microsoft har jo ret - hvis man skifter fra Microsoft Office til "noget andet", så vil man med "Toyota-sikkerhed" (112%) komme til at miste data og information. Men hvis din kontorpakke understøtter OOXML, så kan du give Microsoft fingeren og sige, at det er noget fis - for ved valg af "kontorpakke XYZ" mistes intet - fordi der er understøttelse for OOXML.

[u]Derfor[/u] er OOXML bedre som værktøj til "Microsofts undergang" end ODF. Det er ikke fordi ODF er et dårligt dokumentformat - det er blot uanvendeligt til en gradvis migration af dokumenter fra Microsoft Office.

Jeg tror (og indrømmet det er et spørgsmål om tro) at på sigt så vil mange leverandører tabe lysten til at være med på dette marked og dermed fortsætter Microsoft deres nuværende monopol og min frygt vil vise sig at være begrundet.

Jeg tror ikke, at du skal være nervøs. Alle større kontorpakker vil snart få ganske glimrende OOXML-understøttelse. Allerede nu har Apple, IBM, Google og Sun/ORACLE implementeret OOXML i deres pakker/services, og den understøttelse vil naturligvis løbende blive bedre.

Der er INGEN, der kan overleve på markedet, hvis de ikke er kompatible med den kontorpakke, der er installeret på flere PC'ere end alle konkurrenterne tilsammen.

Jeg arbejde i en periode med OpenOffice og havde absolut ingen problemer med at åbne gamle Microsoft dokumenter, så den bagud kompatibilitet du efterlyser findes faktisk i disse tools.

Jeg gætter på at der har været tale om ret standard tekst så.

Som jeg skrev i anden debat her på siden for et par dage siden så det jeg har oplevet i forbindelse med udveksling af doc dokumenter mellem MS Office 2007 PS2 og OpenOffice.org 3.1 det er følgende problemer og det er altså bare ved ret simpel aftestning i en times tid:

Fyldfarve i enkelte celler på tabeller der forsvinder, fodnoter der forsvinder, rettelsesmarkeringer der ikke korrekt angiver hvad der er rettet (specielt på rettelser omkring tabeller jeg har oplevet dette), sletning af billeder under rettelsesmarkering som ikke efterfølgende kunne afvises, indrykninger af tekst der forskydes, bullets/numbering som ikke gengives korrekt specielt efter at der har været foretaget rettelser i dem og tekst omkring billeder som wrapper anderledes rundt om billedet afhængig af kontorpakken

Ja og så er der selvfølgelig formatering m.v. som direkte ikke er understøttet i den ene eller den anden kontorpakke og derfor af mere indlysende årsager forsvinder når man udveksler den ene eller den anden vej. Det er det som beskrives i rapportens afsnit 5 dog selvfølgelig med udgangspunkt i OOXML/ODF og ikke i de pågældende kontorpakker.

Så det er altså absolut ikke det mindste brugbart når man benytter lidt mere avancerede formateringer og funktionalitet.

Hej Henrik

Det lyder ikke til at doc er brugbart som udvekslingsformat på tværs af platforme længere (2007 udgaven af doc!).
docx virker heller ikke i praksis på andet end MS Office.
Så er der jo reelt kun et format tilbage: ODF.
Prøv at installere SUN ODF Plugin på din MS Office, og sendt et par "avancerede" ODF dokumenter fra OpenOffice til Word. Jeg tror du bliver overrasket over resultatet. Jeg har endnu ikke oplevet at de indholdselementer du nævner er gået tabt/ændret.
ODF er absolut brugbart og modent som udvekslingsformat - og har altså nu overgået doc. (som egentlig var OK til og med 2003-versionen)

Hej Jens Christian,

Prøv at installere SUN ODF Plugin på din MS Office, og sendt et par "avancerede" ODF dokumenter fra OpenOffice til Word. Jeg tror du bliver overrasket over resultatet.

Svedigt - så Sun ODF Plugin kan trylle og få de inkompatible dele imellem ODF og OOXML til at være i ODF alligevel?

Indrømmet - efter at have testet et hav af convertere/filtre/plugins kunne det ligne trylleri når der endelig er noget der virker. Et af de steder hvor der også i helt "enkle" dokumenter er inkompatibiliteter, er i programmernes måder at lave forskellige sideopsætninger på indenfor samme dokument (eksempelvis at side 5 skal være i liggende format og uden sidehoved). OpenOffice bruger sidetypografier men den funktion findes (endnu) ikke i Microsoft Office - så den oversættes til sektionsinddelinger i stedet. Herved bevares indhold og layout. (og så er de fleste brugere tilfredse;-)
Keine hexerei...Men måske lidt snyd?

Keine hexerei...Men måske lidt snyd?

Du har fuldstændig ret, intet der tyder på magi der, men blot nogle udviklere som har skrevet noget kode og derfor har været underlagt de forskelle der nu engang er.

Med en MS Office 2007 SP1 (ville ikke installere SP2 for at være 100% sikker på at Microsofts egen ODF implementeringen ikke spillede ind) oprettede jeg et dokument hvor jeg

1) Indsatte tabel med et mønster i en celle

2) Indsatte noget tekst og definerede nogle borders herunder inline borders for denne tekst

Bare for at vælge to former for formatering som er understøttet i Microsoft Office/OOXML/DOC men ikke i ODF.

Og rigtig nok da jeg gemte i ODF via brug af SUN ODF Plugin 3.1 og derefter åbnede i OpenOffice.org 3.1 så var mit mønster i cellen blevet til en baggrundsfarve i stedet og mine borders rundt om teksten blev ikke gengivet korrekt. Flere var simpelthen bare væk. Så ingen magi der.

Så testede jeg om magien virker den anden vej.

Oprettede et dokument i OpenOffice.org 3.1 og indsatte

1) Tekst som var overstreget

2) Tekst som blinkede

Bare for at vælge to former for formatering som er understøttet i OpenOffice.org/ODF men ikke i MS Office/OOXML/doc.

Og rigtig nok da jeg gemte i ODF og åbnede i MS Office via brug af SUN ODF Plugin 3.1 så var overstregningen over teksten forsvundet og den blinkende tekst var blev til blinkende baggrund i stedet. Så heller ingen magi der.

Så fuldstændigt som forventet så kan SUN ODF Plugin selvfølgelig ikke trylle. Men når SUN ikke kunne trylle så kunne man dog have håbet på at de

1) Sammen med download af plugin eller som link på plugin download siden vedlage et dokument som beskrev alle de ting som ikke er kompatible og hvor formatering derfor forsvinder eller bliver ændret. Men det har jeg ikke kunne finde.

2) Når man gemmer via plugin så fortælle at formateringer X, Y, Z kan vi ikke gemme fordi at det ikke er understøttet i ODF

3) Når man åbner via plugin så fortæller at formatering X, Y, Z kan vi ikke præsenteres korrekt da det ikke er understøttet af Microsoft Office.

Når ovenstående mangler så opnår man lige præcis den effekt at for det første render der mange rundt og tror at det er umuligt at der kan forsvinde + blive ændret i formatering m.v. på trods af at det ikke er tilfældet. For det andet hvis jeg sad hos en kunde der gerne ville migrere fra MS Office til OpenOffice.org så bliver jeg selv nødt til at sidde og finde ud af præcis hvilke problemer vi kan løbe ind i ved at sidde og teste om det virker eller ej.

Derudover testede jeg lige hurtigt lidt på track changes for det er noget jeg benytter meget ofte (vi snakker flere gange om ugen) i forbindelse med udveksling af dokumenter med kunder, samarbejdspartnere og andre kontakter.

Hvor meget der skyldes manglende understøttelse i enten OpenOffice.org/ODF og MS Office/OOXML/doc og hvor meget der bare skyldes fejl i plugin ved jeg ikke det har jeg ikke gidet at sidde og slå op i standarderne samtidigt.

Men først prøvede jeg at oprette et dokument i word som havde følgende

1) En tekstlinie formateret med fed

2) Et billede

3) En tabel med 4 rækker og 3 kolonner. I række 1, kolonne 1 var der indsat noget tekst og på denne tekst indsat en fodnote. 2. række i tabellen var markeret med grå baggrund

4 En liste med standardnummerering af elementerne i listen. Der var en 4-5 elementer i listen

Jeg gemte det så via plugin i ODF og åbnede det i OpenOffice.org 3.1

Her fjernede jeg 'fed' markering på teksten og slettede billedet samtidigt så slettede jeg den 2. række i tabellen og markerede den 3. række med grå baggrund i stedet, samtidigt slettede jeg fodnote fra teksten i 1. række. Derefter indsatte jeg et nyt element i listen og slettede et eksisterende ved blot at markere teksten og slette.

Så gemte jeg tilbage i ODF og så over i Microsoft Word og åbne via SUN ODF Plugin 3.1

Resultatet var at

1) 'Fed' formateringen var forsvundet men der var ikke registeret nogen rettelse så jeg kunne ikke afvise/godkende

2) Billedet var forsvundet men der var ikke registeret nogen rettelse så jeg kunne ikke afvise/godkende

3) Række 2 i tabellen var forsvundet men der var ikke registeret nogen rettelse så jeg kunne ikke afvise/godkende

4) Række 3 var ikke markeret med grå baggrund som jeg ellers have gjort i OpenOffice.org

5) Sletning af fodnote blev vist korrekt med rettelsesmarkering og jeg kunne godkende/afvise korrekt

6) Det indsatte element i listen blev vist korrekt med rettelsesmarkering og jeg kunne godkende/afvise korrekt

7) Det slettede element i listen blev også umiddelbart vist korrekt med rettelsesmarkering men når jeg godkendte så blev kun teksten slettet men min nummerering og altså selve listepunktet blev stående blot med tom tekst. For at se om det var min egen skyld prøvede jeg at gennemkøre denne test en gang til men denne gang slettede jeg både tekst + nummerering af elementet i OpenOffice.org. Men så blev resultatet bare at hvis jeg så afviste rettelsen så kom kun teksten tilbage mens min nummerering var væk.

Så lavede jeg bare samme test men vendte den om. Altså startede i OpenOffice.org og så foretog de samme ændringer i MS Office Word.

Resultatet her var endnu mere besynderligt

Da jeg åbnede op via Plugin i MS Office Word for at foretage rettelser kunne jeg ikke slette det billede var indsat fra OpenOffice.org. Hverken ved at trykke delete eller ved at højre klikke på billedet og trykke cut.

Når Track Changes var slået fra så kunne jeg godt slette billedet. Jeg kunne også oprette en ny kopi af billedet eller indsætte et helt nyt som jeg godt kunne slette mens at track changes var slået til. Men når track changes var slået til fandt jeg ingen måde hvorpå jeg kunne få fjernet det oprindelige billede fra OpenOffice.org 3.1

Så sletning af billedet måtte jeg altså opgive at teste den vej.

Desuden var min række 2 i tabellen heller ikke markeret med grå baggrund så det med at sætte en baggrundsfarve på nogle celler i en tabel virker altså generelt kun den ene vej og ikke den anden.

Tilbage i OpenOffice.org for at kontrollere de rettelser jeg kunne lave blev jeg så mødt af følgende resultat

1) 'Fed' formateringen var forsvundet men der var ikke registeret nogen rettelse så jeg kunne ikke afvise/godkende

2) Række 2 i tabellen som jeg havde slettet i word og hvor at hele række var markeret med slettemarkering i Word var nu i OpenOffice.org i stedet blevet til at indholdet i rækken stod to gange den ene gang blot slettemarkeret. Så hvis jeg godkendte så var resultatet at række 2 blev stående i stedet for at blive slettet og hvis jeg afviste var resultatet blot at nu stod tekstindholdet i min række dobbelt. Så hverken afvise eller godkende gav mig det resultat jeg ville opnå eller bragte mig tilbage til udgangspositionen.

3) Række 3 var markeret med grå baggrund men der var ikke mulighed for at afvise/godkende

4) Sletning af fodnote blev vist korrekt med rettelsesmarkering og jeg kunne godkende/afvise korrekt

5) Indsættelse af element i liste blev vist korrekt med rettelsesmarking men hvis jeg afviste så blev nummereringen stadig stående og kun teksten forsvandt

6) Slettelse af element i liste blev ikke vist korrekt. Nummereringen var allerede væk og kun selve teksten stod på rettelsesmarkering så hvis jeg afviste havde jeg kun teksten stående men ikke den oprindelige nummerering

Det er bestemt ikke imponerende og jeg vil faktisk ikke engang mene at det er så særlig avanceret det jeg har gjort. Jeg har benyttet tekst, billeder, tabeller, lister og fodnoter og har i høj grad blot valgt standardindstillingerne for listenummerering, billeder, fodnoter m.v. Jeg tvivler derfor meget på at der er nogen som helst som arbejder ofte med udveksling af dokumenter via brug af SUN ODF Plugin hvor de benytter track changes.

Jeg havde også en anden lille sjov episode da jeg allerførst valgte at teste med en Microsoft Office 2003 med SUN ODF Plugin.

Her oprettede jeg et ODF dokument i OpenOffice.org som blot indeholdt et billede og gemte i ODF og åbnede i MS word 2003.

Her blev billedet simpelthen ikke vist. Så indsatte jeg et nyt billede i selve word og det blev vist korrekt. Så gik jeg ind på det nye billede og ændrede lidt på tekstwrapping indstilling og pludselig kom det oprindelig billede fra OpenOffice.org til syne og skjulte det nye billede jeg havde indsat i Word.

Men det samme skete altså ikke med MS Word 2007 SP1 så SUN ODF Plugin virker åbenbart også lidt forskelligt afhængigt af MS Office versionen på selv noget så simpelt som billeder.

Hej Henrik

Nu skrev jeg også at "de fleste brugere" er tilfredse, og jeg tror ikke du hører til i den kategori.
F.eks. at indsætte et mønster i en tabelcelle ikke en særlig typisk handling (det gør det svært at læse celleindholdet!)
Men selvfølgelig burde det oversættes korrekt. Og jeg skriver "burde" for den slags skønhedsfejl har vi jo lært at leve med gennem mange år med forskellige doc versioner. hvor vi også har oplevet mange små smuttere af den art. Og endda selv om to personer bruger samme version af MS Office 2003 og sender doc filer til hinanden, kan man komme ud for at udseendet ændrer sig og sidelayoutet skrider - fordi de to personer har forskellige printere og forskellige skrifttyper installeret. Sådan har det altid været, og hvis man forventer at et nyt format fra starten kan rette op på det, bliver man skuffet.
Men jeg er enig i at også småtingene skal være på plads, og at korrekturværktøjerne skal virke på tværs. Men vi er nået langt hvis et almindeligt brev kan vises korrekt i en "fremmed" kontorpakke. Det har vi ventet længe på.
Jeg bruger en stribe forskellige ODF testdokumenter fra det virkelige liv og de klarer oversættelsen forbavsende godt. Og dokumenter fra det virkelige liv indeholder heldigvis sjældent mønstre i tabelceller og blinkende tekst. ;-)

Nu skrev jeg også at "de fleste brugere" er tilfredse, og jeg tror ikke du hører til i den kategori.

Kender du nogle virksomheder som har benyttet SUN ODF Plugin til at batch konvertere alle deres MS Office dokumenter til ODF for derefter at kunne droppe brug af MS Office? Altså har kunne bruge ODF til at slippe af med deres afhængighed til MS Office?

Har du kunne finde en liste over de formateringer m.v. som ikke virker korrekt med SUN ODF Plugin?

Hvis nej, hvordan benytter "de fleste brugere" så plugin'et? Blot benytter det og så tror/håber at der ikke er noget formatering der forsvinder/ændrer sig, eller benytter de plugin for derefter hver gang at bruge tid på at kontrollere i andre kontorpakker om det ser rigtigt ud før de sender det til kunder, samarbejdspartnere m.v.?

F.eks. at indsætte et mønster i en tabelcelle ikke en særlig typisk handling (det gør det svært at læse celleindholdet!)

Det er korrekt, men hvem har styr på hvor stor en procentdel af de forskellige features der benyttes?

Nu var mønstre i tabelceller og textborders i MS Office/OOXML/DOC og overstreget samt blinkende tekst i OpenOffice.org/ODF blot et par eksempler i tekstdelen (Wordproccesing) på hvor der er forskelle i kontorpakker/formater som ikke kan løses ved at konvertere fra et format til et andet.

Man kan selv læse den omtalte rapports afsnit 5 og finde en hel del flere eksempler. Og man skal desuden være opmærksom på at rapporten beskæftiger sig kun med forskelle mellem OOXML Strict og ODF. OOXML Transitional som indeholder alle bagudkompatibilitets indstillinger m.v. er der slet ikke taget stilling til i rapporten og der er ingen tvivl om at det er her der for alvor er en masse indstillinger i OOXML som ikke kan gengives korrekt i OpenOffice.org/ODF

Så vi snakker altså hverken om at der kun 5, 10 eller 20 forskellige ting der ikke virker på tværs af kontorpakkerne/formaterne. Tallet er langt langt højere.

skønhedsfejl

Om det er skønhedsfejl eller ej afhænger jo helt af hvordan at man har brugt formateringerne. Generelt mener jeg jo at man overordnet kan bruge formateringer på tre forskellige måder.

Man kan lege med det, som min kæreste godt kunne finde på i et svagt øjeblik, altså f.eks. sætte blinkende tekst i ODF, eller mønstre i tabelceller i OOXML m.v. bare fordi at det er sjovt at sende til veninderne. Det jeg vil kalde formatering til tihi fnis brug. Her overlever alle at der forsvinder formatering m.v. så finder de bare noget andet "lege" med.

Så kan man benytte formateringer for at få det til at se lidt godt ud / fremme læsevenligheden / fremhæve forskellige ting m.v. Her overlever alle normalt også at der forsvinder formatering m.v. men det er bestemt ikke hensigtsmæssigt. Hvis jeg f.eks. har givet mine overskrifter i en tabel i OpenOffice.org Writer en grålig baggrund for at fremhæve at der er tale om en overskrift og derved øge læsevenligheden af mit dokument, så når jeg sender mit dokument afsted i ODF og min kunde åbner det i Word via plugin og denne grålige baggrund forsvinder så har mit dokument altså mistet en smule af dets læsevenlighed. Prøv også at forestille dig at det er udvekslinger mellem en elev og en lærer af opgavedokumenter som der skal gives karakter for. Det at der pludselig forsvinder formatering m.v. kan gøre at elementer som eleven har ønsket at fremhæve (via brug af formatering) pludselig forsvinder eller at læsevenligheden blot forringes. Der er tale om skønhedsfejl, men det kan altså være skønhedsfejl der reelt kan være det som er afgørende for om karakteren ryger et tak op eller ned hvis læreren sidder og er lige på vippen til at give den ene eller den anden karakter.

Og så er der hvor at formateringer så at sige bliver en del af indholdet. Lad os f.eks. sige at jeg markerer nogle linjer i en tabel med en grå baggrund og under tabellen skriver "Linjer markeret med en grå baggrund er de udeståender som XYZ har ansvar for at udføre inden uge 42". SUN ODF Plugin smider så min baggrundsfarve i tabellen væk når jeg indlæser ODF i Word, eller erstatter et mønster med en baggrundsfarve når jeg gemmer fra Word i ODF og indlæser i OpenOffice.org. Nu er der pludselig ikke kun tale om skønhedsfejl mere, nu er der tale om at SUN ODF Plugin reelt ændret indholdet i mit dokument, fordi at dokumentet nu kan opfattes fuldstændigt forskelligt med hensyn til hvem der har ansvar for givne udeståender.

Og igen nu har vi jo primært snakket om tekstdokumenter. Når vi f.eks. snakker regneark så giver det sig selv at når inkompatibilitet betyder at udregninger ændrer sig når dokumenterne udveksles, så er der selvfølgelig heller ikke blot tale om skønhedsfejl mere.

Og dokumenter fra det virkelige liv indeholder heldigvis sjældent mønstre i tabelceller og blinkende tekst. ;-)

Kan du på samme måde gennemgå samtlige af de andre forskelle der er imellem OOXML og ODF og præcist angive hvor stor en procentdel af de mange hundrede millioner kontorpakke brugere verden over der benytter det ene og det andet så har du en rapport i hånden der virkelig kan gavne når politikerne skal tage stilling.

Kender du nogle virksomheder som har benyttet SUN ODF Plugin til at batch konvertere alle deres MS Office dokumenter til ODF for derefter at kunne droppe brug af MS Office?

Jeg kender ingen som ville batchkonvertere alle deres dokumenter, uanset hvilke formater det drejede sig om. Og hvis jeg kendte nogen, ville jeg fraråde dem det. Det vil altid være risikabelt.
Jeg kender til gengæld mange som har skiftet kontorpakke og dermed dokumentformat. Herefter konverteres typisk efter behov. I vores tilfælde har vi de gamle doc filer liggende, og hvis der er behov for det åbnes de fint i OpenOffice. Hvis det er "aktive" dokumenter der fortsat skal redigeres, gemmer vi som ODF.

Lad os f.eks. sige at jeg markerer nogle linjer i en tabel med en grå baggrund og under tabellen skriver "Linjer markeret med en grå baggrund er de udeståender som XYZ har ansvar for at udføre inden uge 42". SUN ODF Plugin smider så min baggrundsfarve i tabellen væk når jeg indlæser ODF i Word

Jeg tillod mig at efterprøve dit udsagn. Fremhævede nogle linjer tekst i OpenOffice 3.01 med gråt. Åbnede dokumentet i Word 2003 med SUN ODF Plugin 3.0: Den grå markering er der stadig, og alt ser ud som det skal. Jeg har dog før oplevet at Word i kombination med visse lcd-skærme/grafikkort kan gøre lyse gråtoner og tynde streger usynlige. Måske kan det have spillet ind?

Ud fra min erfaring er ODF interoperabiliteten efterhånden på et niveau hvor det er "brugbart" Men der er selvfølgelig plads til forbedringer.

Hvis du og dine kunder ikke kan leve med kvaliteten, er der vel ikke anden løsning end at hver bruger skal have to (eller tre eller fire...) kontorpakker installeret?

Jeg kender til gengæld mange som har skiftet kontorpakke og dermed dokumentformat. Herefter konverteres typisk efter behov. I vores tilfælde har vi de gamle doc filer liggende, og hvis der er behov for det åbnes de fint i OpenOffice. Hvis det er "aktive" dokumenter der fortsat skal redigeres, gemmer vi som ODF.

Og hvordan kontrollerer I om noget er mistet efter at doc er åbnet i OpenOffice eller er konverteret til ODF? Eller er indholdet/formateringen ikke af større betydning end at det er ligegyldigt om der mistes lidt hist og her?

Jeg tillod mig at efterprøve dit udsagn. Fremhævede nogle linjer tekst i OpenOffice 3.01 med gråt. Åbnede dokumentet i Word 2003 med SUN ODF Plugin 3.0: Den grå markering er der stadig, og alt ser ud som det skal.

Det er fyldfarve (skygge) i en celle på en tabel

Og hvordan kontrollerer I om noget er mistet efter at doc er åbnet i OpenOffice eller er konverteret til ODF? Eller er indholdet/formateringen ikke af større betydning end at det er ligegyldigt om der mistes lidt hist og her?

Vi kan naturligvis ikke acceptere tab af indhold, og vi har ikke eksempler på det fra nyere tid. Det er også yderst sjældent at vi oplever forskelle i formatering - og så er det som regel småting uden betydning.
Indtil i juni i år havde vi OpenOffice sat op til at gemme i doc-format som standard. Det ville vi aldrig gøre hvis der var den mindste risiko for datatab.
(Nu gemmes der i ODF som standard)

Det er fyldfarve (skygge) i en celle på en tabel

Samme her - og uden problemer!

vi har ikke eksempler på det fra nyere tid

Men hvordan kontrollerer i det? Manuel verifikation i hvert enkelte tilfælde ved at sidde og sammenligne med dokumentet åbent i begge kontorpakker, eller har I en eller anden form for værktøj som validerer et doc dokument og gør opmærksom på hvis det indeholder elementer som der er/kan være problemer med og brugeren derfor skal være ekstra opmærksom?

Samme her - og uden problemer!

Så er det åbenbart kun specifikt fra OpenOffice.org 3.1 -> ODF -> SUN ODF Plugin 3.1 -> MS Word 2007 SP1 / MS Word 2003 (Husker ikke servicepakken) at det er et problem.

For at være helt sikker på at det ikke var en lysegrå farve som forsvandt grundet grafikkort, skærm m.v. som du foreslår har jeg lige prøvet med en rød baggrund. Og lige så rød som den var i OpenOffice.org lige så hvid (no color) er den i MS Word når den har været en tur igennem SUN ODF Plugin 3.1

Men hvordan kontrollerer i det?

Brugerne ville ret hurtigt opdage hvis der manglede ting i deres dokumenter. Men vi laver ikke længere en direkte kontrol eller sammenligning. Det gjorde vi til at starte med, men hvis tingene virker, holder man op med at kontrollere på et tidspunkt. Vi har anvendt OpenOffice i så mange år efterhånden at der er tilstrækkelig tillid til det.
Hvis du åbner et doc fra Word 97 i din Word 2007 sidder du heller ikke og kontrollerer med begge programmer åbne - selv om der er potentiel fare for tab af data eller formatering.

Så er det åbenbart kun specifikt fra OpenOffice.org 3.1 -> ODF -> SUN ODF Plugin 3.1 -> MS Word 2007 SP1 / MS Word 2003 (Husker ikke servicepakken) at det er et problem.

Så kan vi konkludere at ODF standarden giver mulighed for interoperabilitet, men at der er convertere/kontorpakker som ikke er tilstrækkeligt modne endnu.

Hej Jens Christian,

Så kan vi konkludere at ODF standarden giver mulighed for interoperabilitet, men at der er convertere/kontorpakker som ikke er tilstrækkeligt modne endnu.

Jeg tror, at nøgleordet her er "mulighed".

:o)

Brugerne ville ret hurtigt opdage hvis der manglede ting i deres dokumenter.

Så er det nok bare mig der er blevet for gammel og glemsom. Hvis jeg fandt et par år gammelt 50 siders dokument frem fra arkivet så ville jeg da ikke kunne huske alle detaljerne i dokumentet og derfor nemt kunne verificere om det var blevet ændret blot ved at kigge på det "konverterede" dokument.

Samtidigt hvis din kunde nu modtager et doc dokument fra en anden organisation som benytter MS Office, hvordan kan din kunde så opdage at der mangler ting i det dokument som de aldrig har set før i den originale form?

Derfor at jeg spørger meget interesseret efter noget værktøjsunderstøttelse.

Så kan vi konkludere at ODF standarden giver mulighed for interoperabilitet

Ja hvis man bare ikke bruger den lange række af funktionalitet/formateringer m.v. i MS Office/OOXML/binære office dokumenter som ikke understøttes i ODF og hvis man ikke i ODF benytter de funktionaliteter/formateringer m.v. som ikke understøttes af MS Office/OOXML/binære office dokumenter, men altså kun benytter fællesmængden, det giver sig selv.

Hvis man blot husker kun at benytte fællesmængden i det enkelte tilfælde så er der jo også fuldt interoperabilitet mellem ODF og text/rtf/html m.v.

Problemet er bare for det første at det ikke er til at opdrive en komplet beskrivelse af hvad der er komplementær og hvad der er fællesmængde mellem OOXML og ODF og værktøjerne (f.eks. SUN ODF Plugin) hjælper heller ikke med at gøre opmærksom på hvad der ikke kan håndteres. Der bliver foretaget nogle forskelliges tests og udarbejdet nogle rapporter ligesom denne her fra Fraunhofer som giver en del af billedet, og det er så det man har at arbejde ud fra.

Næste problem sådan mere på politisk beslutningsniveau er at der ikke er nogen der har et overblik over hvor mange af de milliarder af eksisterende binære ms office formater/OOXML dokumenter der findes som kun benytter noget der ligger inden for fællesmængden og hvor mange der også benytter noget fra MS Office/OOXML komplementærmængden.

Hele dialogen mellem Henrik og Jens Christian er for mig et bevis på, at man skal være meget bevidst om forskellen mellem indhold og formatering i et dokument.

Måske er det fordi jeg er en gammel mand, som startede med at arbejde før PCen og farve-laserprinteren var opfundet, at jeg ved at man kan klare ufattelig meget forretning med sort-hvid tekst.

Så kom moderne teknologi med ufattelige og omfattende muligheder for at lave formateringer og desværre er der nogen mennesker som føler det som en pligt at anvende så meget blip-båt som muligt og dermed kommer til at fokusere mere på format (præsentation) end selve indholdet.

Måske burde man med lov vedtage at et standardformat ikke må understøtte alt dette blip-båt, så man ad den vej kan få folk til at tænke på indholdet?

Set ud fra en overordnet betragtning om at IT er tænkt som en værktøj til administrativ forenkling var det måske slet ikke nogen dårlig ide :)

Hej Jan,

Måske burde man med lov vedtage at et standardformat ikke må understøtte alt dette blip-båt, så man ad den vej kan få folk til at tænke på indholdet?

Desværre er det nok lidt en tabt kamp.

I efteråret 2007 deltog CIBER sammen med Microsoft, IBM og en række andre i et teknisk udredelsesarbejde for ITST, hvor vi gennemtrevlede de dokumenter, der var blevet dannet i ITST's pilotprojekter om anvendelse af to dokumentformater. Allerede dengang var vores konklusion, at ikke alene var der ting, der ikke kunne konverteres [0], men brugerne havde også en tendens til at lave dokumenterne mere komplekse end nødvendigt. Et fiktivt eksempel på dette kunne være i stedet for at sammenflette to tabelceller, så lavede man en konstruktion med x antal indlejrede tabeller, så det visuelle resultat blev det samme.

[0] Det behøver altså ikke at være specielt avancerede ting, der ikke kan konverteres. Fx er så mondæne ting som (ikke)nummerede lister ikke 100% oversætbare. I øvrigt er oversættelse ikke vejen at gå - og kun dårer taler efterhånden om det. Ja, faktisk er det netop én af de ting, som Rob Weir og jeg er enige om :o)

http://idippedut.dk/post/2008/05/14/Document-translation-sucks-%28When-R...

Hej Jan

Jeg tror du har helt ret i at der bliver skudt langt over målet med de forventninger der er til en udvekslingsstandard for tekstdokumenter.
Før internettets tidsalder, herskede dinosaurerne på pc'en i form af gigantiske kontorpakker der svulmede op til gigantstørrelser fordi en kontorpakke var selve omdrejningspunktet for alt arbejde på PC'en, og derfor både skulle kunne lave flowchart diagrammer, sende mails, udgive websites, designe relationsdatabaser, redigere billeder og film samt være centrum for applikationsudvikling. Derfor skulle et tekstdokument selvfølgelig også kunne rumme alt dette indhold, plus alle de nye typer indhold der kunne tænkes at komme i fremtiden. Der er stadig nogen der holder fast i den ide.

Derfor er det tankevækkende at det billede vi ser når vi åbner et nyt dokument i Word 2007 stadig forestiller et A4-ark (Et dokumentformat vi trods alt stadig kan være enige om her i landet) Og næsten alt hvad der produceres i programmet ender på papir (herunder PDF) i dette format.

En praktiserende læge der sender et notat til et hospital har ikke brug for at dokumenter skal rumme makroknapper, HD film eller andre finurligheder. Han har mest brug for at patientens CPR-nummeret ikke forsvinder fra dokumentet fordi man ikke kunne blive enige om een standard.
Det altomfattende tekstdokument er en uddød art, og vi må så bare indse at tekstbehandling stadig handler om at behandle tekst.
Hvor svært kan det være?

Og iøvrigt, Jesper, indlejrede tabeller fungerer også på tværs af platforme :-)

En praktiserende læge der sender et notat til et hospital har ikke brug for at dokumenter skal rumme makroknapper, HD film eller andre finurligheder. Han har mest brug for at patientens CPR-nummeret ikke forsvinder fra dokumentet fordi man ikke kunne blive enige om een standard.

Men hvis lægen nu laver en fremhævning via brug af formatering så er det hensigtsmæssigt at denne formatering ikke forsvinder eller ændres.

Lad os nu sige at lægen i notatet skriver "Jeg indstiller hermed til at nn får foretaget en EKG scanning og det bør (angivet med fed) ske meget snart da....."

Hvis nu rent hypotetisk at fremhævningen med fed skrift forsvinder så ændres lægen notat en smule. Lægen har sikkert ikke fremhævet 'bør' med fed blot fordi at det var sjovt. Han har gjort det fordi at han mente at det vitterligt var vigtigt at fremhæve at det efter hans vurdering var vigtigt at EKG scanning blev foretaget meget snart.

Eller hvad hvis han i notatet lister en række forskellig medicin og underneden skriver, "den medicin der er markeret med understregning har jeg midlertidigt anbefalet at patienten indstiller brug af indtil.....". Igen hvis understregningen forsvinder eller ændres til en anden form for formatering, så er det ikke hensigtsmæssigt.

Nu skal det dog siges at formatering som fed og understregning generelt virker. Men hvad med f.eks. overstregning (kun OpenOffice.org/ODF og ikke MS Office/OOXML eller den markering af fyldfarve i tabelceller som forsvinder i nogle kombinationer af MS Office/ODF/SUN ODF Plugin).

vi må så bare indse at tekstbehandling stadig handler om at behandle tekst.
Hvor svært kan det være?

Hvad så med regneark? Nu er ODF/OOXML jo dokumentformater for kontorpakker. Hvis bare vi skal sende ren tekst og ikke andet så har vi jo allerede andre fungerende formater til dette brug.

Det altomfattende tekstdokument er en uddød art

Hvad foreslår du så der pilles ud af henholdsvis ODF og OOXML? Og hvordan afgør man hvad der må komme med og ikke komme med?

Jeg mener hvis man skulle gøre noget hen af det du ønsker så skulle man lade ODF være ODF og OOXML være OOXML og så kunne man definere en tredje fælles standard som er absolut minimal. De forskellige kontorpakker skulle så bare være 100-metre mestre i at forklare og illustrere for en bruger præcis hvad der mistes når der gemmes i det minimale format. Jeg foreslår blandt andet via et preview hvor man kan se dokumentet formateret præcis som det vil se ud (på tværs af alle kontorpakker) når denne minimale standard benyttes.

Så kan alle dem der har et avanceret behov bruge MS Office/OOXML eller OpenOffice.org/ODF eller KOffice/ODF eller Symphony/ODF o.s.v. og når man så kommunikerer på tværs af kontorpakker så må man så begrænse sig til det minimale format. Det betyder selvfølgelig at langt de fleste der benytter kontorpakker professionelt og derfor i nogle situationer har mere avancerede behov (virksomheder, offentlige institutioner m.v.) de kommer til at leve med at køre med en række forskellige kontorpakker. De får altså ikke frit valg til at vælge én kontorpakke men frit valg til at vælge hvilken af de mange kontorpakker de har installeret de vil benytte til et givent behov.

Fra mit eksempel tidligere kan man jo sige, jamen det sammen kan jo opnås med ODF i dag hvis bare lægen (eller hvem det nu ellers er) f.eks. ikke er så åndsvag at benytte f.eks. overstregning. Men helt ærligt hvis der er mulighed for at lave overstregning i kontorpakken og hvis kontorpakken ikke advarer om at denne mulighed findes altså ikke i andre kontorpakker (MS Office/OOXML) er det så lægens ansvar at læse ODF og OOXML standarderne og lave sin egen huskeliste over inkompatible elementer?

Det der jo også er spørgsmålet er at hvis en sådan neddrosling af funktionalitet for at opnå interoperabilitet vinder indpas hvor mange steder får det så ellers betydning. Hvad med f.eks. web? Der er ingen tvivl om at hvis man smed CSS + javascript på porten og definerer at HTML fremover kun bestod af muligheden for at skrive lidt simpel tekst og få det formateret med fred og ikke andet, så ville vi nemt kunne komme problemet med browserspecifikke hjemmesider til livs. Siderne ville godt nok være jævnt kedelige at se på men vi ville uden problemer kunne vælge browsere frit.

Eller hvad med C++? C++ standarden er også så stor at der er mange kompilere der ikke magter at få implementeret alle funktionaliteter. Det betyder at man ikke altid bare frit kan skifte mellem C++ kompilere. Hvad hvis vi skærer 3/4 af funktionaliteten væk i C++, så burde vi bedre kunne sikre os at vi frit kan vælge.

Det store spørgsmål er dog altid, hvad skærer vi væk, og hvem bestemmer hvad der skal skæres væk og hvad der eventuelt må blive tilføjet? Eller er vi nået dertil at vi kun skærer væk og så må alt innovation stoppe af hensyn til interoperabiliteten?

En anden lille sjov tanke er at hvis det virkelig er sandt at det er det store sæt af funktionalitet der gør at man ikke kan opnå god interoperabilitet, (selv over en årrække for intet er selvfølgelig perfekt i morgen) på trods af man ikke kan påpege enkeltstående funktionaliteter som man ikke burde kunne implementere, så var alt snakken i mange år om at Microsofts lukkede office formater var med til at bibeholde deres monopol faktisk forkert. For nu siger vi reelt at selv med et åbent format kan vi stadig ikke implementere hvad Microsoft kan, fordi at mængden af funktionalitet er for stor.

Men hvis lægen nu laver en fremhævning via brug af formatering så er det hensigtsmæssigt at denne formatering ikke forsvinder eller ændres.

Lad os nu sige at lægen i notatet skriver "Jeg indstiller hermed til at nn får foretaget en EKG scanning og det bør (angivet med fed) ske meget snart da....."

Derfor bruger det danske sundhedsdatanet - standarden Medcom. 'Medcom - de gode XML-breve'(1)

Af 'XML syntaks- og kommunikationsreglerne'(2) kan man læse om de meget begrænset tekstformatterings muligheder. Medcom skriver at tekstformatering skal anvendes sparsomt da mange systemer ikke kan vise dem!

1) http://www.medcom.dk/default.asp?id=109824

2) http://www.medcom.dk/dwn146

Derfor bruger det danske sundhedsdatanet - standarden Medcom. 'Medcom - de gode XML-breve'(1)

Jep. Jeg videreførte også kun læge eksemplet fordi at det var det som der blev omtalt, selvom det er rent hypotetisk, men blot for at forklare at man kan altså ikke antage at interoperabilitet på formatering er fuldstændig ligegyldigt. Jeg kan godt huske Medcom (af navn + funktion, ikke detaljerne) fra jeg for 7-8 år siden var med til at byde på en ny sundhedsportal.

Men det er jo også et meget godt eksempel på at man har fundet en minimal løsning som man så benytter som alternativ til at vi skal tage ODF og OOXML og gøre til minimale løsninger til gene for dem som faktisk har mere avancerede behov.

Hej Henrik

Jeg mener hvis man skulle gøre noget hen af det du ønsker så skulle man lade ODF være ODF og OOXML være OOXML og så kunne man definere en tredje fælles standard som er absolut minimal.

Men så kan vi forvente at MS kommer med en fjerde standard fordi den skal kunne indeholde alle deres gamle dokumentformater. ;-)
Sagen er at Microsoft sagtens kunne gengive ODF perfekt hvis de ville - SUN ODF Plugin er for mig nok "proof of concept" på at det kan lade sig gøre.

Men hvad med f.eks. overstregning (kun OpenOffice.org/ODF og ikke MS Office/OOXML eller den markering af fyldfarve i tabelceller som forsvinder i nogle kombinationer af MS Office/ODF/SUN ODF Plugin).

At du kan finde plugins/kombinationer der ikke virker er ikke bevis for at det ikke kan lade sig gøre, men kun bevis på at din IT-leverandør/IT-afdeling har leveret det forkerte produkt.

Hej Jens Christian,

Sagen er at Microsoft sagtens kunne gengive ODF perfekt hvis de ville - SUN ODF Plugin er for mig nok "proof of concept" på at det kan lade sig gøre.

Men det er der vel heller ikke nogen, der har påstået? Alle kan jo "gengive ODF perfekt hvis de ville" - sådan er det jo også med OOXML, PDF og HTML og alle mulige andre formater. Eneste forskel på OOXML+PDF og fx ODF er jo, at man i ODF har valgt at give fortrinsret til proprietære teknologier.

PS: Mht indlejrede tabeller, så var det blot et eksempel på, at noget visuelt simpelt for en bruger sagtens kan være konstrueret overmåde komplekst i den resulterende markup.

:o)

Men så kan vi forvente at MS kommer med en fjerde standard fordi den skal kunne indeholde alle deres gamle dokumentformater. ;-)

Nej. For vi er jo blevet enige om at andre producenter ikke magter at implementere den fulde funktionalitet som MS Office understøtter alligevel. Så dem der har eksisterende gamle ms office dokumenter der benytter funktionalitet udover hvad der er fællesmængde med de formater som producenterne magter at implementere de er altså låst til MS Office indtil de er i stand til at slette disse dokumenter.

Sagen er at Microsoft sagtens kunne gengive ODF perfekt hvis de ville - SUN ODF Plugin er for mig nok "proof of concept" på at det kan lade sig gøre.

Ja hvis de blot implementerer den funktionalitet som findes i ODF og ikke i MS Office som f.eks. overstregning, blinkende tekst m.v. Og det tror jeg også i stor grad vil ske på et tidspunkt.

Men det ændrer ikke ved at der også er en komplementærmængde af funktionalitet i MS Office som du ikke kan gemme i ODF.

Grunden til at jeg tror på at Microsoft vil gøre det er at hvis de sørger for at de kan gengive ODF perfekt (eller i hvert fald tæt på) så er Microsoft jo i den unikke position at have den eneste kontorpakke der kan håndtere såvel gengivelse af ODF samt af de gamle MS Office dokumenter perfekt (eller tæt på). Med mindre altså at Sun (Oracle), IBM m.v. alligevel magter at implementere ordentlig understøttelse for OOXML. For det kan de jo godt hvis de virkeligt vil på lige fod med at Microsoft sagtens kan gengive ODF hvis de vil.

At du kan finde plugins/kombinationer der ikke virker er ikke bevis for at det ikke kan lade sig gøre, men kun bevis på at din IT-leverandør/IT-afdeling har leveret det forkerte produkt.

For at citere Rob Weir (ja IBM manden som er fortaler for ODF og modstander af OOXML):

Men når f.eks. OOXML understøtter mønstre som baggrund i celler og ODF ikke gør, og når ODF understøtter overstregning og OOXML ikke gør så er det også bevist at man opnår kun interoperabilitet på disse og lignende elementer hvis

1) Kontorpakkerne tilføjer den komplementære funktionalitet fra andre kontorpakker
2) Kontorpakkerne enten understøtter både ODF og OOXML eller et af formaterne udvides med den komplementære funktionalitet fra den anden

Så man KAN ikke levere en perfekt oversættelse mellem OOXML og ODF i dag om man så hyrede de 10.000 dygtigste udviklere i verden.

Men når f.eks. OOXML understøtter mønstre som baggrund i celler og ODF ikke gør, og når ODF understøtter overstregning og OOXML ikke gør

Jeg kan af gode grunde ikke udtale mig om ISO OOXML, men når jeg sender et ODF dokument til MS Office 2003 (m. SUN Plugin) ser overstregningen perfekt ud i MS Office. Hvad der evt. ligger i koden bagved er ligegyldigt for mig som bruger. Det er, som du citerer: "Real-world interoperability" det drejer sig om.
På samme måde kommer blinkende tekst også med - så jeg tror der er et par gamle kæpheste der skal aflives efterhånden :-)

På samme måde kommer blinkende tekst også med - så jeg tror der er et par gamle kæpheste der skal aflives efterhånden :-)

Er du sikker på at du ikke mener at blinkende tekst bliver til blinkende baggrund i MS Office? Det gør det nemlig hos mig. Men overstregningen forsvinder helt hos mig.

Det er godt nok mærkeligt

Her et et testdokument oprettet i OpenOffice.org 3.1: http://74.86.48.190/test.odt

Dokumentet indeholder to tekstlinjer med overstregning (den ene med automatisk valg af overstregningsfarve den anden med specifikt valg farve bare for at være sikker på at det ikke spiller ind) og så er der en tekstlinie der blinker.

http://74.86.48.190/msoffice_overstreg_blink.jpg er screen dump af resultatet som det ser ud i MS Office 2007 SP1 efter indlæsning ved brug af SUN ODF Plugin 3.1

Det er selvfølgelig svært at se på et billede, men den sorte baggrund blinker i stedet for teksten på den nederste linje.

Hej Henrik

Har åbnet dokumentet i MS Office 2003 (SUN plugin):
Ingen overstregning på nogen af linjerne.
Teksten blinker

OpenOffice 3.01:
Ingen overstregning på nogen af linjerne!
Teksten blinker

Eneste forskel er måden teksten blinker på!

Hvis du er nede på et niveau hvor understøttelse af blinkende tekst er en afgørende faktor - vil jeg mene at vi er så godt som i mål med interoperabiliteten for ODF.

Har åbnet dokumentet i MS Office 2003 (SUN plugin):
Ingen overstregning på nogen af linjerne.
Teksten blinker

OpenOffice 3.01:
Ingen overstregning på nogen af linjerne!
Teksten blinker

Eneste forskel er måden teksten blinker på!

Så overstregningen virkede ikke. Det regnede jeg heller ikke med, som tidligere sagt tror jeg at der er brugt god gammel kode og ikke magi i SUN ODF Plugin og MS Office understøtter ikke overstregning.

Og blinker anderledes er fordi at Microsoft understøtter blinkende baggrund men ikke blinkende tekst. Igen, ingen magi i SUN ODF Plugin men blot kode

Så den gamle kæphest var alligevel stadig i live.

Hvis du er nede på et niveau hvor understøttelse af blinkende tekst er en afgørende faktor - vil jeg mene at vi er så godt som i mål med interoperabiliteten for ODF.

Min pointe er følgende

1) Nu har vi kun pillet få udvalgte forskelligheder mellem ODF og MS Office/OOXML frem og testet at indlysende nok så kan SUN ODF Plugin ikke håndterere disse. Der er mange mange flere.

2) Hvorfor leverer Sun ikke en komplet liste af hvad der ikke virker i Sun ODF Plugin og hvorfor hjælper de ikke brugerne ved at når der importeres eller eksporteres via plugin så gøres der opmærksom på formatering der ikke kan håndteres? Du kan sagtens sige, jamen brugerne er nogle idioter hvis de benytter overstregning eller blinkende tekst eller mønstre i tabelceller m.v. Det er muligt, men er det forbudt at forsøge at hjælpe brugerne alligevel, at gøre deres hverdag lettere?

Hvis jeg skulle være i mit rigtig skeptiske hjørne så spørger jeg mig selv om den virkelige grund til at Sun ikke lægger sådan en liste ud med hvad der ikke virker i SUN ODF Plugin er fordi at de helst vil have at alle skal tro at det virker 100%, fordi at det er en ekstremt vigtigt salgsværktøj når eksisterende MS Office kunder skal overtales til at skifte til OpenOffice.org/StarOffice. I mit mindre skeptiske hjørne tror jeg simpelthen bare ikke at de har overblik over det. Det er en enorm stor opgave at sammenligne disse standarder og produkter og tag ikke fejl af at Fraunhofer også har brugt en hel del tid på at udarbejde denne rapport der satte hele debatten igang.

Rettelse:

Jeg har ovenfor skrevet:

Ja, men heldigvis er det jo efterhånden sådan, at "listen" kun findes i hovederne på fire personer - nemlig Morten Kjærsgaard fra IBM, Henrik Madsen fra DTU, Roy Schestowitz fra - nåja, ham selv samt Pamela Jones fra Groklaw.net

Der skulle have stået "Morten Kjærsgaard fra OSL". Det har ikke været min mening at påstå, at Morten Kjærsgaard er på IBMs lønningsliste.

Undskyld :o)