Printjobs ganges med en faktor 15!! Hjælp til forståelse søges :-)

Alle printjobs bliver større, når det konverteres til printerens sprog... - det er uundgåeligt.

Jeg har set et eksempel for 8 år siden på en 12kb PDF fil, der endte med at fylde 2GB i spooleren - og da printserveren havde et ledigt drev på 3.5GB, og brugeren printede 2 eksemplarer, så.... :-)

Men det er iøvrigt kun de nyere printere der har 100MBit netinterface - alle lidt ældre printere kører 10MBit, da data normalt ikke fylder så meget, og derfor bliver overført med rigelig hastighed.

1. Størrelsen afhænger af datatype, programtype og drivertype.

2. Joda - du kan tvinge opløsningen i driveren ned til en lavere opløsning (dpi), men så forringer du samtidig kvaliteten af printet.

Så vidt jeg kender Lexmark C7xx serien, så forstår de både PCL og PostScript printersproget, så det er oplagt at forsøge at skifte til den anden drivertype....

Jeg kan på Lexmarks hjemmeside se, at det mest normale er at køre PCL versionen - det gør I sikkert også. Her er linket til den engelsksprogede PostScript Driver: http://support.lexmark.com/index?page=content&productCode=LEXMARK_C782&actp=RECOMMEND&id=DR20436&segment=DOWNLOAD&userlocale=DA_DK&oslocale=en_US&locale=da

hej Ole

Tak for svaret. Det gav en smule lys over problemet.

Jeg prøver dog alligevel at smide et (måske) mere konkret spørgsmål.

Vi har programmerne, som er vores ansvar.
Vi har printerne som er leverandør A's ansvar.
Vi har printserveren som er leverandør B's ansvar.

Spørgsmålet er så, hvor giver det mening at smide bolden hen. Er det printleverandøren (og leverandøren af driveren) der har det primære ansvar for at printet spooles i en fornuftig størrelse, eller er det printserveren der er hovedansvarlig?

Vi har samme problem uanset hvilket priogram der udskrives fra, så mit gæt er at vi med nogenlunde sikkerhed kan "frikende" programmerne, og altså klienterne.

Det ser dog ud som om at klienten sender 15 gange mere afsted end den originale fil fylder, så spørgsmålet er om spoolingen foregår lokalt... I så fald vil en lokal opgradering af printerdriveren måske kunne gøre noget?

Alt hvad du måtte have af teorier har interesse :-)

Tja, da størrelsen af spooljobbet er afhængig af hvilken applikationen og datatypen, er det jo faktisk i første omgang jeres eget ansvar...

Jeg tvivler voldsomt på at I altid har en faktor 15 udviddelse af dokumentet.

Prøv et notepad dokument (ren tekst) i forhold til et grafisk dokument.

Du kan også lege lidt med Excel - ren tekst i sort/hvid fylder langt mindre, end det øjeblik du lægger farver - og specielt rammer på.

Men for at teste med en anden printerdriver, er det printerserveren du skal have fat på - og altså "Leverandør B"´s ansvar.

Men hvis i mærker generelle lange svartider, ville jeg da også indkalde "Leverandør A" for at tjekke, om printernes netkort nu er konfigureret korrekt.

Jeg var for nogle år siden på en printer, der som sådan printede fint - der kunne bare gå 5-15 minutter fra man havde sendt printet af sted, til den begyndte at printe. Det viste sig, at printerens netkort havde en forkert "Default Gateway" sat ind, så rent kommunikationsmæssigt havde den svært ved at svare retur til serveren. Det kunne jo tænkes I havde noget af samme problem.

Endelig kan hastigheden være forårsaget af gamle forliste printerjobs på printserveren - her skal man finde det fysiske spoolerbibliotek og slette restfiler her (der skal være tomt, når der ikke ligger printjobs i kø). En simpel defragmentering af serveren ville heller ikke være af vejen, hvis den har nogle år på bagen...

Hej Ole

Jeg fik faktisk en del ud af dit indlæg, og vi har rent faktisk løst problemet ved at benytte os af en PostScript driver i stedet for PCL.

Smid et svar, så få du point :-)

Det lyder godt at I fik løst problemet :-)

Hermed svar...