Dear Ferran, I work on the multivio project especially on the server side, which do the pdf rendering.
Le 3 mai 2010 à 11:19, Ferran Jorba a écrit : > Hello Miguel, > > It certainly looks interesting! I've tested a couple of PDF files from > our site. The first one happened to weight 11 MB (an old scanned > journal, from http://ddd.uab.cat/record/53804), and it took so long that > I had to abort it: > > http://demo.multivio.org/client/#get&url=http://ddd.uab.cat/pub/garbanzo/garbanzo_a1873n47.pdf > > The second one, a modern native PDF (from http://ddd.uab.cat/record/5), > was sligtly better: > > http://demo.multivio.org/client/#get&url=http://ddd.uab.cat/pub/autonoma/autonoma_a2010m3n233.pdf > > I'd certainly choose Multivio instead of our Flash based equivalent (no, > it's no my fault, I give it to you so you can see a propietary > alternative): > > http://www.uab.es/revista-autonoma/ Concerning the fact that some pdfs can take while to be displayed on Multivio, this is mainly due to network problems at the server side. The external file should be downloaded on the multivio server, and it seems that we have some problem with our firewall. To avoid this, you can try multivio with local files with RERO DOC. For example: http://doc.rero.ch/record/18242?ln=fr (try the multivio button) or directly: http://demo.multivio.org/client/#get&url=http://doc.rero.ch/record/18242/export/xd However, we are working on a new prototype to make multivio more responsive. But as you can see, accessing very big files take only few seconds. The main idea is that only the information see by the user is downloaded. This is particularly useful for smart phone or GPRS/UMTS internet connexion. The fast web pdf is a part of the solution for big pdf files. At RERO, we have spécific collection such as "L'Impartial" which is a Swiss newpaper. That's represents Giga of data. For such cases, fast pdf is not really useful. Moreover, to search in a pdf or display the Table Of Content, a file should be completely downloaded. > > However, I'd say that the quality of the thumbnails can be improved. Do you mean the quality of the rendering? > Which tool are you using? In my case, I've found that, by far, the > fastest and best results are using a combination of Xpdf's pdftoppm and > Imagemagick's convert. We create the thumbnails of the first page of > our PDFs this way (simplified): > > $ pdftoppm -f $page -l $page $file.pdf $file > $ convert -thumbnail 85 $file-00000$page.ppm $file.png > $ rm $file-00000$page.ppm > > pdftoppm converts all pages to ppm if no -f or -l parameters are given. > Relying on ImageMagick's own PDF to PNG (or any other graphic format) > conversion, the route goes through Ghostscript, and it brings any system > to its knees, and the quality is worses. I use the same kind of tools: I use poppler and I did a python wrapper on the poppler classes to perform the rendering and PIL for the image manipulation. I do not want to have system calls. I know that the rendering is affected by the font configuration/installation on the linux distribution. I have to do some tests to obtain the best results. If you have some advise for that, do not hesitate. > Hope it helps, Course, all comments are welcome. Thanks again. > > Ferran -- Johnny
