Arrestare Microsoft Word 2010 dal livellare gli screenshot?

Quando inserisco schermate JPEG in Microsoft Word, le leviga invece di preservare i pixel originali dalla bitmap. Quando poi stampa su PDF (usando Acrobat Distiller), a seconda delle mie impostazioni di downsample, ottengo schermate sfocate o dimensioni di file enormemente gonfiate.

Quello che voglio:

Vorrei che Word e Acrobat lasciassero da sole le bitmap in modo che lo facessero attraverso il processo con i loro pixel intatti. Ecco come appare l'immagine originale quando si ingrandisce:

Cosa ottengo:

Ecco come appare il documento di Word quando si inserisce la stessa immagine e si ingrandisce. Quando questo viene stampato in PDF, tutti quei pixel extra generano un file molto più grande.

File di esempio:

• Test.png (56K) Un file di immagine di screenshot di esempio
• Test.docx (69K) Un file di Word contenente nient'altro che questa immagine
• Test.PDF ( 9.4MB ) Un file PDF stampato dal file Word usando Distiller, con tutti i downsampling disattivati
• Test2.PDF (98K) Un file PDF generato utilizzando lo strumento "Salva come PDF" di Word 2010 (notare la qualità molto bassa dell'immagine compressa)

Modifica: questo è con Word 2010 - ho aggiornato i tag per riflettere quello.

Modifica: ho confermato che OpenOffice non ha questo problema. Ho aperto Test.docx (di cui sopra) ed esportato come PDF da OO (scegliendo "Compressione senza perdita di dati" in Immagini nelle opzioni), e l'immagine risulta incolume.

• Test_OO.pdf

Sfortunatamente, OpenOffice manipola la formattazione su documenti Word più complessi che ho creato; quindi non posso semplicemente creare i documenti in Word e usare OO per rendere i PDF; Dovrei passare a OO del tutto, che è un passo più grande di quello che sono pronto a fare in questo momento.

Word forse rende solo l'immagine ingrandita e la invia in questo modo come input per la stampante (presumo che Distiller funzioni come una stampante). In tal caso, è utile per le normali stampanti, ma inefficiente per le stampanti false che producono file PDF.

Ad esempio pdfLaTeX incorpora correttamente l'immagine nel file di output. Controlla il mio PDF caricato nella galleria min.us: incorporamento dell'immagine nel documento LaTeX

La cosa importante è quale stack di produzione PDF stai utilizzando. Se provare altre stampanti PDF, come PDFCreator grande e gratuito , non risolve il problema, allora dovresti provare a utilizzare l'esportazione PDF dedicata, cioè non lavorare come stampante. Le versioni recenti di AFAIK Word hanno l'esportazione PDF integrata, quindi se è implementata correttamente, otterrai file di piccole dimensioni, grazie all'incorporamento delle immagini utilizzate nel documento.

MODIFICA ENORME

La galleria è stata rinominata in Incorporamento dell'immagine PNG in LaTeX vs Word

Ho esaminato più a fondo il mio mytest.pdfgenerato da pdfLaTeX e il tuo test2.pdfgenerato da Word.

mytest.pdf test2.pdf

Cominciamo con non comprimere. Se guardi un file non compresso, individuerai facilmente l'inizio del flusso di immagini ( <<...>>streamlinea con i parametri Larghezza e Altezza, lo stesso di in test.png, cioè 176x295), che termina con il endstreamtag. Tempo di sbirciatina.

(ATTENZIONE a questo punto si presuppone che pdftk sia nella versione 1.41)

test2.pdf

$ pdftk test2.pdf output test2uc.pdf uncompress
$ sed '\,^<</Width 176[^>]*/Height 295[^>]*>>stream$,!d' test2uc.pdf
<</Width 176/BitsPerComponent 8/Interpolate true/Height 295/Filter[/DCTDecode]/Subtype/Image/Length 20003/ColorSpace/DeviceRGB/Type/XObject>>stream
$ sed '1,\,^<</Width 176[^>]*/Height 295[^>]*>>stream$,d;/^endstream$/,$d' test2uc.pdf > test2stream
$ xxd test2stream | head -10
0000000: ffd8 ffe0 0010 4a46 4946 0001 0101 0048  ......JFIF.....H
0000010: 0048 0000 ffe1 005c 4578 6966 0000 4d4d  .H.....\Exif..MM
0000020: 002a 0000 0008 0004 0302 0002 0000 0016  .*..............
0000030: 0000 003e 5110 0001 0000 0001 0100 0000  ...>Q...........
0000040: 5111 0004 0000 0001 0000 0b13 5112 0004  Q...........Q...
0000050: 0000 0001 0000 0b13 0000 0000 5068 6f74  ............Phot
0000060: 6f73 686f 7020 4943 4320 7072 6f66 696c  oshop ICC profil
0000070: 6500 ffe2 0c58 4943 435f 5052 4f46 494c  e....XICC_PROFIL
0000080: 4500 0101 0000 0c48 4c69 6e6f 0210 0000  E......HLino....
0000090: 6d6e 7472 5247 4220 5859 5a20 07ce 0002  mntrRGB XYZ ....
$ file test2stream 
test2stream: JPEG image data, JFIF standard 1.01

Quindi Word fornisce JPEG anziché PNG sul suo output interno per un'ulteriore elaborazione PDF. Solo WOW! La stessa cosa può accadere quando si invia l'output alla stampante.

test2stream.jpg

mytest.pdf

$ pdftk mytest.pdf output mytestuc.pdf uncompress
$ sed '\,^<</Width 176[^>]*/Height 295[^>]*>>stream$,!d' mytestuc.pdf
<</Width 176/BitsPerComponent 8/Height 295/Subtype/Image/Length 155760/ColorSpace/DeviceRGB/Type/XObject>>stream
$ sed '1,\,^<</Width 176[^>]*/Height 295[^>]*>>stream$,d;/^endstream$/,$d' mytestuc.pdf > myteststream
$ xxd myteststream | head -10
0000000: ebeb ebea eaea ecec eceb ebeb ebeb ebeb  ................
0000010: ebeb ebeb ebec ecec ebeb ebeb ebeb ebeb  ................
0000020: ebeb ebeb ebeb ebeb ebeb ebeb ebeb ebeb  ................
0000030: ebeb ebea eaea eaea eaec ecec eaea eaec  ................
0000040: ecec ebeb ebec ecec ebeb ebeb ebeb ebeb  ................
0000050: ebeb ebeb ebeb ebeb ebeb ebeb ebeb ebeb  ................
0000060: ebeb ebeb ebeb ebeb ebeb ebeb ebeb ebeb  ................
0000070: ebeb ebeb ebeb ebeb ebeb ebeb ebeb ebeb  ................
0000080: ebea eaea ecec eceb ebeb ebeb ebea eaea  ................
0000090: ebeb ebeb ebeb ebeb ebeb ebeb ebeb ebeb  ................
$ file myteststream 
myteststream: DOS executable (COM)

Non è un file COM, ma non è nemmeno PNG.

$ du -b test.png test2stream myteststream 
57727   test.png
20004   test2stream
155761  myteststream

Lo vedi adesso? Il flusso di immagini (di PNG) da PDF prodotto da pdfLaTeX è probabilmente un semplice formato raw (176 * 295 * 3 = 155760, 1 proviene da una nuova riga superflua). Controlliamolo:

$ convert -depth 8 -size 176x295 rgb:myteststream myteststream.png

E abbiamo di nuovo la nostra immagine originale! Non aspettare. Sembra che la decompressione di pdftk 1.41 sia buggy e che l'immagine fosse quasi la stessa con qualche difetto. Ho aggiornato a pdftk 1.44, ma questa versione non decomprime affatto il flusso di immagini. Inoltre pdftk non emette il dizionario di flusso in una riga, quindi sopra l'estrazione usando sed non funziona più, ma non ha senso ripararlo ora.

Quindi cosa possiamo fare con Word? Non ci sono molti modi di pensare. Almeno è possibile trapiantare l'immagine incorporata da un PDF a un altro. Ho ripetuto la decompressione di entrambi i PDF utilizzando il recente pdftk, li ho aperti in vim, sostituiti test2uc.pdf <<...>>stream...endstreamcon la controparte da mytestuc.pdf, salvati come test2fixuc.pdfe compressi in test2fix.pdf.

test2fix.pdf

test.pdf

Dopo tutto, sarebbe un peccato non controllare il tuo grande PDF. Ok, ho preparato un altro oneliner per giocare con PDF non compressi pdftk 1.44 per elencare i flussi di immagini e le loro linee di partenza in file. Quindi inizierò con la decompressione test.pdf.

(ATTENZIONE a questo punto si presuppone che pdftk sia nella versione 1.44)

$ pdftk test.pdf output testuc.pdf uncompress
$ awk '{if(i)h=h$0} /^[0-9]+ [0-9]+ obj $/{i=1;h=""}/^stream$/{i=0;if(h!~/\/Image/)next;print h,":"NR+1}' testuc.pdf 
<</ColorSpace /DeviceRGB/Subtype /Image/Length 10443804/Width 707/Type /XObject/BitsPerComponent 8/Height 4924>>stream :619
<</ColorSpace /DeviceRGB/Subtype /Image/Length 11264460/Width 953/Type /XObject/BitsPerComponent 8/Height 3940>>stream :12106
<</ColorSpace /DeviceRGB/Subtype /Image/Length 2813256/Width 953/Type /XObject/BitsPerComponent 8/Height 984>>stream :12910
<</ColorSpace /DeviceRGB/Subtype /Image/Length 11264460/Width 953/Type /XObject/BitsPerComponent 8/Height 3940>>stream :18547
<</ColorSpace /DeviceRGB/Subtype /Image/Length 2813256/Width 953/Type /XObject/BitsPerComponent 8/Height 984>>stream :19312
<</ColorSpace /DeviceRGB/Subtype /Image/Length 4845216/Width 328/Type /XObject/BitsPerComponent 8/Height 4924>>stream :19326

Qualcosa è davvero folle qui! 6 immagini grezze (apparentemente questa volta pdftk non ha avuto problemi a decomprimerle) mettendo insieme 43444452 byte! Ricontrolliamo test2uc.pdfe mytestuc.pdf.

$ awk '{if(i)h=h$0} /^[0-9]+ [0-9]+ obj $/{i=1;h=""}/^stream$/{i=0;if(h!~/\/Image/)next;print h,":"NR+1}' test2uc.pdf 
<</Width 176/BitsPerComponent 8/Interpolate true/Height 295/Filter /DCTDecode/Subtype /Image/Length 20003/ColorSpace /DeviceRGB/Type /XObject>>stream :113
przemoc@debian:~/latex/test/img/mod$ awk '{if(i)h=h$0} /^[0-9]+ [0-9]+ obj $/{i=1;h=""}/^stream$/{i=0;if(h!~/\/Image/)next;print h,":"NR+1}' mytestuc.pdf 
<</DecodeParms <</Colors 3/Columns 176/Predictor 10/BitsPerComponent 8>>/Width 176/BitsPerComponent 8/Height 295/Filter /FlateDecode/Subtype /Image/Length 54954/ColorSpace /DeviceRGB/Type /XObject>>stream :22

In entrambi i casi, solo un flusso di immagini. Perché diamine potrebbe essercene di più ?!

$ sed '1,618d;/^endstream $/q' testuc.pdf | convert -depth 8 -size 707x4924 rgb:- testuc-stream1.png
$ sed '1,12105d;/^endstream $/q' testuc.pdf | convert -depth 8 -size 953x3940 rgb:- testuc-stream2.png
$ sed '1,12909d;/^endstream $/q' testuc.pdf | convert -depth 8 -size 953x984 rgb:- testuc-stream3.png
$ sed '1,18546d;/^endstream $/q' testuc.pdf | convert -depth 8 -size 953x3940 rgb:- testuc-stream4.png
$ sed '1,19311d;/^endstream $/q' testuc.pdf | convert -depth 8 -size 953x984 rgb:- testuc-stream5.png
$ sed '1,19325d;/^endstream $/q' testuc.pdf | convert -depth 8 -size 328x4924 rgb:- testuc-stream6.png

L'immagine è stata tagliata in molti pezzi ... Sembra una sorta di protezione assolutamente stupida, forse introdotta da Distiller (e forse può essere disattivata)? Dubito che la stessa cosa verrebbe sputata da PDFCreator, a meno che non sia Word a eseguire questa incredibile follia ...

testuc-stream1.png e altri (usa la freccia destra per navigare)

Conclusione

Le cose importanti sono:

• puoi vedere chiaramente che quell'enorme immagine che è stata tagliata a pezzi è in realtà JPEG ingrandito, quindi la mia ipotesi era corretta,
• perché in PDFCreator hai anche un enorme file nell'output, è la Parola che fornisce un'immagine terribilmente grande alla falsa stampante PDF, e anche la mia supposizione precedente era corretta.

Uff. Questa indagine ha richiesto del tempo. La parola è un pezzo di spazzatura.

Soluzioni alternative?

Nel frattempo sono stati dati alcuni suggerimenti. Lasciami commentarli.

L'uso di writer con un supporto PDF decente come LibreOffice (dimentica di OpenOffice, ora è obsoleto) è una buona soluzione, a meno che alcune incompatibilità non ti impediscano di lavorare con esso.

Anche usare un'immagine più grande nella stessa casella della pagina non è una cattiva idea, perché anche dopo il dimensionamento JPEG, gli artefatti saranno meno visibili.

Il mio altro grosz sta usando JPEG dall'inizio. In questo modo Word non dovrebbe ricomprimerlo (non lo sai mai ...) e puoi fornire la massima qualità possibile di JPEG. C'è anche una compressione JPEG senza perdita di dati. Gli sviluppatori di Redmond presumibilmente hanno pensato che non fosse necessario, quindi non sarei sorpreso se Word non gestisse tali JPEG. Bene, TBH non è ampiamente supportato (anche nel mondo open source), proprio come la codifica aritmetica (o è una situazione ancora peggiore in caso di codifica aritmetica).

convert test.png -quality 100 -resize $((100*300/72))% test-300dpi-mitchell.jpg
convert test.png -quality 100 -filter box -resize $((100*300/72))% test-300dpi-box.jpg
convert test.png -quality 100 test.jpg

(In Windows utilizzare 416 invece di questa $(())espansione aritmetica disponibile nelle shell POSIX)

Penso che Mitchell predefinito sia buono per l'upscaling, ma se vuoi davvero un'immagine pixelatica, vai con Box come suggerito da @ceving. Naturalmente i primi 2 file sono utili solo se è necessario (per qualche motivo) utilizzare stampanti PDF false.

Ho caricato tutti e tre i file.

test-300dpi-mitchell.jpg (426 KB) test-300dpi-box.jpg (581 KB) test.jpg (74 KB)

Se la mia ipotesi è corretta e Word non ricomprime l'immagine JPEG, usa solo l'ultimo non ingrandito e utilizza l'output PDF incorporato, perché ha meno carenze (almeno evita inutili upscale).

Apri File > Impostazioni > Avanzate , quindi nella sezione Dimensioni e qualità dell'immagine , seleziona l'opzione Non comprimere le immagini nei file (vedi acquisizione dello schermo per orientare dove si trova questa opzione)

L'immagine seguente è la stessa immagine JPG (acquisizione del documento ingrandita del 400% per mostrare la differenza di antialiasing) inserita prima e dopo l'attivazione di tale opzione:

Sembra che la funzione di zoom di Microsoft Word utilizzi il filtro bilineare. Questo non dovrebbe cambiare l'immagine stessa, ma solo come viene visualizzata con ingrandimenti diversi dal 100%. Quello che vuoi è il ridimensionamento del vicino più vicino, ma dubito che MS Word abbia un'opzione per questo.

Ho ripetuto la manipolazione dell'inserimento di Test.png in un documento in Word 2007 e ho scoperto con mio stupore che il risultato dipende dal meccanismo che si usa.

Se si utilizza Inserisci / Immagine, l'immagine viene smussata.
Ma se si entra in un editor di immagini e si copia, quindi si incolla in Word, quindi l'immagine non viene levigata.

Altre possibili soluzioni alternative sono:

1. Prova a utilizzare Incolla speciale come bitmap o bitmap indipendente dal dispositivo.
2. Non incollare le immagini. Utilizzare la scheda Inset / gruppo Illustrazioni / comando Immagine e modificare il pulsante a discesa "Inserisci" in "Collegamento al file". Il file di immagine può essere ottimizzato affinché il Web occupi meno spazio.

È probabilmente la soluzione più semplice per ridimensionare le immagini originali a 300 dpi o qualsiasi risoluzione si usi durante l'esportazione in PDF. Il programma di conversione di ImageMagick può farlo per esempio.

L'immagine originale ha una larghezza di 176 pixel. Se vuoi ridimensionarlo a 4 pollici a 300 dpi la larghezza target è di 1200 pixel. Questo lo farà:

convert test.png -filter Box -resize 1200 test_300dpi.png

Ho sperimentato che è sempre meglio impedire ai prodotti Microsoft di provare a pensare a ciò che potrebbe essere utile per te. È sempre meglio decidere da soli.

Questa domanda è simile a questa

Ha a che fare con lo stile di avvolgimento ... impostalo solo in alto e in basso. Leggi qui .

Correggimi se questo commento è troppo ovvio o non pertinente:

Quando incollo un'immagine nitida, per esempio, di una pagina di testo (ho testato .bmp e .png) in un documento di Word 2010 (.docx) il risultato è una versione sfocata dell'originale. Ciò è dovuto al ridimensionamento automatico e all'elaborazione delle immagini eseguiti da Word, apparentemente indipendentemente dalle impostazioni pertinenti in "Opzioni". Comunque se io allora

1. seleziona l'immagine
2. vai al nastro Intestazione "Formato"
3. seleziona la piccola icona nella parte più a sinistra della barra multifunzione che assomiglia a una piccola immagine con una freccia "annulla"
4. abbassa il menu associato
5. seleziona l'elemento in basso chiamato "Ripristina immagine e dimensioni" (che era una traduzione libera dal tedesco),

quindi l'immagine nitida che ho incollato riappare al posto di quella sfocata.

Nota: se uso lo strumento fotografico incorporato in Acrobat Reader, quindi incollo direttamente in Word, quanto sopra non funziona. Devo fare uno screenshot dell'intero schermo o passare tramite IrfanView.