Jesper Lund Stocholm bloghoved

RM standardbrev 2s (Part 2, OOXML)

For efterhånden længe siden satte jeg et lille stykke arbejde i gang med at teste interop via dokumentskabelonerne fra Region Midtjylland (RM). Disse skabeloner indgik bla. i ITSTs arbejde med afviklingen af pilotprojekterne i 2007, hvori RM (Psykiatrien, så vidt jeg husker) deltog.

Årsagen fortaber sig lidt i tågerne i dag, men summa summarum er, at jeg lovede at lave en undersøgelse af interop i dag baseret på dokumenterne fra RM.

    table  
    {  
        border: solid 1px #000;  
    }  
    th  
    {  
        font-weight: bold;  
        text-align: center;  
    }  
    td  
    {  
        vertical-align: middle;  
    }  
img   
{  
    border: 0px;  
}

Jeg ville gerne lægge mig så tæt op af de tekniske tests fra 2007 for at skabe en slags "kontinuitet" og sporbarhed i undersøgelsen, men desværre har RM ikke ønsket, at jeg anvendte deres originale dokumenter i undersøgelsen. Eller - det måtte jeg gerne, men jeg måtte ikke offentliggøre screenshots af resultaterne af anvendelse af deres dokumenter og ej heller ikke de originale dokumenter.

Derfor har jeg "anonymiseret" dokumenterne, dvs jeg har udskiftet teksten i originaldokumenterne samt manipuleret indlejrede billeder, så logoet fra RM ikke fremtræder længere. Felter og andet sjov er bibeholdt og også dokumentets generelle visuelle indtryk.

Alt i alt er dokumenterne altså reelt ens - bortset fra at teksten er "transmogriffet" og billeder er blevet udskiftet.

Om dokumenterne

Dokumenterne er kendetegnede ved at bruge en bred vifte af ting, som enhver organisation vil komme til at anvende - dvs normal formattering af tekst, tekstbokse, ændrede margins, billeder og (dynamiske) felter. Derfor er de i mine øjne udmærkede til en generel test at funktionalitets-interoperabilitet imellem forskellige applikationer. At de også har deres ophav i "den virkelige verden" i RM er jo tillige perfekt.

Om testen

Jeg har tidligere beskrevet de kriterier, jeg har anvendt til denne test. Kriterierne indebærer både en visuel inspektion af dokumenterns layout, men også en "teknisk" inspektion af, om dynamiske felter er bibevarede. Jeg har tillige sammenlignet resultatet af indlæsning af mine filer med de originale, så jeg har været sikker på, at der ikke var nogen forskel.

Testen er en "Create and load"-test, dvs den imiterer den use-case i en organisation, hvor en medarbejder laver et dokument og rundsender det til en anden medarbejder. Jeg talte for noget tid siden med en embedsmand i anden sammenhæng, og han vurderede, at denne use-case passede på 99.9% af de dokumenter, der blev dannet i hans organisation. Testen er altså ikke en round-trip-test, hvor et dokument dannes, rundsendes, redigeres og herefter sendes tilbage igen.

Jeg har tidligere beskrevet kriterierne for testene, men lad mig lige gentage dem:

    Vurderingen af mine tests lander i tre kategorier, hhv "rød", "gul"  
    og "grøn".  

    "Rød":


    Denne kategori lander man i, hvis der forsvinder information fra dokumentet, dvs  
    hvis dynamiske felter, rammer, tekst, billeder etc forsvinder. Man lander også deri, hvis al information  
    er intakt - men dokumentet dog nu er så rodet, at det reelt er ubrugeligt.  

    "Gul":  

    Denne kategori lander man i, hvis al information er er intakt, men at ting har flyttet  
    sig så meget, at det vil virke forvirrende for brugeren og at denne vil tænke, at  
    noget er gået galt.  


    "Grøn":  

    Denne kategori lander man i, hvis al information er intakt. Man lander også deri,  
    hvis nogle ting har flyttet sig en lille smule, så her har jeg lagt et "petitesse-kriterie"  
    ind ifht "fuldstændig intakt". Groft sagt kan man sige, at en ændring  
    af placering af indhold er under petitessegrænsen, hvis man skal have et referencedokument  
    for at opdage det. Et dokument med et billede, der er flyttet 2 pixels til højre  
    men ellers er intakt, vil altså lande i "Grøn" kategori.

Jeg har kun testet RTM/endelige versioner af programmerne og ikke eventuelle beta-versioner. Jeg har testet programmerne i deres standardopsætning.

Når dokumentet er blevet indlæst i programmet, har jeg dannet en PDF af dokumentet - enten via en PDF printerdriver, funktionalitet i selve programmet eller via PDF-understøttelse i operativsystemet.

Om applikationerne

Jeg havde tidligere den ambition, at jeg ville teste "revl og krat", dvs hver eneste applikation, jeg kunne komme i nærheden af. Jeg har dog måttet indse, at det ville kræve for meget tid, så jeg har skåret ned på applikationerne - og jeg tester nu "kun" på de større applikationer, der i dag findes på markedet. Jeg har også forsøgt at sprede testen på så mange operativsystemer jeg kunne.

Skulle nogen ønske at teste andre applikationer, agerer jeg gerne som proxy for resultaterne, skulle nogen ønske det.

Jeg har testet DOCX-filen i følgende applikationer:

  • Microsoft Office 2007 SP2, Windows
  • Microsoft Office 2003 SP3 med compat-pack, Windows
  • Corel WordPerfect 14, Windows
  • Apple iWork '09, MacOSX
  • Lotus Symphony 1.3, MacOSX
  • OpenOffice 3.1.1, Mac, Ubuntu 9.04
  • OpenOffice NOvell Edition, Windows
  • GO-OO, Windows
  • Google Docs
  • NeoOffice, MacOSX

Resultatet for DOCX-filen

ApplikationPlatformResultat
Apple iWork '09MacOSX
Corel WordPerfect 14Windows
GO-OOWindows
Google Docs
Lotus Symphony 1.3MacOSX
OpenOffice 3.1.1, MacUbuntu 9.04
OpenOffice NOvell EditionWindows
Microsoft Office 2003 SP3 med compat-packWindows
Microsoft Office 2007 SP2Windows
NeoOfficeMacOSX
SoftMaker 2010Windows
Der er følgende bemærkninger til dokumenttesten. Hver eneste OO-klon jeg har testet dokumentet i har crashet fuldstændigt. Jeg har naturligvis schema-valideret mine dokumenter, og de er fint valide. Årsagen til ovenstående resultater for OO-klonerne er derfor fremkommet ved at jeg har indlæst det originale dokument i programmerne og vurderet resultatet. Resultatet har været præcist det samme som for Google Docs, og derfor den røde lystavle.

Konklusion
Det var egentlig meningen, at jeg ikke selv ville have konkluderet noget på baggrund af testen, men da der tilsyneladende er nogen, der ser "rødt" (host), må jeg hellere komme med et par afsluttende ord.
Mit tilbud om at lave denne test kom, da jeg i sin tid spurgte repræsentanterne fra RM, hvorfor de ikke havde valgt OOXML som deres udvekslingsformat. Deres svar var (fra hukommelsen), at man ikke ønskede at bruge et format, hvor kun Microsoft Office kunne åbne deres skabeloner. Det syntes jeg lød interessant, og jeg ville derfor gerne teste, om det nu kunne passe.
Derfor er min test jo reelt absolut positiv. At OO-klonerne og Google Docs fejler fælt er jo kendt stof og kan ikke komme bag på nogen. OOXML-understøttelsen i disse programmer er sindssygt ringe - ja nærmende sig det latterlige (flamebait!). Men jeg har selv været overrasket over, at der trods alt findes to andre implementeringer af OOXML, på vidt forskellig kodebase, der åbner dokumenterne fejlfrit. Det synes jeg er absolut positivt - og det viser med al tydelighed, at for denne (simple) test, så findes der pt., nu, i dag andre implementeringer af OOXML end de fra Microsoft.

Ja, faktisk synes jeg, at det taler enormt meget mere positivt om "implementerbarheden" og "modenheden" af OOXML, at der findes disse forskellige implementeringer af formatet - end at der findes 117 kloner af Suns OpenOffice.org med forskellig brugerflade men med samme ODF-motor.

Test-fil samt PDF'er er tilgængelige via OOXMLdoctest.zip (170.28 kb).

Kommentarer (64)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#5 Claus Agerskov

Selvom OOo hentet som Ubuntu-pakke i Ubuntu under "Om OpenOffice.org xxxx" oplyser, at det er en rigtig OOo, så er de ekstra-udvidelser GO-OO har udviklet også blevet oversat i Ubuntu-pakken.

Derfor er der delvist direkte understøttelse af Office Open XML (OOXML).

I regnarksapplikationen OOo Calc er der over 1 million rækker mod 65.536 i den originale.

  • 0
  • 0
#7 Jesper Lund Stocholm Blogger

Hej Christian,

Har du genereret et .docx dokument i MSO 2003/7 og derefter afprøvet om det kan vises korrekt i alle de andre pakker?

Mjaeh ... RM har lavet et OOXML-dokument, som de i sin tid indsendte til de pilotprojekter, som ITST i sin tid satte i verden - og som bla. CIBER deltog i den tekniske udredning af. Dette OOXML-dokument har jeg anonymiseret og herefter testet resultatet af indlæsning af dokumentet i ovenstående liste af applikationer.

  • 0
  • 0
#8 Rene Madsen

Det vil jo på den her baggrund være interessant at se den tilsvarende test med et ODF dokument, bygget op, så det ligner docx dokumentet og så åbnet i de tilsvarende pakker og se, hvordan de rangere sig.

Således det er klart, om ODF bygget op med de informationer klare sig dårligere eller bedre end docx dokumentet i de samme office pakker.

Det vil også være interessant at se, hvordan en konvertering i MS office fra docx til odf ser ud når den bliver åbnet på ny i MS office og de tilsvarende andre pakker. Jeg gør gerne førsøget når filerne kommer tilbage online.

  • 0
  • 0
#10 Christian Nobel

Mjaeh ... RM har lavet et OOXML-dokument, som de i sin tid indsendte til de pilotprojekter, som ITST i sin tid satte i verden - og som bla. CIBER deltog i den tekniske udredning af. Dette OOXML-dokument har jeg anonymiseret og herefter testet resultatet af indlæsning af dokumentet i ovenstående liste af applikationer.

Der er altså et eller andet jeg så ikke helt forstår her.

Hvis det er et dokument RM har lavet, så vil jeg antage at RM har lavet det i OO, for dernæst (åbenbart) at gemme det i OOXML.

I følge din undersøgelse, så kan selvsamme dokument så alligevel ikke aflæses korrekt når du læser det ind i OO.

Det virker påfaldende på mig, for hvis jeg laver noget i OO og gemmer det i OOXML, og så læser det ind igen i OO, så går det som regel godt.

Der må være noget mere i den historie.

Herudover ville det vel også være rimeligt at (kva det MSO jo skulle understøtte ODF) at du også foretager testen fra ODF.

/Christian

  • 0
  • 0
#11 Jesper Lund Stocholm Blogger

Hej Rene,

Det vil jo på den her baggrund være interessant at se den tilsvarende test med et ODF dokument, bygget op, så det ligner docx dokumentet og så åbnet i de tilsvarende pakker og se, hvordan de rangere sig.

Faktisk - hvis jeg husker ret - så er OOXML-dokumentet blevet til på baggrund af RMs eksisterende ODF-skabelon (altså omvendt ifht hvad du siger - men reelt er det jo blot en detalje)

Således det er klart, om ODF bygget op med de informationer klare sig dårligere eller bedre end docx dokumentet i de samme office pakker.

ODF-skabelonen klarer sig MARKANT bedre end OOXML-skabelonen. Det som er interessant i nærværende resultat er jo, at der faktisk er andre kontorpakker end Microsoft Office, der kan gøre noget intelligent med OOXML-filen. Ofte hører man jo det modsatte - at et valg af OOXML implicit indebærer et valg af Microsoft Office. Denne (simple) test viser derimod, at du i hvert fald har [i]2[/i] andre valg.

(jeg skal nok sørge for at lave en artikel om ODF-resultatet ASAP).

Det vil også være interessant at se, hvordan en konvertering i MS office fra docx til odf ser ud når den bliver åbnet på ny i MS office og de tilsvarende andre pakker. Jeg gør gerne førsøget når filerne kommer tilbage online.

Ja, jeg erkender gerne, at jeg håbede på, at der kom lidt crowd-sourcing ud af det, så det kunne være super interessant.

Jeg er sikker på, at man kan lave dokumenter, der udviser både bedre og dårligere opførsel end den her rapporterede - specielt, hvis vi taler om reel round-tripping, så hvis de dokumenter jeg har lavet kan bruges som afsæt til dette, så er det lige i øjet!

:o)

  • 0
  • 0
#12 Jesper Lund Stocholm Blogger

Hej Christian,

Hvis det er et dokument RM har lavet, så vil jeg antage at RM har lavet det i OO, for dernæst (åbenbart) at gemme det i OOXML.

Nej - iflg Jens Christian Damgaard er OOXML-dokumentet ikke et konverteret dokument. Det er et OOXML-dokument lavet manuelt i Microsoft Office 2007, så det visuelt og funktionelt svarer til ODF-skabelonen.

Herudover ville det vel også være rimeligt at (kva det MSO jo skulle understøtte ODF) at du også foretager testen fra ODF.

Det skal jeg nok :o)

  • 0
  • 0
#13 Deleted User

ODF-skabelonen klarer sig MARKANT bedre end OOXML-skabelonen.

Hvorfor så ikke bare skrotte OOXML og forsætte med ODF?

Det som er interessant i nærværende resultat er jo, at der faktisk er andre kontorpakker end Microsoft Office, der kan gøre noget intelligent med OOXML-filen. Ofte hører man jo det modsatte - at et valg af OOXML implicit indebærer et valg af Microsoft Office. Denne (simple) test viser derimod, at du i hvert fald har 2 andre valg.

Men slet ingen frie eller gratis valg.

  • 0
  • 0
#16 Deleted User

Det er jo også det RM har gjort - det er helt fint, at de har fundet noget, der virker for dem.

Pointen er jo at alle skal gøre det.

Nope - men i forhold til "pluralitet af implementeringer" er det jo ligegyldigt.

Ja, men det er ikke lige gyldigt når der for alternativet, ODF er indtil flere frie og gratis implementationer.

  • 0
  • 0
#18 Christian Nobel

Nej - iflg Jens Christian Damgaard er OOXML-dokumentet ikke et konverteret dokument. Det er et OOXML-dokument lavet manuelt i Microsoft Office 2007, så det visuelt og funktionelt svarer til ODF-skabelonen.

Og det er 100 at dokumentet er gemt i OOXML (for du nævnte før .docx, som jo ikke nødvendigvis entydigt er OOXML) og ikke været en uheldig omvej?

Din anonymisering, hvorledes har du foretaget den?

Du siger du har schema valideret dokumenterne, men det er vel ikke nødvendigvis nogen garanti for siderne ellers er forståelige/brugbare.

Hvordan fortages schema validering, er det med et MS værktøj, eller har du læst dokumenterne igennem byte for byte?

Jag kan også godt lave noget i HTML der validerer, men som alligevel ender i hat og briller.

Og mangler testen ikke der hvor OOXML dokumentet er genereret i ODF, og så indlæst af de andre pakker?

Hvis jeg laver et dokument i OO 3.1 med rammer og tabeller mv. og gemmer som OOXML, og så åbner igen med OO, så er den der næsten - det eneste der gik galt var at sidemarginer blev tabt.

/Christian

  • 0
  • 0
#19 Deleted User

Jeps - men hvis du mener, at dette er en forudsætning for valg af en konkret standard for dokumentformater, så er jeg ikke enig med dig.

Det er ikke forudsætningen. Men det er en forudsætning at frie åbne og gratis programmer har lov til at implementere standarden uden royalty betaling eller krydslicensiering af patenter.

Det scorer dog høje point hvis en standard har frie, åbne og gratis implementeringer.

  • 0
  • 0
#20 Christian Nobel

Jesper jeg ved ikke hvad det er du har lavet, men hvis jeg prøver at åbne dit .docx dokument, så får det min OO 3.1 (Ubuntu 9.10) til at crashe under åbning.

Sidste gang jeg var ude for at et dokument var så dårligt at det fik en tekstbehandling til at crashe under opstart, var da jeg havde fået ødelagt et (desværre ret stort) dokument i Word 2.0!

Jeg har enkelte gange oplevet at OO er gået ned, men dokumentet er altid blevet regenereret ved genstart af OO.

Jeg har [b]aldrig[/b] oplevet et dokument opføre sig på tilsvarende vis som det du har lavet, heller ikke et almindelig .doc fra Word 97/XP/2003!

/Christian

  • 0
  • 0
#21 Christian Nobel

En anden ting, og det kan sagtens være jeg ikke lige har fundet det, men hvis jeg kikker på dit dokument, hvor er doctypen angivet henne?

Jeg formoder at et OOXML format skal have en doctype på samme måde som HTML, som explicit fortæller hvilken en det er, så man ved om det er OOXML-S eller T?

/Christian

  • 0
  • 0
#24 Kristian Vilmann

Hej Jesper, Der er noget forkert i det fine billede med trafiklysene.

Lotus Symphony kører sikkert på Ubuntu. Men Ubuntu 9.03 findes ikke. Ubuntu 9.04 findes derimod, og jeg kan se den afvikler OOo 3.1.1 til Mac.

Der er gået noget galt....

  • 0
  • 0
#28 Jesper Lund Stocholm Blogger

(jeg samler lige alle svar herunder)

Christian,

Og det er 100 at dokumentet er gemt i OOXML (for du nævnte før .docx, som jo ikke nødvendigvis entydigt er OOXML) og ikke været en uheldig omvej?

Jeps. Jeg har adgang til det originale dokument, der er tidsstemplet engang i 2007, hvor Microsoft Office ikke havde support for ODF. På det tidspunkt var det ikke muligt at lave den ønskede konvertering.

Din anonymisering, hvorledes har du foretaget den?

Den er foretaget manuelt via udpakning af dokumentet og herefter en gennemgang af samtlige XML-filer og billeder i dokumentet.

Du siger du har schema valideret dokumenterne, men det er vel ikke nødvendigvis nogen garanti for siderne ellers er forståelige/brugbare.

Enig

Hvordan fortages schema validering, er det med et MS værktøj, eller har du læst dokumenterne igennem byte for byte?

Jeg har valideret dokumenterne både via MS egne værktøjer samt office-o-tron i Java. Den anvender T-schemas til valideringen.

Og mangler testen ikke der hvor OOXML dokumentet er genereret i ODF, og så indlæst af de andre pakker?

Nej - for testen er ikke en "konverteringstest". Du er naturligvis velkommen til at lave en sådan test :o)

Jesper jeg ved ikke hvad det er du har lavet, men hvis jeg prøver at åbne dit .docx dokument, så får det min OO 3.1 (Ubuntu 9.10) til at crashe under åbning.

Ja, det er netop, hvad jeg påpeger sidst i artiklen. Derfor er trafiklyset for OO-klonerne baseret på indlæsning af de originale dokumenter.

En anden ting, og det kan sagtens være jeg ikke lige har fundet det, men hvis jeg kikker på dit dokument, hvor er doctypen angivet henne?

Jeg formoder at et OOXML format skal have en doctype på samme måde som HTML, som explicit fortæller hvilken en det er, så man ved om det er OOXML-S eller T?

I OOXML anvender vi ikke doctypes men "media-types", der findes i filen [Content_Types]. Om et dokument er et T-dokument eller et S-dokument angives (pt.) via en "conformanceClass"-attribut. Denne attribut har default-værdi "transitional", så fraværet af den betyder, at dokumentet er et T-dokument.

Kristian Vilmann,

Lotus Symphony kører sikkert på Ubuntu. Men Ubuntu 9.03 findes ikke. Ubuntu 9.04 findes derimod, og jeg kan se den afvikler OOo 3.1.1 til Mac.

Det er nu rettet - mange tak :o)

Michael,

Ifølge mit ringe kendskab til formaterne, typer namespaces i dokumenterne på, at det er EOOXML, altså ECMA-376. Dvs de er ikke OOXML. Det er sikkert her forklaringen skal findes på, at OOo har det dårligt med dokumentet.

OOXML arvede namespaces fra ECMA-376, så disse er identiske. Dokumentet er et T-dokument (jvf dets overholdelse af schemas for OOXML).

Til alle:

Jeg forstår ikke helt jeres iver efter at finde årsagen til at OO-klonerne fejler. Jeg er ganske klar over, at der nok er et eller andet med mit dokument, men jeg skal nok finde fejlen. Hvis jeg ikke har fundet den i løbet af et par dage, så indsender jeg en bug-rapport til OOo med dokumentet - så kan det være, at de kan hjælpe.

Men at OO-klonerne fejler er ikke udslagsgivende for resultatet ovenfor, for resultatet af ikke "den crashede og bliver derfor rød". Resultatet for OO-klonerne er resultatet af indlæsning af de originale filer.

Men måske søger I blot at fjerne opmærksomheden fra, at der findes andre implementeringer af OOXML end Microsofts?

:o)

  • 0
  • 0
#29 Christian Nobel

Jeps. Jeg har adgang til det originale dokument, der er tidsstemplet engang i 2007, hvor Microsoft Office ikke havde support for ODF. På det tidspunkt var det ikke muligt at lave den ønskede konvertering.

Æh så kan det vel heller ikke være "ægte" OOXML, da OOXML ikke var en ISO standard på det tidspunkt.

Jeg forstår ikke helt jeres iver efter at finde årsagen til at OO-klonerne fejler. Jeg er ganske klar over, at der nok er et eller andet med mit dokument, men jeg skal nok finde fejlen. Hvis jeg ikke har fundet den i løbet af et par dage, så indsender jeg en bug-rapport til OOo med dokumentet - så kan det være, at de kan hjælpe.

Men at OO-klonerne fejler er ikke udslagsgivende for resultatet ovenfor, for resultatet af ikke "den crashede og bliver derfor rød". Resultatet for OO-klonerne er resultatet af indlæsning af de originale filer.

Men måske søger I blot at fjerne opmærksomheden fra, at der findes andre implementeringer af OOXML end Microsofts?

Hallo, og så var det du lige røg helt ned i mudderpølen.

Jesper, det nytter ikke at nedgøre at der er nogen der selv prøver at læse det dokument du har fremlagt, og når det så medfører at OO går i dørken, så er det da rimeligt nok med en tilbagemelding.

Du er meget hurtig med at uddele røde stoplys, men hvis nu der kommer dielsel ud af standeren når jeg tror jeg hælder benzin på min bil, og den efterfølgende bryder sammen, så er det altså for letkøbt at sige at det er en skodbil, bare fordi den ikke kan køre på diesel.

Så Jesper, et godt råd, kom ind på banen igen, men vær lige lidt seriøs.

/Christian

  • 0
  • 0
#30 Jesper Lund Stocholm Blogger

Hej Christian,

Æh så kan det vel heller ikke være "ægte" OOXML, da OOXML ikke var en ISO standard på det tidspunkt.

Dokumentet validerer ifht schemas i ISO 29500 - ergo er det et ISO 29500 conformant dokument - uanset tidspunktet det blev dannet.

Jesper, det nytter ikke at nedgøre at der er nogen der selv prøver at læse det dokument du har fremlagt, og når det så medfører at OO går i dørken, så er det da rimeligt nok med en tilbagemelding.

Rolig nu, Christian - jeg nedgør ingen. Jeg forstår blot ikke jeres iver. Jeg kunne forstå det, hvis jeg havde testet ODF-filer, men det er jo ikke tilfældet her.

Du er meget hurtig med at uddele røde stoplys, men hvis nu der kommer dielsel ud af standeren når jeg tror jeg hælder benzin på min bil, og den efterfølgende bryder sammen, så er det altså for letkøbt at sige at det er en skodbil, bare fordi den ikke kan køre på diesel.

Du skal læse, hvad jeg skriver til jer: De røde stoplys er IKKE fordi OO-klonerne crasher. De røde stoplys er et resultat af indlæsning af det originale dokument i OO-klonerne, der ikke får dem til at crashe. Desværre er indholdet totalt ubrugeligt - derfor de røde stoplys.

  • 0
  • 0
#31 Kenn Nielsen

Jeg har valideret dokumenterne både via MS egne værktøjer samt office-o-tron i Java. Den anvender T-schemas til valideringen.

Transitional er vel ikke en ISO standard. Det er vel max. en RFC + en hensigtserklæring om at vokse til Strict.

Eller har jeg misforstået noget ?

K

  • 0
  • 0
#32 Jens Christian Damgaard

Hej Jesper

Som din test viser, dur docx ikke som fælles udvekslingsformat mellem OpenOffice.org og MS Office 2003. Vi har valgt at tilbyde vore brugere "MS Office compatibility pack" i stedet. Den konverterer fra docx til doc(!) - som herefter åbner uden problemer i OpenOffice.org. Vores docx-testdokument vises identisk med originalen når vi bruger denne løsning. (og vi undgår at skulle købe MS Office licenser :-) Måske du skulle tilføje en test af denne løsning til din liste?

  • 0
  • 0
#33 Jesper Lund Stocholm Blogger

Hej Kenn,

Transitional er vel ikke en ISO standard. Det er vel max. en RFC + en hensigtserklæring om at vokse til Strict.

Eller har jeg misforstået noget ?

Ja - det har du misforstået. Hverken Strict eller Transitional er "standarder". De er derimod begge "klassifikationer" eller "conformance classes" i samme standard - nemlig ISO/IEC 29500:2008 .

:o)

  • 0
  • 0
#34 Jesper Lund Stocholm Blogger

Hej Jens Christian,

Vi har valgt at tilbyde vore brugere "MS Office compatibility pack" i stedet. Den konverterer fra docx til doc(!) - som herefter åbner uden problemer i OpenOffice.org. Vores docx-testdokument vises identisk med originalen når vi bruger denne løsning.

Dette modsvarer jo præcist de erfaringer vi kom med tilbage i 2007, hvor vi netop konkluderede, at brugte vi DOC som en slags "lingua Franca" imellem Microsoft Office og OpenOffice.org, så virkede det uden problemer.

... men så bevæger vi os jo væk fra åbne standarder ... og det var vel ikke meningen?

  • 0
  • 0
#35 Deleted User

Konklussionen på alt det her må være at OOXML er meget svær at implementere. Dels fordi den er meget stor, men også fordi selve formatet er dårligt beskrevet således at forskellige implementeringer fortolker standarden på forskellige måder. Det dur jo ikke.

En standard skal være klar og tydelig og alle skal umiddelbart læse den helt ens. Der må ikke være nogen fortolkninger.

  • 0
  • 0
#38 Jens Christian Damgaard

... men så bevæger vi os jo væk fra åbne standarder ... og det var vel ikke meningen?

Enig. Det er ikke meningen, men løser vore problemer nu og her med docx-formatet. Det er heldigvis begrænset hvor mange docx-filer vi modtager efterhånden.

Til gengæld produceres der tusindvis af ODF dokumenter hver dag, så vi er trods alt tættere på en åben standard end vi nogensinde har været.

  • 0
  • 0
#39 Jesper Lund Stocholm Blogger

Hej Jon,

Hvis det havde været nemt, så havde de gjort det helt rigtigt fra starten af.

Det forstår jeg ikke - hvem er "de"?

Dokumentet overholder jo netop kravene fra ECMA-376, dvs "fra starten af", så med din logik skulle det jo virke?

Jeg synes, at det er farligt at konkludere noget som helst på bagggrund af indlæsning i et program, der beviseligt har meget dårlig understøttelse for netop dette format.

Hvis du endelig vil konkludere noget, så skal det da ske på baggrund af de to implementeringer (WordPerfect og iWork), der gør det fejlfrit.

  • 0
  • 0
#40 Kenn Nielsen

Ja - det har du misforstået. Hverken Strict eller Transitional er "standarder".

.. men så bevæger vi os jo væk fra åbne standarder ... og det var vel ikke meningen?

Takker for udredningen.

Jeg har åbenbart fejlfortolket en halvkvædet vise, der med lidt moralsk manøvredygtighed, kan symbolisere lidt af hvert.

:o)

K

  • 0
  • 0
#41 Deleted User

@Jesper: OpenOffice har aldrig set en specifikation af .doc, men det er alligevel lykkedes at få det til at virke.

OpenOffice har adgang til OOXML specifikationen, og derfor burde det være meget nemmere at implementere. Men det er alligevel ikke lykkedes godt.

Vi kan ikke vide hvor de andre har fået deres kode fra. De kan sige hvad som helst, og vi har kun mulighed for at stole på dem.

  • 0
  • 0
#42 Jesper Lund Stocholm Blogger

Hej Jon,

OpenOffice har aldrig set en specifikation af .doc, men det er alligevel lykkedes at få det til at virke.

Du er klar over, at reverse-engineering af DOC-formatet af fyrene fra Sun tog det meste af 10 år, ikke?

Men det er alligevel ikke lykkedes godt.

Du mener så, at det skyldes et dårligt format. Jeg mener, at det nok snarere skyldes en ikke-færdig implementering (første skud i bøssen var så vidt jeg huske OOo 3.0). Jeg har også selv lavet en "OOXML-implementering", der kunne lave regneark. Men det er nok liiiige at stramme den at konkludere deraf, at siden den ikke kan indlæse alle regneark fra alle producenter, så er der noget galt med OOXML. Årsagen er nok mere, at jeg ikke har haft resourcerne til at gøre arbejdet færdigt.

I øvrigt: alle OOo-kloner crasher ved load af dette dokument, men de har jo forskellige OOXML-implementeringer. Hvis fejlen lå i OOXML-implementeringen, så ville jeg forvente forskellig opførsel. Da de opfører sig fuldstændigt ens, vil jeg tro, at fejlen nok mere ligger i OOos indlæsnings-filter - der afgør, til hvilken parser et givet dokument skal sendes til.

  • 0
  • 0
#43 Dennis Skovborg Jørgensen

Jeg er ganske klar over, at der nok er et eller andet med mit dokument, men jeg skal nok finde fejlen. Hvis jeg ikke har fundet den i løbet af et par dage, så indsender jeg en bug-rapport til OOo med dokumentet - så kan det være, at de kan hjælpe.

Jeg vil da tro de gerne tager imod en bugrapport uanset. OOo burde jo ikke gå ned uanset om din fil er valid eller ej.

  • 0
  • 0
#44 Jesper Lund Stocholm Blogger

Hej Dennis,

Jeg vil da tro de gerne tager imod en bugrapport uanset. OOo burde jo ikke gå ned uanset om din fil er valid eller ej.

Det tror jeg da, at du har ret i - men (om ikke andet, så for mig selv), så kunne jeg godt tænke mig at hitte ud af, hvor fejlen ligger.

Jeg er dog ret tilbageholdende med at lave hele anonymiseringsøvelsen igen (og så kontinuerligt teste med OOo) - det tog MEGET lang tid at lave den.

:o)

  • 0
  • 0
#45 Deleted User

I øvrigt: alle OOo-kloner crasher ved load af dette dokument, men de har jo forskellige OOXML-implementeringer. Hvis fejlen lå i OOXML-implementeringen, så ville jeg forvente forskellig opførsel. Da de opfører sig fuldstændigt ens, vil jeg tro, at fejlen nok mere ligger i OOos indlæsnings-filter - der afgør, til hvilken parser et givet dokument skal sendes til.

Måske er det bare dit dokument som er problemet...

Du mener så, at det skyldes et dårligt format. Jeg mener, at det nok snarere skyldes en ikke-færdig implementering (første skud i bøssen var så vidt jeg huske OOo 3.0). Jeg har også selv lavet en "OOXML-implementering", der kunne lave regneark. Men det er nok liiiige at stramme den at konkludere deraf, at siden den ikke kan indlæse alle regneark fra alle producenter, så er der noget galt med OOXML. Årsagen er nok mere, at jeg ikke har haft resourcerne til at gøre arbejdet færdigt.

Det er jo præcis det som er et dårligt format når de ikke kan få det implementeret. Hvis det havde været meget nemt, så havde de nok gjort det allerede.

Jeg ved godt at DOC tog lang tid.

  • 0
  • 0
#46 Jesper Lund Stocholm Blogger

Hej Jon,

Det er jo præcis det som er et dårligt format når de ikke kan få det implementeret. Hvis det havde været meget nemt, så havde de nok gjort det allerede

Skru lige tiden et år tilbage og kig på denne kommentar:

"Det er jo præcis derfor ODF er et dårligt format når Microsoft ikke kan få det implementeret. Hvis det havde været meget nemt, så havde de nok gjort det allerede"

Make sense?

Nej, vel?

  • 0
  • 0
#47 Jens Christian Damgaard

Jesper

Jeg er dog ret tilbageholdende med at lave hele anonymiseringsøvelsen igen (og så kontinuerligt teste med OOo) - det tog MEGET lang tid at lave den.

I efteråret 2009 sendte jeg dig en anonymiseret version af docx-filen, som du kunne bruge. Det kunne have sparet dig noget tid Og så ville du også have en fil der ikke fik diverse programmer til at crashe.

Både det oprindelige RM-dokument, og det jeg sendte åbner i OpenOffice uden at crashe (men med grove fejl i formatering) mens dit "anonymiserede" dokument crasher. Ergo må der være sket en ændring da du pakkede filen ud og ændrede i den.

Hvis jeg skal sende dig min anonymiserede fil igen, siger du bare til.

  • 0
  • 0
#48 Jesper Lund Stocholm Blogger

Hej Jens Christian,

I efteråret 2009 sendte jeg dig en anonymiseret version af docx-filen, som du kunne bruge. Det kunne have sparet dig noget tid Og så ville du også have en fil der ikke fik diverse programmer til at crashe.

Der var to mål med min menuelle proces. Det ene var at sikre mig, at indholdet modsvarede det oprindelige dokument. Det gjorde din fil ikke - strukturen i dokumentet var blevet ændret. Dette gav den anden grund - nemlig at dokumenterne ikke opførte sig ens.

Ergo må der være sket en ændring da du pakkede filen ud og ændrede i den.

Ja godaw, det er jeg da helt enig med dig i - og det har jeg også tidligere påpeget selv. Spørgsmålet er jo, hvorfor alle andre testede applikationer end OO-klonerne ikke har noget problem med at åbne filen.

  • 0
  • 0
#49 Martin Bøgelund

Spørgsmålet er jo, hvorfor alle andre testede applikationer end OO-klonerne ikke har noget problem med at åbne filen.

Forventer du at RM vil åbne dokumenterne og editere i dem på samme måde som du gjorde? Hvad betyder det for relevansen af din use-case?

  • 0
  • 0
#50 Jesper Lund Stocholm Blogger

Hej Martin,

Forventer du at RM vil åbne dokumenterne og editere i dem på samme måde som du gjorde?

Nope

Hvad betyder det for relevansen af din use-case?

Ingen anelse - men jeg forstår jo heller ikke, hvorfor dette er kommet til at handle om, hvorfor OO-klonerne crasher. Det eneste man reelt kan konkludere positivt af min test er, at der [b]er[/b] alternativer til Microsoft Office, der kan åbne skabelonerne fra RM.

  • 0
  • 0
#51 Jens Christian Damgaard

Der var to mål med min menuelle proces. Det ene var at sikre mig, at indholdet modsvarede det oprindelige dokument. Det gjorde din fil ikke - strukturen i dokumentet var blevet ændret. Dette gav den anden grund - nemlig at dokumenterne ikke opførte sig ens.

Der var kun udskiftet billeder og tekst!

Hvordan var strukturen ændret, og hvorledes opførte dokumenterne sig forskelligt?

  • 0
  • 0
#52 Deleted User

Ingen anelse - men jeg forstår jo heller ikke, hvorfor dette er kommet til at handle om, hvorfor OO-klonerne crasher. Det eneste man reelt kan konkludere positivt af min test er, at der er alternativer til Microsoft Office, der kan åbne skabelonerne fra RM.

Men ingen frie åbne og gratis alternativer. Og ikke nok med det. Der er ikke engang noget alternativ på Linux, FreeBSD, ... . Den eneste måde at få OOXML i følge din test er ved at køre windows eller mac os x.

Vælger man derimod ODF, så er der understøttelse på en masse forskellige platforme.

  • 0
  • 0
#53 Jesper Lund Stocholm Blogger

Hej Jens Christian,

I efteråret 2009 sendte jeg dig en anonymiseret version af docx-filen, som du kunne bruge

For en god ordens skyld modtog jeg en DOCX-fil fra din kollega Martin og ikke fra dig. Jeg antager, at det er dette dokument vi taler om?

Der var kun udskiftet billeder og tekst!

Hvordan var strukturen ændret, og hvorledes opførte dokumenterne sig forskelligt?

Der var meget mindre tekst i dokumentet, der var indsat hårde sideskift og links var fjernet.

I det dokument jeg har anonymiseret har jeg gjort mig umage for at sikre, at alle afsnit var med samme linieantal og tegnantal, at alle links (incl længde af tekst) var bevarede etc.

Jeg vil gerne gentage: jeg forstår slet ikke, hvorfor I er så mobsede over min test. Jeg har ikke konkluderet noget som helst på baggrund af at OO-klonerne crashede.

  • 0
  • 0
#54 Jesper Lund Stocholm Blogger

Hej Jon,

Men ingen frie åbne og gratis alternativer.

Nej, det er korrekt, men som vi også blev enige om ovenfor, er det ikke voldsomt relevant ifht anbefaling af en konkret standard. Det relevante er nemlig, at

[b]Jon:[/b] Men det er en forudsætning at frie åbne og gratis programmer har lov til at implementere standarden uden royalty betaling eller krydslicensiering af patenter.

Og så er vi heldigvis i mål ifht både ODF og OOXML.

:o)

  • 0
  • 0
#56 Martin Bøgelund

Ingen anelse - men jeg forstår jo heller ikke, hvorfor dette er kommet til at handle om, hvorfor OO-klonerne crasher.

Det forstår jeg til gengæld godt.

Der er nemlig her på Version2 en tradition for at man debatterer indholdet i de blog-indlæg, som debatten hører til.

Og du skrev selv i blog-indlægget:

At OO-klonerne og Google Docs fejler fælt er jo kendt stof og kan ikke komme bag på nogen. OOXML-understøttelsen i disse programmer er sindssygt ringe - ja nærmende sig det latterlige (flamebait!).

Bemærk din afsluttende "(flamebait!)".

På det tidspunkt du skrev bloggen, må du øjensynligt have forventet kraftige reaktioner på dette crash.

Så undskyld mig, hvis jeg nu sidder med fornemmelsen af at du taler med to tunger, når du nu påstår at du ikke forstår hvorfor det er kommet til at handle om OOo-crash...

OOXML er et skralde-format, som er meget vanskeligt at håndtere for andre en Microsoft - kun et par andre kommercielle spillere er lykkedes med det iflg. din egen test.

Men istedet for at erkende at det er vanskeligt at understøtte, kaster du flamebait ud for at lede opmærksomheden bort fra OOXMLs vanskelige implementérbarhed, ved at prøve at få det til at se ud som om OpenOffice bare er for dårligt.

Fokus i udviklingen af OpenOffice skal naturligvis ikke gå til understøttelsen af noget der er uløseligt forbundet til Microsoft, men til understøttelsen af det eneste rigtigt frie dokumentformat: ODF.

OOXML er lige så meget stedbarn hos OpenOffice, som ODF er stedbarn hos Microsoft. Men trods det er der dog så meget proffessionalisme hos OpenOffice-udviklerne, at de ærligt forsøger at understøtte OOXML native nu og her, så godt de kan, med de begrænsede ressourcer de kan afse til det.

For selvfølgelig skal de lægge kræfterne i ODF. Det er det der på sigt giver bedst mening.

  • 0
  • 0
#57 Jens Christian Damgaard

For en god ordens skyld modtog jeg en DOCX-fil fra din kollega Martin og ikke fra dig. Jeg antager, at det er dette dokument vi taler om?

Så forstår jeg bedre: det dokument jeg taler om blev lagt ud i på din blog under "RM Standardbrev Part 1" sammen med et par PDF udskrifter af resultatet i vore kontorpakker. Tror dog ikke at linket virker mere, men sender dig lige de tre filer til info!

Jeg vil gerne gentage: jeg forstår slet ikke, hvorfor I er så mobsede over min test.

At stille spørgsmål er vel ikke at være mobset?

  • 0
  • 0
#58 Deleted User

Jeg vil gerne gentage: jeg forstår slet ikke, hvorfor I er så mobsede over min test. Jeg har ikke konkluderet noget som helst på baggrund af at OO-klonerne crashede.

Er vi mobsede? Det ved jeg ikke rigtigt. Men her er nogle forklaringer på hvorfor du kan opfatte det sådan. Rækkefølgen er mere eller mindre tilfældig.

  • Vi er sure over at OO crasher når man giver den input data i forkert udformning. Det er dårligt når programmer crasher. De bør altid sige "garbage data" og forsætte med at være brugbar. Du kommer og siger det, og du gnider det ind i vores ansigter. => helt naturlig menneskelig reaktion at vi ikke elsker dig for det.

  • du anerkender ikke argumenter om at det er vigtigt at der er frie åbne og gratis implementationer på frie åbne og gratis platforme. Det synes vi er meget vigtigt. => helt naturlig menneskelig reaktion at vi ikke elsker dig for det.

  • Du arbejder på en standard som kom for sent, specielt nu hvor udbredelsen af funktionel ODF ser ud til at dække samtlige platforme. Vi føler at du spilder tiden og resourcer. => helt naturlig menneskelig reaktion at vi ikke elsker dig for det.

  • Du kommer med de her informationer NU og i et åbent brev hvor du forsøger at påvirke beslutningen i en retning vi ikke ønsker. => helt naturlig menneskelig reaktion at vi ikke elsker dig for det.

  • du prøver at sige at det handler om teknik, når vi alle sammen godt ved at det her handler stort set ikke om teknik, men om politik. Vi ønsker en politik som er væsentlig anderledes end den det lader til at du er fortaler for. => helt naturlig menneskelig reaktion at vi ikke elsker dig for det.

Jeg forventer i øvrigt at du på din side har støtter som har samme helt naturlige menneskelige reaktioner som gør at de ikke elsker os.

  • 0
  • 0
#59 Jesper Lund Stocholm Blogger

Hej Martin,

På det tidspunkt du skrev bloggen, må du øjensynligt have forventet kraftige reaktioner på dette crash

Forstå det nu:

  • Jeg har indlæst mit eget dokument i OO-klonerne - her crasher de allesammen.

  • Jeg har indlæst det originale dokument i OO-klonerne - her crasher de ikke, men indholdet er ubrugeligt.

Jeg har ikke på noget tidspunkt i min test refereret eller konkluderet noget om crash af OO-klonerne. Jeg har netop indlæst de originale dokumenter i OO-klonerne for at kunne se resultatet.

Min udtalelse ovenfor har intet med crashet at gøre - det har med indlæsningen af de originale dokumenter at gøre.

ved at prøve at få det til at se ud som om OpenOffice bare er for dårligt.

OOo [b]er[/b] for dårlig - til indlæsning af OOXML-dokumenter. Min test bekræfter jo blot det, som Jens Christian og de andre fra RM hele tiden har sagt, nemlig at OOXML sammen med OOo ikke giver mening. Der er INTET nyt i dette. Men det er interessant, at så længe Jens Christian siger, at OOo og OOXML ikke går sammen, så er det en (åbenbart) valid kritik af OOXML ... men når jeg siger det samme, så er det en urimelig kritik af OOo.

:o)

  • 0
  • 0
#60 Deleted User

OOo er for dårlig - til indlæsning af OOXML-dokumenter. Min test bekræfter jo blot det, som Jens Christian og de andre fra RM hele tiden har sagt, nemlig at OOXML sammen med OOo ikke giver mening. Der er INTET nyt i dette. Men det er interessant, at så længe Jens Christian siger, at OOo og OOXML ikke går sammen, så er det en (åbenbart) valid kritik af OOXML ... men når jeg siger det samme, så er det en urimelig kritik af OOo.

Den menneskelige forklaring er at du ønsker at OOXML skal bruges af samfundet. Det ønsker vi ikke.

Det er ikke vores opfattelse af Jens Christian at han ønsker at samfundet skal bruge OOXML.

Du siger noget negativt om Open Office, hvorimod Jens Christian siger noget negativt om OOXML.

  • 0
  • 0
#62 Thomas Jensen

Det er vel ikke negativt at konstatere at Open Office ikke kan håndtere OOXML særlig godt. Det er vel bare fakta og så vidt jeg kan se, er det det eneste der bliver sagt om Open Office i testen, ikke at det er et dårligt produkt (nej, det siger jeg ikke at det er) eller andet. Blot at den ikke lige kan håndtere OOXML.

Men det er da interessant at se at det er lykkes for Corel og Apple at understøtte det.

  • 0
  • 0
Log ind eller Opret konto for at kommentere