Computer går i baglås når der printes fra open office

[soundpartner]

Jeg tror jeg kan forklare den opførsel.
Jeg aner ikke om dette stadigt gør sig gældende, men det kunne tyde på det.
I gamle dage arbejdede jeg en del med produktion af tryksager til cd-cowes og lignende, og havde derfor min vante gang ved nogle af disse snedige filmprintere der laver film til tryksager.
Der var det skruet således sammen at når man arbejdede med billede og tekst så arbejdede man wysiwyg. Det fungerede ved at man "importerede" billedet, og denne data blev indlejret i dokumentet MEN når man printer film så snakker vi en meget højere opløsning end hvad skærmen kan håndtere, så opløsning og farvedybte på skærmen (og altså det indlejrede billede) var ofte lavere end opløsningen på selve originalen.
På den måde så kunne vi arbejde med vores tryksag på en maskine, og filen incl billeder fyldte måske et par hundrede megabyte, men når vi skulle over til maskinen og printe, så skulle selve billedfilerne lige med i en mappe for sig.
printteknikkeren lavede så lidt magi og fik atached billederne til dokumentet igen, og kunne så printe.

som sagt så er dette på professionelt plan, og jeg ved ikke om det stadig fungerer således i praksis, men det ville give god mening at man generelt roder rundt med en cashed kopi af billedet på skærmen (jeg har her på denne skærm 1200 punkter på ca 20 cm hvilket er ca 150 dpi) men når så man printer så hiver den selve billedet ind igen for at få den optimale opløsning (min printer printer i 1200 dpi hvilket er ca 8 gange af hvad jeg har på skærmen)

hvor er sammenligningen så med din sag her? jo hvis nu der af en eller anden grund er sket en ændring af rettigheder på din fil eller en af de ovenliggende mapper, eller hvis der er sket noget med selve filen, så kan dette betyde at når du prøver at printe, så prøver maskinen at tilgå filen og løber ind i problemer. når du har lavet nye dokumenter så laver du jo et nyt og funktionelt link til filen, og dette vil derfor virke.

på professionelle systemer giver det mening at kunne arbejde med tingene "offline" og så kunne atache billederne senere hen, men til et produkt som en kontorpakke der vil sådanne funktionaliteter bare forvirre mere end det gavner.

Det er en mulig forklaring, og den forklarer netop de tilfælde hvor gamle dokumenter ikke virker, men det virker at lave et nyt dokument med præcis samme indhold.
Om det fungerer sådan i openoffice ved jeg som sagt ikke, men noget kunne tyde på det

[AJenbo]

Jeg hade selv overvejet noget af det samme, det glæder stadig når man arbejder med tryksager i de fleste layout programmer. Men i OpenOffice gør den det at den indlejre billedet som en base64 kode (MS Office gør noget i samme stil). Men det er da muligt at der er undtagelser, og at den ikke kommer med hensigtsmæssige advarsler (det gør layout programmer ikke altid).

[lath]

Jeg hade selv overvejet noget af det samme, det glæder stadig når man arbejder med tryksager i de fleste layout programmer. Men i OpenOffice gør den det at den indlejre billedet som en base64 kode (MS Office gør noget i samme stil). Men det er da muligt at der er undtagelser, og at den ikke kommer med hensigtsmæssige advarsler (det gør layout programmer ikke altid).

Det er nu ikke rigtigt at den base64 indkoder billedet.
Et gif billede er LZW (Lempel–Ziv–Welch) indkodet, og en *.odt fil og de andre Open Document Format fil-formater er i virkeligheden en zip fil med en speciel struktur[1].
Pakker man sådan en fil ud som en zip fil ud vil man kunne finde billedet i en billede mappe.

[1] http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1.odt [452 KB]

17. Packages

This chapter describes the package format that optionally can be used in OpenDocument. It contains the following sections:

• Introduction
• Zip File Structure
• Encryption
• Preview Image
• Manifest File
• Introduction

As XML has no native support for binary objects such as images, [OLE] objects, or other media types, and because uncompressed XML files can get very large, OpenDocument uses a package file to store the XML content of a document together with its associated binary data, and to optionally compress the XML content. This package is a standard Zip file, whose structure is discussed below.

Information about the files contained in the package is stored in an XML file called the manifest file. The manifest file is always stored at the pathname META-INF/manifest.xml. The main pieces of information stored in the manifest are as follows:

• A list of all of the files in the package.
• The media type of each file in the package.
• If a file stored in the package is encrypted, the information required to decrypt the file is stored in the manifest.

/Lars

[AJenbo]

Ups ja du har ret, måske er det et andet format jeg tænker på.

[lath]

This chapter describes the package format that optionally can be used in OpenDocument

Det lagde jeg ikke lige mærke til.

Som jeg husker det er der zip fil metoden som jeg referer herover og er "optionally", og den mest brugte af hvad jeg ved. Derudover er der så også at odt filer rent faktisk kan indkodes i en gigantisk stor XML fil. i sådan en stor XML fil vil billeder nødvendigvis være indkodet i noget der er tilladt for XML, og der er base64 vel et godt bud.

Store XML filer er bare noget rod: pakke ud fra base64 indkodet fil -> dekomprimere binære data fra udpakkede base64 data -> og så har vi noget man kan vise.

/Lars