[gull] Lecture de PDF google books sous linux

Tue Mar 24 22:49:13 CET 2009

Salut Félix,

Merci beaucoup pour toutes ces recherches ! J'ai appris tout plein de choses sur les commandes liées au pdf...

A l'origine, la solution était destinée à ma copine (non-informaticienne) qui commence à oublier Windows pour le remplacer par linux. Je lui laisse donc la solution d'Adobe (moins élégante parce que non libre mais plus pratique pour une nouvelle adhérente à linux) et je garde pour moi la solution de Félix !

A la prochaine,

Samuel

----- Message d'origine ----
> De : Félix Hauri <felix at f-hauri.ch>
> À : "Gull, liste de discussion" <gull at government.linux-gull.ch>
> Envoyé le : Mardi, 24 Mars 2009, 8h46mn 15s
> Objet : Re: [gull] Lecture de PDF google books sous linux
> 
> Bonjour,
> 
> Tout d'abord, désolé pour la réponse sur le tard, mais
> pour manipuler et tester un fichier de 560 pages, j'ai utilisé
> des nuits. (lancer la commande... voir au petit matin, la durée
> et le résultat)...
> 
> On Fri, Mar 20, 2009 at 04:05:42AM -0700, Samuel Chenal wrote:
> > 
> > Hello,
> > 
> > 
> > Sur le pdf, la page correspondante est la 15. La gravure en bas de la 
> > page n'apparaît pas.
> Ok, vu! (Sans Windows! et sous Debian;)
> 
> > Le test a été effectué sur :
> > 
> > - Ubuntu 8.10 avec evince et xpdf.
> > - Kubuntu 8.04 avec kpdf et KGhostView.
> Etrange!
> 
> > Mêmes résultats avec evince, kpdf et xpdf. Le fichier n'est pas lisible 
> > sous KGhostView.
> Là, par contre, c'est normal:
> 
> evince, kpdf et xpdf utilisent tous le même ``moteur'' postscript.
> (Je suis plus étonné en ce qui concerne KGhostView, mais comme
> je n'utilise pas KDE, je ne sais pas trop de quoi il s'agit)
> En gros, on trouve essentiellement 2 moteurs postscript distincts
> sur une distrib linux standard: xpdf et ghostscript.
> Xpdf est rapide et spécialisé dans le traitement pdf.
> Ghostscript et le moteur d'impression qu'utilise entre autres cups.
> 
> Mes premiers tests sous xpdf m'ont permis de constater que la page
> 15 contient une zone blanche importante en bas de page.
> 
> J'ai donc lancé ghostscript via GV (voire ggv) mais le programme
> semblait planté.
> 
> J'ai alors lancé ghostscript en ligne de commande dans un terminal:
> $ gs La_figure_de_la_terre.pdf
> AFPL Ghostscript 8.53 (2005-10-20)
> ...
> >>showpage, press to continue<<
> 
> 14x ``return'', pour observer la page 15. Ai pu alors constater
> qu'une gravure figure effectivement sur cette page.
> 
> J'ai tenté de lancer simplement
> $ pdf2ps La_figure_de_la_terre.pdf
> mais là, après une bonne dizaine de minutes:
> Segmentation fault
> Il a pondu un fichier de 1.3Go pour 89 pages (sur 560), mais
> les gravures y sont présentes.
> 
> J'ai alors lancé la commande suivante:
> $ file=La_figure_de_la_terre
> $ gs -sDEVICE=pswrite -dNOPAUSE -dBATCH -dSAFER -sOutputFile=${file}_p%04d.ps 
> ${file}.pdf -c quit
> 
> Vingt minutes plus tard (et 1.3Go), à nouveau
> Segmentation fault
> J'insiste:
> $ gs -sDEVICE=pswrite -dNOPAUSE -dBATCH -dSAFER -dFirstPage=88 
> -sOutputFile=${file}_q%04d.ps ${file}.pdf -c quit
> 
> Les pages 88 et 89 sont très rapides, je compare:
> $ diff ${file}_p0088.ps ${file}_q0001.ps
> 7c7
> < %%CreationDate: 2009/03/21 21:34:48
> ---
> > %%CreationDate: 2009/03/21 21:41:56
> 60c60
> < %%Page: 88 1
> ---
> > %%Page: 1 1
> 
> Il sont ``identiques''!
> 
> ....
> Il s'est re-planté à la page 175...
> Je peux relancer la commande précédente en changeant le 88 pour 174 et
> le ``q'' par un ``r'', afin de
> - pouvoir comparer 2 pages pour supprimer les doublons
> - pouvoir les repasser dans un filtres, si nécessaire,
>    l'ordre alphabetique respectera l'ordre des pages
>    (q_0002 vient apres p_0088 ainsi que r_0002 suit q_0086)
> 
> Bref, à partir de là, je peux dire:
> Ces fichier sont difficiles à digérer si tu ne dispose pas d'un moteur
> récent, de préférence adobe (quoique, sur ma version 5, il n'y a pas 
> de gravures non plus;).
> 
> Une petite pause supplémentaire sera nécessaire pour recréer un pdf:
> $ gs -sDEVICE=pdfwrite -dNOPAUSE -dBATCH -dSAFER -sOutputFile=${file}b.pdf 
> ${file}*.ps -c quit
> (compter une bonne heure...)
> mais au final, on obtiens un fichier pdf lisible avec un peu n'importe
> quel viewer... 
> (... capable de manipuler un fichier de 560 pages et 1.2Go:~2Mo/page)
> 
> La vitesse d'execution (et le nombre de pages avant plantage) dépend
> des ressources disponibles
> Je l'ai fait sans ``fault'' sur une version identique de GS,
> sur une machine pourvue de 5Go de RAM, la mienne n'en à ``que'' 1.
> en presqu'une heure pour un resultat pesant ~5.5Go )
> 
> Maintenant, voici une solution sous bash qui marche,
> (pas vite, mais qui marche;)
> $ for ((i=1;i<561;i++));do gs -r1000 -sDEVICE=pnmraw -q \
>     -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -dNOPAUSE -dBATCH -dSAFER \
>     -dFirstPage=$i -dLastPage=$i -sOutputFile=- ${file}.pdf -c quit |
>     pnmscale .2 |
>     if [ $i -lt 7 ] || [ $i -gt 557 ];then
>      cat;
>       else
>          ppmtopgm ;
>       fi | 
>     pnmtops -eq -dpi 200 >$(printf "${file}-%04d.ps" $i) 2>/dev/null;
>     done
> $ cat ${file}-*.ps | ps2pdf - ${file}2.pdf
> 
> Cela à pris environ 3 heures à ma machine, mais au final, j'obtiens
> un fichiers de 165Mo, avec mes 560 pages dont les pages 1-6 et 558-560
> en couleurs.
> 
> Le final pèse environ 6x plus que l'original, mais il est nettement
> plus digeste! S'affiche sur *tous* mes viewers et rapidement!
> 
> > Merci d'avance pour vos éclairages ! Et dites-moi si vous observez le 
> > même problème chez vous avec votre configuration.
> Si tu as bcp de bouquins à manipuler, échanger, imprimer (partiellement)
> etc, alors cela vaudrait peut-être la peine de systématiser la méthode
> (en faire un script)
> 
> --
> Félix Hauri  -    -  http://www.f-hauri.ch
> _______________________________________________
> gull mailing list
> gull at forum.linux-gull.ch
> http://forum.linux-gull.ch/mailman/listinfo/gull