
RM Standardbrev 2s (Part 1)
For noget tid siden var jeg i kommentar-samtale med Martin fra Region Midtjylland (RM) omkring deres valg af OpenOffice.org som standardapplikation og ODF som standarddokumentformat. Jeg spurgte i debatten om, hvorfor man eksempelvis ikke havde valgt OOXML som standardokumentformat og jeg fik svaret, at det bla skyldtes, at deres standardskabeloner ikke kunne indlæses af andre end Microsoft Office - og at OOXML-understøttelsen på tværs af applikationer dermed ikke var god nok.
th
{
font-weight: bold;
text-align: center;
}
Jeg har ikke noget belæg for at tro, at man ikke har fundet en løsning, som virker
for dem i RM, men jeg syntes alligevel, at det kunne være interessant at kigge nærmere
på, hvor galt det står til med OOXML-understøttelsen i markedet.
Jeg besluttede mig derfor for at lave en load-test
af DOCX-udgaven af skabelonerne fra RM. Jeg har derefter testet dem på
stort set alle de applikationer jeg kunne komme i nærheden af - og vel at mærke
seneste "RTM" eller produktionsmodne udgave. KOffice er derfor eksempelvis testet
i version 2.0, der er seneste RTM-udgave via Synaptics på ubuntu 9.04.
Jeg har testet skabelonerne dokumenterne
i følgende programmer og på følgende platforme:
<table cellpadding="3" width="100%">
<tr>
<th>
Applikation
</th>
<th>
Mac
</th>
<th>
ubuntu
</th>
<th>
Windows
</th>
</tr>
<tr>
<td>
Microsoft Office 2007 SP2
</td>
<th>
</th>
<th>
</th>
<th>
X
</th>
</tr>
<tr>
<td>
Microsoft Office 2003 SP3
</td>
<th>
</th>
<th>
</th>
<th>
X
</th>
</tr>
<tr>
<td>
Microsoft Office 2003 SP3 incl Sun ODF Plugin
</td>
<th>
</th>
<th>
</th>
<th>
X
</th>
</tr>
<tr>
<td>
Microsoft Office 2003 SP3 incl CleverAge plugin
</td>
<th>
</th>
<th>
</th>
<th>
X
</th>
</tr>
<tr>
<td>
iWork '09
</td>
<th>
X
</th>
<th>
</th>
<th>
</th>
</tr>
<tr>
<td>
Corel WordPerfect 14
</td>
<th>
</th>
<th>
</th>
<th>
X
</th>
</tr>
<tr>
<td>
IBM Lotus Symphony 1.3
</td>
<th>
X
</th>
<th>
X
</th>
<th>
X
</th>
</tr>
<tr>
<td>
OpenOffice.org 3.1
</td>
<th>
X
</th>
<th>
</th>
<th>
X
</th>
</tr>
<tr>
<td>
OpenOffice Novell Ed 3.1
</td>
<th>
</th>
<th>
</th>
<th>
X
</th>
</tr>
<tr>
<td>
GO-OO
</td>
<th>
</th>
<th>
</th>
<th>
X
</th>
</tr>
<tr>
<td>
AbiWord
</td>
<th>
</th>
<th>
X
</th>
<th>
X
</th>
</tr>
<tr>
<td>
KOffice 2.0
</td>
<th>
</th>
<th>
X
</th>
<th>
</th>
</tr>
<tr>
<td>
TextMaker 2008
</td>
<th>
</th>
<th>
X
</th>
<th>
X
</th>
</tr>
</table>
I alt har jeg testet 18 forskellige kombinationer.
Hvad gjorde jeg:
Jeg har lavet en "Indlæsningstest" af de 14 kombinationer. Konkret har
jeg indlæst dokumentet i hver applikation. Herefter har jeg lavet en visuel kontrol
af dokumentets indhold, felter, billeder etc, og til sidst jeg har dannet en PDF
af dokumentet, som applikationen "ser det". På Windows har jeg brugt CutePDF
printer driver, på Mac OSX har jeg brugt den indbyggede "Save as PDF"
og på ubuntu ligeledes den indbyggede PDF-eksport funktionalitet.
(Det har i øvrigt været en total dejavu-oplevelse af lave disse tests. [
CIBER](http://www.ciber.dk) deltog jo i efteråret 2007 sammen med bla. IBM, Novell og Microsoft
i en teknisk udredning af ITST's pilotprojekter, og reelt har jeg lavet stort set
det samme igen. Eneste forskel er dog nu, at CIBER er alene om det ... og at indeklimaet
derhjemme er bedre end i det bette lokale vi sad sammenkrøblede i hos Sogeti i Høje-Tastrup.)
Da mange af programmerne har overlap, har jeg brugt Microsoft Virtual PC 2007 til
at dannet et image til hvert program på Windows-platformen. Hver af disse images
er derfor fuldstændigt separerede fra de andre. Operativsystemet på den virtuelle
maskine er Windows XP UK SP3 - fuldt opdateret med alt fra Microsoft Update. Programmerne på ubuntu er alle installeret på samme installation af ubuntu 9.04 hanky panky ed.
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.
Fortsættelse følger ... :o)
Jesper Lund Stocholm er seniorarkitekt hos konsulentfirmaet CIBER. Han er formand for udvalget i Dansk Standard, der vedligeholder og udvikler dokumentformaterne ODF og OOXML i dansk regi, og han deltager aktivt i det internationale arbejde med formaterne i ISO.
Follow @jlundstocholmKommentarer (47)
Hej Jesper
Så vidt jeg husker det er RM's skabelen i ODF og ikke DOCX?
Du skriver som forvirrer mig:
"
Jeg besluttede mig derfor for at lave en load-test af DOCX-udgaven af skabelonen fra RM.
"
Mener du ODF udgaven, eller har duproduceret en DOCX udgave som anvender samme principper som ODF udgaven (mht f.eks placering af højre kolonne osv.)?
Mvh
Jens Jakb
Er det muligt at se den modsvarende ODF test og se den skabelon der bliver testet med?
Blot for sammenligningens skyld og for at man ved selvsyn kan se, hvordan det ser ud i sin egen installation af "office" pakke?
Opdatering 2009-10-15 kl. 8:54:
Jeg var lige lovligt hurtig med artiklen i går, så jeg har rettet lidt i nogle formuleringer (oprindelig tekst er bevaret) og lavet et par links.
I øvrigt: hvis nogen har forslag til kombinationer af platform/applikation, så sig endelig til -jeg kan stadig nå at teste andre programmer. Mine mulige platforme er:
Windows XP
Mac OS X (ikke snow-leopard)
ubuntu 9.04
(og nej, jeg gider ikke skrive noget i terminalen i ubuntu for at komme til at kunne installere fx seneste udgave af OOo. Programmet skal kunne hentes via de pakkemanagers, der findes i ubuntu uden at skulle gøre andet end point-and-click)
:o)
Hej Rene,
Er det muligt at se den modsvarende ODF test og se den skabelon der bliver testet med? Blot for sammenligningens skyld og for at man ved selvsyn kan se, hvordan det ser ud i sin egen installation af "office" pakke?
Bare rolig - jeg skal nok dokumentere alt sammen med både oprindelige filer og PDF'er.
:o)
Lyder godt - er skam ikke urolig for din dokumentation, mere bare nysgerrig :-)
Hej René,
Lyder godt - er skam ikke urolig for din dokumentation, mere bare nysgerrig :-)
Jeg skal nok gør det lødigt :o)
RM har sendt mig en skabelon i DOCX-format.
Hvad er det så lige du tester?
Du skriver at du vil teste OOXML-understøttelsen - er det ISO OOXML? Er det den der har .docx endelsen?
Du skriver at du har fået en version af deres skabelon i DOCX-format - var det ikke OOXML du ville teste? Hvorfor skriver du så ikke "OOXML" i stedet for "DOCX-format"?
Og var RM's skabelon ikke i ODF oprindeligt? Hvilken ODF - der findes jo flere versioner, hvilket du selv påpeger temmelig ofte. Og hvis de har konverteret skabelonen til "DOCX-formatet" fra et oprindeligt ODF format, før de sendte den til dig, vil det så ikke reelt være en eksport af et ODF-dokument til "DOCX-format" [i]vha. RM's tekstbehandlingspakke[/i] du reelt tester? Altså væsentligt smallere scope end det du lægger op til i din tekst?
Dit test-setup virker i artiklen til at være en rodet gang "hovsa" uden detaljeret redegørelse for scope, forudsætninger eller formål.
Jeg håber derfor at du enten vil rette op på den manglende videnskabelighed i din tilgang, eller i det mindste afstå fra at udbasunere de store, eviggyldige sandheder med din "test" som eneste udgangspunkt.
Hej Martin,
Du skriver at du vil teste OOXML-understøttelsen - er det ISO OOXML? Er det den der har .docx endelsen?
Jeps
Du skriver at du har fået en version af deres skabelon i DOCX-format - var det ikke OOXML du ville teste? Hvorfor skriver du så ikke "OOXML" i stedet for "DOCX-format"?
Faktisk har jeg fjernet det eneste sted ordet "DOCX" stod i artiklen. Hvis Jeg skal fremover konsekvent bruge ordet "OOXML" og ikke "DOCX" - ganske som jeg bruger ordet "ODF" og ikke "ODT".
Og var RM's skabelon ikke i ODF oprindeligt? Hvilken ODF - der findes jo flere versioner, hvilket du selv påpeger temmelig ofte. Og hvis de har konverteret skabelonen til "DOCX-formatet" fra et oprindeligt ODF format, før de sendte den til dig, vil det så ikke reelt være en eksport af et ODF-dokument til "DOCX-format" vha. RM's tekstbehandlingspakke du reelt tester? Altså væsentligt smallere scope end det du lægger op til i din tekst?
Der var en grund til, at jeg tilføjede links til artiklen til den debat, som vi havde dengang. Deri kan du nemlig se, at OOXML-filen ikke er et konverteret dokument.
Omkring versionen af ODF, så har RM jo aldrig konkretiseret den version de hentyder til, når de har sagt, at "ODF er eneste dokumentformat, der virker" (eller lignende). RM har ikke ønsket at sende mig deres ODF-skabelon, og derfor har jeg pt. endnu ikke testet ODF-skabelonen.
Dit test-setup virker i artiklen til at være en rodet gang "hovsa" uden detaljeret redegørelse for scope, forudsætninger eller formål. Jeg håber derfor at du enten vil rette op på den manglende videnskabelighed i din tilgang, eller i det mindste afstå fra at udbasunere de store, eviggyldige sandheder med din "test" som eneste udgangspunkt.
Nu har jeg jo ikke konkluderet noget endnu, og idéen med at skrive en "primer" er netop at få feedback fra andre som dig, der har forslag til forbedringer.
... så tak for dine input - jeg retter op på det.
:o)
Først en opklaring. Du skriver OpenOffice.org 1.3, mener du ikke OpenOffice.org 3.1? Og hvorfor ikke under Ubuntu?
Hvorfor ikke IBM Lotus Symphony 1.3 på Ubuntu?
Nyt:
Abiword under Windows: http://www.abisource.com/downloads/abiword/2.6.8/Windows/abiword-setup-2...
http://www.abisource.com/downloads/abiword/2.6.8/Windows/abiword-plugins...
Hov ...
Sætningen
"Hvis Jeg skal fremover konsekvent bruge ordet "OOXML" og ikke "DOCX" - ganske som jeg bruger ordet "ODF" og ikke "ODT"."
Skulle naturligvis have været
"Jeg skal fremover konsekvent bruge ordet "OOXML" og ikke "DOCX" - ganske som jeg bruger ordet "ODF" og ikke "ODT".
:o)
Hej Michael,
Først en opklaring. Du skriver OpenOffice.org 1.3, mener du ikke OpenOffice.org 3.1?
Jeg mener OOo 3.1.1 EN
Og hvorfor ikke under Ubuntu?
Seneste version af OOo, der er tilgængelig via pakkepakkemanager i ubuntu er 3.1 (i hvert fald sidst jeg kiggede). Hvis der er nogen, der mener, at det vil være mere relevant for testen at aktivere endnu et repo i Synaptics for at få OOo 3.1.1 med, så kigger jeg gerne på det.
Hvorfor ikke IBM Lotus Symphony 1.3 på Ubuntu?
Da jeg installerde ubuntu 9.04 sidst var Symphony kun tilgængelig i version 1.3 til ubuntu 8.etellerandet.
Jeg booter lige min ubuntu op og sørger for at se, hvilke programmer, der er opdateringer til.
Mht Abiword på Windows, så kigger jeg også på det.
:o)
Tak for input.
Hej Jesper
Spændende initiativ! Hvis du har mulighed for det, ville det interessere mig, om du testede skabelonen i TextMaker 2008 til Windows og Linux også:
http://www.softmaker.com/english/ofwdemo_en.htm
http://www.softmaker.com/english/ofldemo_en.htm
I øvrigt hedder det iWork '09 og ikke iWorks 9 :-)
mvh Kristoffer
Hej Kristoffer,
Spændende initiativ! Hvis du har mulighed for det, ville det interessere mig, om du testede skabelonen i TextMaker 2008 til Windows og Linux også:
Jeg putter dem på listen.
:o)
OOo 3.1.1 i Ubuntu 9.04
1) Åben en terminal og copy/paste følgende: sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 247D1CFF
2) Åben programmet system->administration->software sources
Vælg fanebladet third-party software og klik på add. I dette fremkomne vindue copy/pastes følgende: deb http://ppa.launchpad.net/openoffice-pkgs/ppa/ubuntu jaunty main
3) Kør update manager og genopfrisk pakkearkivet. Der skulle nu blandt eventuelt andet blive meddelt, at der findes en opdatering af OpenOffice.org fra 3.0.1 til 3.1.1
Hej Michael,
1) Åben en terminal og copy/paste følgende: sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 247D1CFF 2) Åben programmet system->administration->software sources Vælg fanebladet third-party software og klik på add. I dette fremkomne vindue copy/pastes følgende: deb http://ppa.launchpad.net/openoffice-pkgs/ppa/ubuntu jaunty main
*sigh ... lad os alle sige i kor:
"Linux er også for Hr. og Fru Jensen"
;o)
Jeg kaster mig over det ...
Man kan jo også gøre, som man ville gøre på windows og downloade pakken fra www.openoffice.org. Det er nok løsningen for Hr. og Fru Jensen, hvis de endelig skal have "bleeding edge".
Jeg ved godt at man så går uden om pakke manageren, men det er dog en .deb fil man henter. Man kan ikke få i både pose og sæk...ikke engang med Linux :o)
Hej Thomas,
Man kan jo også gøre, som man ville gøre på windows og downloade pakken fra www.openoffice.org. Det er nok løsningen for Hr. og Fru Jensen, hvis de endelig skal have "bleeding edge". Jeg ved godt at man så går uden om pakke manageren, men det er dog en .deb fil man henter. Man kan ikke få i både pose og sæk...ikke engang med Linux :o)
Ok - så jeg skal vælge
Linux 32-bit DEB
?
(og hvad betyder forkortelserne?)
Jeg prøver at hente DEB-filen :o)
Jeg vil dog stærkt fraråde dette, da deb-pakkerne fra OpenOffice.org installerer programmet et andet sted end pakkerne fra Ubuntu, hvorfor Ubuntu's version ikke fjernes.
Jeg har prøvet, og aldrig fået det til at virke!
Hej Michael,
Når man går ind på openoffice.org fra ubuntu 9.04, så foreslår den selv, at man skal hente DEB-filen OOo_3.1.1_LinuxIntel_install_en-US_deb.tar.gz. Mon så ikke det er godt nok?
Kan man starte med at fjerne OOo 3.0 (som er std på ubuntu 9.04) og så installere 3.1.1 bagefter?
Anyways, jeg kan se, at Symphony er i version 1.3 allerede og mon der er så stor forskel på OOo på Windows/MAC/ubuntu?
Jeg tror reelt ikke, at det er noget problem - forskellene skal nok findes i selve programmerne og ikke i, hvilken platform de afvikles på.
hmrf ...
ubuntu@ubuntu:~$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 247D1CFF
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --secret-keyring /etc/apt/secring.gpg --trustdb-name /etc/apt/trustdb.gpg --keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv-keys 247D1CFF
gpg: requesting key 247D1CFF from hkp server keyserver.ubuntu.com
gpg: keyserver timed out
gpg: keyserver receive failed: keyserver error
Jeg prøver igen lidt senere :o)
Hej Jesper.
Du kan undvære key'en.
Hvis du har lagt ppa repositiriet ind i sources.list som anvist kan du installere uden key.
OOo3.1.1 vil uden key stå som "ikke godkendt" software fordi der ikke er en valid key til repositoriet.
Hvis du vælger at installere vil OOo3.1 blive installeret på samme måde som hvis du havde en valid key til repo.
Kunne godt tænke mig at se resultatet af dine tests i screendumps eller som PDF'er du lagde til download.
For at mindske mængden af muddderkastning synes jeg det kunne være godt om du specifikt angav hvad du tester:
OOXML (strict) = ISO standarden
OOXML (transitional) = Ecma konsortieudgaven
.....
Ser frem til at høre om dine resultater
/Jk
Prøv dette i stedet for:
sudo apt-key adv --keyserver pgp.mit.edu --recv-keys 247D1CFF
$ gpg --search-keys 247D1CFF
gpg: searching for "247D1CFF" from hkp server pgp.mit.edu
(1) Launchpad PPA for OpenOffice.org Scribblers
1024 bit RSA key 247D1CFF, created: 2009-01-21
Hej Jens,
(og lidt Martin)
For at mindske mængden af muddderkastning synes jeg det kunne være godt om du specifikt angav hvad du tester: OOXML (strict) = ISO standarden OOXML (transitional) = Ecma konsortieudgaven
Jeg må reelt blive dig svar skyldig indtil videre. Jeg ville jo oprindeligt teste RMs tese om at "ODF virker" og "OOXML virker ikke", men jeg har ikke kunnet få RM til at kvalificere, hvilke versioner de taler om. Hvis du kan trække i nogle tråde her, så vil det være perfekt.
(og så er jeg i øvrigt løbet ind i nogle andre udfordringer (omkring IPR) med RM, men det er en anden sag, som jeg vil beskrive på et senere tidspunkt - tror jeg)
:o)
Men derudover er det jo vigtigt at bemærke, at jeg ikke tester "document conformance" men derimod "document interop". De to ting er ikke nødvendigvis det samme.
Kunne godt tænke mig at se resultatet af dine tests i screendumps eller som PDF'er du lagde til download.
Min plan er at give jer følgende:
Et farverigt overblik over resultatet af kategoriseringen ovenfor
Fuld dokumentation for resultatet, dvs en forklaring på kategoriseringen samt originalfiler og PDF'er for samtlige loadtests.
:o)
Jeg har opdateret tabellen ovenfor efter de input jeg har fået i debatten efter indlægget - tak for dem. Dette er jo crowd-sourcing på fineste vis (eller, Wisdom of the crowd, i det mindste)
Hvis der er nogen af jer, der har kommentarer til selve kategoriseringen og eksempelvis kriterierne for, hvordan man kommer i den ene eller den anden kasse, så sig endelig til.
:o)
Hej Jesper
Du skriver i dit indlæg at vi ikke har valgt OOXML fordi det
..bla skyldtes, at deres standardskabeloner ikke kunne indlæses af andre end Microsoft Office
Jeg tror det er på tide at få rettet et par misforståelser:
- Vore standardsskabeloner er i ODF format
- Det docx dokument som du vil teste er IKKE en skabelon.
- docx-dokumentet blev konstrueret i forbindelse med pilottest med ITST og Århus kommune i 2007, da der ikke fandtes virkelige docx-filer hos hverken ÅK eller RM.
Vi har brugt dokumentet til løbende at teste docx understøttelsen i f.eks. OpenOffice o.a. Desværre uden at vi har set noget brugbart endnu, på trods af at dokumentet er forholdsvist simpelt.
Jeg ser frem til dine testresultater, og håber også du bruger nogle af ODF eksempelfilerne fra din testsamling, til en tilsvarende test.
Hej Jens Christian,
Tak for dit svar,
1. Vore standardsskabeloner er i ODF format
Hvilken version af ODF?
2. Det docx dokument som du vil teste er IKKE en skabelon.
Ok. Jeg vil jo reelt bruge det til det samme som jer - nemlig at teste, hvor langt OOXML-understøttelsen er i markedet. Til det egner jeres dokument sig jo ganske glimrende.
Har du mulighed for at sende mig jeres ODF-skabelon?
Hvilken version af ODF?
Er ikke sikker, men mener det er 1.0 eller 1.1 (kan du ikke se det ud af filen?)
Har du mulighed for at sende mig jeres ODF-skabelon?
Desværre ikke. Men du har den allerede - det er nemlig den der ligger i testsamlingen fra pilottesten, og som du skrev tidligere har du allerede kopier af disse filer.
Husk blot at det er vidt forskellige testdokumenter, og at det derfor ikke vil give mening at teste docx-filen overfor f.eks. odt-dokumentet "standardbrev"
Hej Jens Christian,
Er ikke sikker, men mener det er 1.0 eller 1.1 (kan du ikke se det ud af filen?)
Jo - jeg har en fil her, der er "1.0". Hvis det er den I stadig bruger, så anvender jeg jo bare den. Jeg kunne dog blot forestille mig, at siden filen efterhånden er 2 år gammel, så havde I på et tidspunkt opgraderet filen til senest version i OOo, nemlig 1.2 . Hvis det er tilfældet, at I har gjort dette, vil jeg gerne have en kopi af filen - så vi er sikre på, at jeg tester den rigtige fil.
Meta-data fra filen er:
[code=xml]
<meta:generator>OpenOffice.org/2.0$Win32 OpenOffice.org_project/680m5$Build-9011</meta:generator>
<meta:initial-creator>Jens Christian Damgaard</meta:initial-creator>
<meta:creation-date>2007-06-04T13:46:52</meta:creation-date>
<dc:creator>Jens Christian Damgaard</dc:creator>
<dc:date>2007-06-04T14:44:25</dc:date>
<dc:language>da-DK</dc:language>
<meta:editing-cycles>3</meta:editing-cycles>
<meta:editing-duration>PT21M28S</meta:editing-duration>
<meta:template xlink:type="simple" xlink:actuate="onRequest" xlink:role="template" xlink:href="/Z:/OpenOffice2/share/template/danish/Psykstandard/Uni-brevdk.ott" xlink:title="Uni-brevdk" meta:date="2007-06-04T13:46:51" />
[/code]
Hvis det svarer til jeres skabelon, så bruger jeg bare den. Jeg går ikke ud fra, at det er et problem, at jeg offentliggør PDF'er og original-fil her, vel? Jeg skal nok anonymisere filen, så der ikke er personhenførbare data i den.
Husk blot at det er vidt forskellige testdokumenter, og at det derfor ikke vil give mening at teste docx-filen overfor f.eks. odt-dokumentet "standardbrev"
Det er ikke en del af planen at lave en "OOXML vs ODF"-sammenligning på baggrund af jeres dokumenter. Jeg vil blot tage jeres dokumenter og lave en test af, hvordan de enkelte programmer identificeret ovenfor opfører sig.
:o)
Hej Jesper
Dokumentet stammer fra vores skabelon, så det kan du sagtens teste med. Hvis du vil teste med ODF ver. 1.2, åbner du bare dokumentet og gemmer i en ny version.
Jeg kan ikke sende dig vores skabelon, da den indeholder makrofunktionalitet der bl.a. trækker adresseoplysninger fra en central database. Dvs. den virker kun på vores netværk.
Det er OK at offentliggøre PDF-resultater hvis du skifter teksten ud. Odt-filen derimod kan ikke publiceres - det var en del af aftalen med ITST, da vi ville bidrage med virkelige dokumenter.
Hej Jens Christian,
(skulle du i øvrigt ikke holde ferie?)
:o)
Tak for dit svar,
Det er OK at offentliggøre PDF-resultater hvis du skifter teksten ud. Odt-filen derimod kan ikke publiceres - det var en del af aftalen med ITST, da vi ville bidrage med virkelige dokumenter.
Bare så jeg er helt sikker på, at vi forstår hinanden:
Jeg må gerne offentliggøre PDF-dokumenter fra mine tests - hvis jeg skifter teksten ud i de originale dokumenter med noget lorem-ipsum sjov.
Jeg må ikke offentliggøre ODT-skabelonen og ej heller DOCX-dokumentet.
Gælder det sidste også, hvis jeg udskifter indholdet i form af tekst og billeder i ODT/DOCX-filerne?
Tak - og god weekend herfra :o)
Hej Jesper,
Men derudover er det jo vigtigt at bemærke, at jeg ikke tester "document conformance" men derimod "document interop". De to ting er ikke nødvendigvis det samme.
Ja, det er jo lige det...
Hvad er det egentlig du tester?
For hvis du har applikation A, som gemmer dokumentformat X, som indlæses i applikation B, og resultatet ser herrens ud, hvor klog blev du så?
Var det applikation A der var dårlig til at gemme? Applikation B der var dårlig til at læse? Eller format X der bare var dårligt?
Endnu værre er det hvis din test går godt; thi du kunne jo have været heldig...
Så vidt jeg kan se, er du nødt til at teste til/fra alle fra/til alle, og selv der hvor det virker eller ikke virker, kan du ikke konkludere ret meget om selve formatet. Og hvis du ikke har formatet som absolut målestok, vil dine vurderinger af applikationerne også være arbitrære.
For hvad er det bedste? At være tilgivende overfor afvigelser fra dokumentstandarden, eller være stringent?
Jeg har virkelig fornemmelsen af at der sælges elastik i metermål med denne test.
Derudover er der hele det æstetiske aspekt, som jo ligger udenfor din test, samt informationsbærende layout - er det form eller indhold?
Det er egentlig hele HTML/browser-snakken om igen. Jeg kan derfor personligt ikke forvente nogen som helst form for endegyldigt resultat. Og hvad er testeriet så værd?
For hvad er det bedste? At være tilgivende overfor afvigelser fra dokumentstandarden, eller være stringent?
Den almene visdom er vistnok, at man skal være stringent, når man sender og tilgivende når man modtager.
Sålænge det kun er to applikationer, der testes, så er dine betragtninger om held gyldige.
Hvis der er flere i testen, og kun ét par falder i en bestemt kategori, så er der næppe tale om tilfældigheder.
Desuden ved jeg at JLS har indsigten og muligheden for at finde forklaringen på de negative udfald.
Jeg ser frem til at han deler med os
/esni
Off-topic: svar på svar på svar kan efterhånden føre et indlæg temmelig langt væk fra overskriften....
Hej Jesper
Bare så jeg er helt sikker på, at vi forstår hinanden: Jeg må gerne offentliggøre PDF-dokumenter fra mine tests - hvis jeg skifter teksten ud i de originale dokumenter med noget lorem-ipsum sjov.
Korrekt!
Jeg må ikke offentliggøre ODT-skabelonen og ej heller DOCX-dokumentet. Gælder det sidste også, hvis jeg udskifter indholdet i form af tekst og billeder i ODT/DOCX-filerne?
ODT-filerne må ikke offentliggøres, bla. pga. makrokode som ligger i filerne.
Docx-filen indeholder ingen makroer, så den må offentliggøres hvis tekst og billede er udskiftet.
(skulle du i øvrigt ikke holde ferie?)
Jo, og det lykkedes mig endda at være offline det meste af tiden :-)
ODT-filerne må ikke offentliggøres, bla. pga. makrokode som ligger i filerne. Docx-filen indeholder ingen makroer, så den må offentliggøres hvis tekst og billede er udskiftet.
Når vi ikke kan få ODT filen, så vil det være godt med dokumenterende billeder af, hvordan ODT filen ser ud, så vi visuelt kan sammenligne, hvor stor forskellen er.
Jeg ville lave noget flow chart i Draw og copy/paste det ind i Writer men fik følgende problem:
http://www.dump.no/files/115f49cf81a7/Untitled.png
Det er OpenOffice 3.1.1 (nyeste). Så måske kunne du udvide testen til at også at omfatte ODF vs. ODF...
Hej Lasse,
Jeg ville lave noget flow chart i Draw og copy/paste det ind i Writer men fik følgende problem: [link] Det er OpenOffice 3.1.1 (nyeste). Så måske kunne du udvide testen til at også at omfatte ODF vs. ODF...
Det forstår jeg ikke - med ODF burde interop da være nærmest sikret.
(btw)
Nu skal det jo ikke være sjov det hele, så du får lige en mulig forklaring:
Clipboard import/export-formatet i OOo og i øvrigt også i Microsoft Office er RTF, dvs ved klik på "CTRL+C" hhv "CTRL+V" sker der en eksport/import af det objekt, du har markeret i dokumentet. Objektet bliver derved omdannet til RTF-repræsentation, og dette RTF-indhold bliver ved "CTRL+V" parset af den modtagende applikation og konverteret til det "oprindelige" objekt.
Jeg vil derfor tro, at der er en bug i OOo's RTF import/eksport funktionalitet.
:o)
Jeg vil derfor tro, at der er en bug i OOo's RTF import/eksport funktionalitet.
Eller at det objekt der blev eksporteret af en eller anden grund ikke kunne gemmes korrekt i rtf formatet?
Hej Eskild,
Eller at det objekt der blev eksporteret af en eller anden grund ikke kunne gemmes korrekt i rtf formatet?
Præcist - men mig bekendt er der ikke meget, der ikke kan persisteres som RTF (det kunne være derfor både Microsoft Office og OOo bruger der), så derfor tror jeg ikke, at det er tilfældet.
Men det er klart, at hvis objektet ikke kan "komme ind i RTF", så er det svært at hente det ud igen.
:-)
Hej igen
Du må undskylde, men det er lige gået op for mig, at TextMaker 2008 ikke har fået indbygget understøttelse af Word 2007-filer: Det kommer først i TextMaker 2010.
Til gengæld kan man allerede nu teste SoftMakers DOCX-parser i den gratis viewer til Windows, som kan downloades her:
http://www.officeviewers.com/
Men den giver selvfølgelig ikke mulighed for redigering, hvorfor den nok falder uden for din undersøgelses scope.
Jeg beklager forvirringen!
Hej Jesper
Har uploadet et par eksempler på en docx-fil udskrevet fra henholdsvis Word 2003 og OpenOffice.org 3.11.
Jeg vil lade eksemplerne tale for sig selv.
docx-fil udskrevet fra MS Office 2003 og derefter scannet til PDF:
http://dump.no/files/3fe24ed34c1a/Word_2003_udskrift.pdf
docx-fil udskrevet fra OpenOffice.org 3.11 og derefter scannet til PDF:
http://dump.no/files/3fe24ed34c1a/OpenOffice_3.11_udskrift.pdf
Dokumentet:
http://dump.no/files/3fe24ed34c1a/ooxml-test.docx
Dokumentets indholdselementer svarer nogenlunde til den docx-fil du har fået fra ITST, dvs det er et typisk (og simpelt) tekstdokument.
Jeg har lige åbnet test dokumentet i seneste version af Abiword (2.6.8) og seneste version af Lotus Symphony (1.3), hvilket gav tilsvarende resultater som med OpenOffice.
Har uploadet et par eksempler på en docx-fil udskrevet fra henholdsvis Word 2003 og OpenOffice.org 3.11.
Så vil det jo være super interessant at se det samme dokument skabt i ODF og så åbnet, udskrevet og så siden scannet til PDF i de to office pakker.
Hej,
Jeg står med fornemmelsen af at dette er et replay af analyserne vi lavede i Dokumentformatprojektet?
http://www.itst.dk/regeringens-it-og-telepolitik/abne-standarder/vejledn...
Det var en glimrende arbejdsmetodik vi havde dengang - visuel validering af konverterings-kapabiliteten mellem de forskellige visnings-værktøjer (læs tekstbehandlingssoftware).
Jeg ser frme til PDF'er af resultaterne :-)
Gode hilsner
Jens Jakob
Jeg står med fornemmelsen af at dette er et replay af analyserne vi lavede i Dokumentformatprojektet?
Modenhed på markedet for de "nye" dokumentformater må selvsagt ændre sig over tid. Derfor er det interessant med et billede af hvordan det ser ud her 2 år efter. Måske var det en ide at ITST lavede en mere systematisk gentagelse af pilottesten fra 2007.
Modenheden i forhold til ODF har f.eks. ændret sig afgørende siden dengang.
Det var en glimrende arbejdsmetodik vi havde dengang - visuel validering af konverterings-kapabiliteten mellem de forskellige visnings-værktøjer (læs tekstbehandlingssoftware).
Helt enig.
Hej Jesper
Jeg har ikke lige fået læst op på, hvor langt du er kommet med ovenstående valideringsprojekt, men jeg kan oplyse om, at SoftMaker 2010 nu endelig er blevet frigivet, og at det kan downloades i en gratis prøve-udgave på nedenstående adresse:
http://softmaker.com/english/ofwdemo_en.htm
Det kunne være interessant at få SoftMaker Office 2010 med i testen, da det tilsyneladende understøtter såvel DOCX som XSLX.
mvh Kristoffer

