Tuto dt

[JacoTux]

@ Irek
> Sous Linux une bonne vielle ligne de commande
Alors là, chapeau bas.
Je suis sous Linux depuis la fin des années 90 et je suis passé à coté de cette commande !
Comme quoi on en apprend tous les jours et qu'il y en a toujours à apprendre.

> D'ailleurs à mon travail, pour réduire la taille de documents qu'on produit, on a imposé...
Itou, certains exagéraient avec des documents issus d'images pour illustrer leur propos

---

@ JMM40
> Mais malheureusement, j'ai bien peur que les débutants ne puissent pas lire dans les images,

Oui j'y avais aussi regardé, pour moi dans qpdfview en pleine largeur de page ça reste lisible, limite toutefois... ma j'ai un écran 25"
Et j'étais justement en train de me renseigner sur cette belle commande CLI, je crains qu'il n'y ait pas d'intermédiaire à 200 DPI... qui serait peut-être insuffisante pour 2 Mio

Code :

-dPDFSETTINGS=/screen   (screen-view-only quality, 72 dpi images)
-dPDFSETTINGS=/ebook    (low quality, 150 dpi images)
-dPDFSETTINGS=/printer  (high quality, 300 dpi images)
-dPDFSETTINGS=/prepress (high quality, color preserving, 300 dpi imgs)
-dPDFSETTINGS=/default  (almost identical to /screen)

[Irek]

Oui j'y avais aussi regardé, pour moi dans qpdfview en pleine largeur de page ça reste lisible, limite toutefois... ma j'ai un écran 25"
Et j'étais justement en train de me renseigner sur cette belle commande CLI, je crains qu'il n'y ait pas d'intermédiaire à 200 DPI... qui serait peut-être insuffisante pour 2 Mio

Tu as jamais utilisé le format .ps (PostScript, bien avant .pdf) ? gs c'est le couteau suisse de PS. Après bon, depuis les lustres, j'ai tout oublié, j'ai juste cette commande qui me sauve la vie parfois quand je scanne qqs pages.

Exact, je sais pas non plus s'il y a un intermédiaire...
C'est pour ça la solution "pas trop mauvaise" est d'utiliser la bonne taille d'images dès le début...

---

Bonjour Irek
Mais malheureusement, j'ai bien peur que les débutants ne puissent pas lire dans les images, il manque un peu de définition, j'ai regardé à diverses échelles et si l'on ne connaît pas d'avance les texte des modules impossible de s'y retrouver, désolé.

Il ne manque pas grand chose, mais je ne pense pas que l'on puisse faire un tel dossier lisible avec une taille de 2 Mo. Il va falloir je pense le faire en deux parties à mon avis. Attendons d'autres avis. 

C'est vrai, il manque un peu de définition...

Non, 2 Mo c'est clairement pas assez pour autant d'images avec autant de détails !

[nicoauffray]

https://covid19.framadrop.org/lufi/r/QGD...wG1gReDH8c

J'y arrive avec celui-là

@Hgmarty : tu as mis quel format/résolution à tes images avant de les mettre dans le PDF ? A mon avis, elles mériteraient d'être optimisées à l'origine (avant introduction dans ton PDF. Parce qu'en effet, le PDF à moins de 2Mo fait que les images deviennent dégueu alors qu'elles font hyper nettes à l'origine.

A plus de 2 Mo, on ne peut pas l'ajouter. Le seul moyen à plus de 2 Mo serait de s'assurer d'un lien permanent externe à darktable.fr. Pour info, le manuel de darktable (avec bien plus d'images et de pages, ne fait que 3 mo de plus ; il est situé sur le dépôt officiel darktable).

[Irek]

La toute meilleure solution serait de de séparer les photos et les images d'interface graphique quand c'est possible:

• Les images, on les met en largeur 1500 px (ou même 1200 px) compressées en JPG
  
• Les éléments d'interface (boite de dialogues, etc), on le compresse en PNG
  

Oui, je sais, c'est le boulot énorme...

[jpg54]

Je viens de regarder le premier PDF, je peux récupérer les copies d'image dans leur taille initiale. Je regarde avec le dernier si c'est aussi possible,
Si c'est possible avec le dernier, je vais les redimensionner et exporter dans plus petite taille compatible avec leur lisibilité dans un PDF.

[JacoTux]

Je regardais avec LibreOffice si ça pouvait le faire rapidement (Ben oui Irek, on devient vite fainéant, et les interfaces graphiques ont progressivement mis au rebus quantité des commandes en console de mes débuts sur Linux.)
En quelques images redimensionnées, je descends déjà de 40 % en re-export mais il faut trouver le bon compromis en partant des captures de base.

---

@ jpg54

Le blog est propulsé par WordPress, ce n'est pas lui qui limite probablement l'hébergement, mais 2 Mo ça commence à devenir peau de chagrin.
C'était souvent le cas, j'avais cette contrainte sur un site Spip en upload directe chez l'hébergeur, sauf à aller déposer les fichiers en FTP dans les dossiers idoines.
Il n'y aurait pas un contournement possible ?

[nicoauffray]

Le blog est propulsé par WordPress, ce n'est pas lui qui limite probablement l'hébergement, mais 2 Mo ça commence à devenir peau de chagrin.
C'était souvent le cas, j'avais cette contrainte sur un site Spip en upload directe chez l'hébergeur, sauf à aller déposer les fichiers en FTP dans les dossiers idoines.
Il n'y aurait pas un contournement possible ?

Je me permets de te répondre. La seule solution simple serait de simplement faire un lien de téléchargement vers un dépôt externe qui n'a pas cette limite (comme pour le manuel) mais il faudrait s'assurer d'un dépôt externe durable.

Pour ce qui est du blog en lui-même et cette limite, il n'y a qu'une administrateur qui pourrait répondre, et donc surtout Andy Costanza.

[JacoTux]

> La seule solution simple serait de simplement faire un lien de téléchargement vers un dépôt externe qui n'a pas cette limite.
Oui c'est sûr, mais si l'on commence à éparpiller à droite ou à gauche les documents et autres ressources liées à DT sur des liens personnels ce n'est pas forcément une bonne idée... ça me rappelle furieusement le packaging façon debian et ces foutus PPA qui ont finis par me rendre chèvre, surtout quant-on a quelques applis exotiques, c'est gentil la compilation maison mais pendant ce temps là on ne produit pas.

Un dépôt externe lié au blog serait l'idéal... évidemment géré par les admins.
Ou alors
Soit il faut le scinder intelligemment en deux parties, jusqu'à chambre noire par exemple... comme le proposait  l'un d'entre nous.
Soit il faut trouver la bonne dimension, définition des captures écran à insérer au documents, Irek a donné quelques pistes.

[Hgmarty]

Bonsoir,

tout cela, j'essaie en même temps.

Les images sont des screenshots de gnome, soit 1920*1200 px je ne pensais pas que cela serait une contrainte, mais c'est vrai que c'est quand même important vu le temps que je mets à uploader.
Mon dossier fait avec les tailles actuelles 12.7Mo, en baissant à 1200 de largeur et 80 de quality, j'arrive à 4Mo soit la taille grosso modo du pdf qui est encore lisible. En le compressant en xz, cela devient un fichier de 3.2Mo.

Si on baisse à 1000 px de large, ca fait un pdf de 2.8 et compressé à 2.2 Mo mais la qualité commence à être passable.
J'ai fait pas mal d'essais, peu de choses sont concluants pour garder une visibilité correcte et un poids réduit du pdf.

De plus le template fait des siennes et met des images en petit mais aussi clair que les autres en agrandissant. (j'ai mes fichiers markdown et mes images et op pandoc fait tout seul le reste)

Suis ouvert à vos propositions.

[jpg54]

Je suis en train de réduire avec LibreOffice. J'ai essayé la méthode de @Irek quelques copies d'écran qui sont difficilement peu lisibles. Je pense qu'il faut au moins dimensionner les copies d'écran et si l'on peut le mettre en téléchargement sur un site permanent.