Arrêter Microsoft Word 2010 de lisser les captures d'écran?

Lorsque j'insère des captures d'écran JPEG dans Microsoft Word, il les lisse au lieu de conserver les pixels d'origine du bitmap. Lorsque j'imprime ensuite au format PDF (à l'aide d'Acrobat Distiller), en fonction de mes paramètres de sous-échantillon, j'obtiens des captures d'écran floues ou des tailles de fichier énormément gonflées.

Ce que je veux:

Je voudrais que Word et Acrobat laissent les bitmaps seuls pour qu'ils traversent le processus avec leurs pixels intacts. Voici à quoi ressemble l'image d'origine lorsque vous zoomez:

Ce que j'obtiens:

Voici à quoi ressemble le document Word lorsque vous insérez la même image et effectuez un zoom avant. Lorsqu'il est imprimé au format PDF, tous ces pixels supplémentaires donnent un fichier beaucoup plus volumineux.

Exemples de fichiers:

• Test.png (56K) Un exemple de fichier image de capture d'écran
• Test.docx (69K) Un fichier Word ne contenant que cette image
• Test.PDF (9.4MB) Un fichier PDF imprimé à partir du fichier Word à l'aide de Distiller, avec tout sous-échantillonnage désactivé
• Test2.PDF (98K) Un fichier PDF généré à l'aide de l'outil "Enregistrer au format PDF" de Word 2010 (notez la très faible qualité de l'image compressée)

Edit: C'est avec Word 2010 - J'ai mis à jour les balises pour refléter cela.

Edit: j'ai confirmé qu'OpenOffice n'a pas ce problème. J'ai ouvert Test.docx (référencé ci-dessus) et l'ai exporté en tant que PDF depuis OO (en choisissant "compression sans perte" sous Images dans les options), et l'image sort indemne.

• Test_OO.pdf

Malheureusement, OpenOffice modifie la mise en forme des documents Word plus complexes que j'ai créés; donc je ne peux pas simplement créer les documents dans Word et utiliser OO pour rendre les PDF; Je devrais passer complètement à OO, ce qui est une étape plus importante que celle que je suis prêt à franchir actuellement.

Word peut simplement restituer une image mise à l'échelle et l'envoyer de cette façon en tant qu'entrée d'imprimante (je suppose que Distiller fonctionne comme une imprimante). Si c'est le cas, c'est bon pour les imprimantes normales, mais inefficace pour les fausses imprimantes produisant des fichiers PDF.

Par exemple, pdfLaTeX incorpore correctement l'image dans le fichier de sortie. Vérifier mon PDF téléchargé dans la galerie min.us: Incorporation d'une image dans un document LaTeX

La chose importante est la pile de production de PDF que vous utilisez. Si essayer une autre imprimante PDF, comme PDFCreator génial et gratuit , ne résout pas le problème, vous devriez essayer d'utiliser l'exportation PDF dédiée, c'est-à-dire ne pas fonctionner comme imprimante. Les versions récentes d'AFAIK Word intègrent l'exportation PDF, donc si elle est correctement implémentée, vous obtiendrez un petit fichier, grâce à l'intégration des images utilisées dans le document.

ÉNORME ÉDITION

La galerie a été renommée Image d' incorporation PNG dans LaTeX vs Word

J'ai regardé de plus près mon mytest.pdfgénéré par pdfLaTeX et votre test2.pdfgénéré par Word.

mytest.pdf test2.pdf

Commençons par décompresser. Si vous regardez dans un fichier non compressé, vous repérerez facilement le début du flux d'image ( <<...>>streamligne avec les paramètres Largeur et Hauteur, comme dans test.png, c'est- à -dire 176x295), qui se termine par la endstreambalise. Coup d'œil.

(AVERTISSEMENT à ce stade, pdftk est supposé être dans la version 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

Par conséquent, Word donne JPEG au lieu de PNG sur sa sortie interne pour un traitement PDF ultérieur. Juste wow! La même chose peut se produire lors de l'envoi de la sortie vers l'imprimante.

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)

Ce n'est pas un fichier COM, mais ce n'est pas PNG non plus.

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

Tu le vois maintenant? Le flux d'images (de PNG) à partir de PDF produit par pdfLaTeX est peut-être un format brut simple (176 * 295 * 3 = 155760, 1 provient d'une nouvelle ligne superflue). Vérifions-le:

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

Et nous avons retrouvé notre image originale! Non attends. Il semble que la décompression de pdftk 1.41 soit boguée et l'image était presque la même avec quelques défauts. J'ai mis à niveau vers pdftk 1.44, mais cette version ne décompresse pas du tout le flux d'images. De plus, pdftk ne génère pas de dictionnaire de flux sur une seule ligne, donc l'extraction ci-dessus à l'aide de sed ne fonctionne plus, mais il n'y a aucun intérêt à le corriger maintenant.

Alors, que pouvons-nous faire à propos de Word? Pas grand-chose. Au moins, vous pouvez transplanter l'image intégrée d'un PDF à un autre. J'ai répété la décompression des deux PDF à l'aide de pdftk récent, les ai ouverts dans vim, remplacé test2uc.pdf <<...>>stream...endstreampar un équivalent de mytestuc.pdf, enregistré sous test2fixuc.pdfet compressé dans test2fix.pdf.

test2fix.pdf

test.pdf

Ce serait un péché de ne pas vérifier votre gros PDF après tout. Ok, j'ai préparé un autre oneliner pour jouer avec les PDF non compressés pdftk 1.44 pour lister les flux d'images et leurs premières lignes dans des fichiers. Je vais donc commencer par décompresser test.pdf.

(AVERTISSEMENT à ce stade, pdftk est supposé être dans la version 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

Quelque chose est vraiment fou ici! 6 images brutes (apparemment cette fois pdftk n'a eu aucun problème pour les décompresser) prenant ensemble 43444452 octets! Revérifions test2uc.pdfet 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

Dans les deux cas, un seul flux d'images. Pourquoi diable pourrait-il y en avoir plus?!

$ 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'image a été coupée en plusieurs morceaux ... Cela ressemble à une sorte de protection complètement stupide, peut-être introduite par Distiller (et peut-être qu'elle peut être désactivée)? Je doute que la même chose soit crachée par PDFCreator, à moins que ce ne soit Word qui exécute cette incroyable folie ...

testuc-stream1.png et autres (utilisez la flèche droite pour naviguer)

Conclusion

Les choses importantes sont:

• vous pouvez voir clairement que cette image énorme qui a été coupée en morceaux est en fait JPEG à l'échelle, donc mon hypothèse était correcte,
• parce que dans PDFCreator vous obtenez également un fichier énorme dans la sortie, c'est le Word qui fournit une image terriblement grande à la fausse imprimante PDF, et ma supposition précédente était également correcte.

Phew. Cette enquête a pris du temps. Le mot est un morceau d'ordure.

Solutions de contournement?

Entre-temps, quelques suggestions ont été faites. Permettez-moi de les commenter.

Utiliser un écrivain avec un support PDF décent comme LibreOffice (oubliez OpenOffice, il est obsolète maintenant) est une bonne solution, à moins que certaines incompabilités ne vous empêchent de travailler avec.

L'utilisation d'une image plus grande dans la même case sur la page n'est pas non plus une mauvaise idée, car même après le JPEG-izing, les artefacts seront moins visibles.

Mon autre grosz utilise cependant JPEG depuis le début. De cette façon, Word ne devrait pas le recompresser (on ne sait jamais ...) et vous pouvez fournir la meilleure qualité possible de JPEG. Il existe également une compression JPEG sans perte. Les développeurs de Redmond pensaient probablement que ce n'était pas nécessaire, donc je ne serai pas surpris si Word ne gère pas ces fichiers JPEG. Eh bien, TBH n'est pas largement pris en charge (même dans le monde open source), tout comme le codage arithmétique (ou c'est encore pire dans le cas du codage arithmétique).

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

(Sous Windows, utilisez 416 au lieu de cette $(())extension arithmétique disponible dans les shells POSIX)

Je pense que Mitchell par défaut est bon pour la mise à l'échelle, mais si vous voulez vraiment une telle image pixelatique, alors allez avec Box comme @ceving l'a suggéré. Bien sûr, les 2 premiers fichiers ne sont utiles que si vous devez (pour une raison quelconque) utiliser de fausses imprimantes PDF.

J'ai téléchargé les trois fichiers.

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

Si mon hypothèse est bonne et que Word ne recompressera pas l'image JPEG, utilisez simplement la dernière non mise à l'échelle et utilisez la sortie PDF intégrée, car elle a moins de lacunes (au moins, elle évite une mise à l'échelle inutile).

Ouvrez Fichier > Paramètres > Avancé , puis dans la section Taille et qualité d'image , cochez l'option Ne pas compresser les images dans les fichiers (Voir capture d'écran pour orienter où se trouve cette option)

L'image suivante est la même image JPG (capture de document 400% zoomée pour montrer la différence d'anti-aliasing) insérée avant et après l'activation de cette option:

Il semble que la fonction de zoom de Microsoft Word utilise un filtrage bilinéaire. Cela ne devrait pas changer l'image elle-même, mais uniquement la façon dont elle est affichée à des agrandissements autres que 100%. Ce que vous voulez, c'est la mise à l'échelle du plus proche voisin, mais je doute que MS Word ait une option pour cela.

J'ai répété la manipulation de l'insertion de Test.png dans un document dans Word 2007 et j'ai constaté à mon grand étonnement que le résultat dépend du mécanisme que l'on utilise.

Si l'on utilise Insérer / Image, l'image est lissée.
Mais si l'on entre dans un éditeur d'image et copie, puis le colle dans Word, l'image n'est pas lissée.

D'autres solutions possibles sont:

1. Essayez d'utiliser Collage spécial comme bitmap ou bitmap indépendant du périphérique.
2. Ne collez pas d'images. Utilisez l'onglet Encart / Groupe d'illustrations / Commande d'image et changez le bouton déroulant "Insérer" en "Lier au fichier". Le fichier image peut être optimisé pour que le Web prenne moins de place.

C'est probablement la solution la plus simple pour mettre à l'échelle les images originales à 300 dpi ou quelle que soit la résolution que vous utilisez lors de votre export PDF. Le programme de conversion d'ImageMagick peut le faire par exemple.

L'image originale a une largeur de 176 pixels. Si vous souhaitez le mettre à l'échelle à 4 pouces à 300 dpi, la largeur cible est de 1200 pixels. Cela le fera:

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

J'ai constaté qu'il vaut toujours mieux empêcher les produits Microsoft d'essayer de penser à ce qui pourrait être bon pour vous. Il vaut toujours mieux le décider par vous-même.

Cette question est similaire à celle-ci

Cela a à voir avec le style d'emballage ... réglez-le uniquement en haut et en bas. Lisez ici .

Corrigez-moi si ce commentaire est trop évident ou non pertinent:

Lorsque je colle une image nette, disons, d'une page de texte (j'ai testé .bmp et .png) dans un document Word 2010 (.docx), le résultat est une version floue de l'original. Cela est dû au redimensionnement automatique et au traitement d'image effectués par Word, apparemment indépendamment des paramètres pertinents dans "Options". Mais si je

1. sélectionnez l'image
2. allez à l'en-tête du ruban "Format"
3. sélectionnez la petite icône dans la zone la plus à gauche du ruban qui ressemble à une petite image avec une flèche "annuler"
4. déroulez le menu associé
5. sélectionnez l'élément inférieur appelé "Rétablir l'image et la taille" (c'était une traduction lâche de l'allemand),

puis l'image nette que j'ai collée réapparaît à la place de l'image floue.

Remarque: si j'utilise l'outil de photographie intégré dans Acrobat Reader, puis que je le colle directement dans Word, ce qui précède ne fonctionne pas. Je dois prendre une capture d'écran de tout l'écran ou passer par IrfanView.