On Sun, Oct 5, 2008 at 10:28 AM, Sayamindu Dasgupta <[EMAIL PROTECTED]> wrote: > On Sun, Oct 5, 2008 at 3:40 PM, S Page <[EMAIL PROTECTED]> wrote: >> Sayamindu Dasgupta wrote: >> >>> [lots of nifty plans for Read] >> >> That's great and undoubtedly worthwhile for legacy documents, but to quote >> Shakespeare, "I come to bury page representations like PDF, not request >> enhancements unto them". Nobody is contesting my argument that HTML in a >> browser whups PDF upside the head six ways to Sunday; therefore the aim of >> OLPC library advocates should be to get content as HTML (and encourage the >> advanced canvas, CSS, JavaScript and SVG that Browse/Firefox 3 supports), >> rather than making hundreds of thousands of kids who will never print from >> their XO look at "page representations". >> > > Agreed. However, there will always be PDF documents, especially in > languages with complex scripts (mainly because of legacy encoding > issues, very hackish fonts, no Unicode support for complex scripts in > authoring applications, etc). So what I'm trying to do is make sure > that we support PDFs as well as we can here :-). > >>> I am wondering if I can use the evince library that we are >>> shipping to implement a small and effiecient mozilla plugin, so that >>> the PDF can be directly viewed from within the Browser itself. >> >> That would indeed solve a lot of download-journal-launch issues, and maybe >> the OOM problem when zooming in Read (trac 7090 and 6002). As you probably >> know, the evince team's position is that rather than provide a plug-in, >> users should use mozplugger (http://mozplugger.mozdev.org/) to run the >> evince app within the browser. I tried `su -l; yum install mozplugger; yum >> install evince`, but evince wants to install dozens of other packages. >> I wonder when someone will write a PDF parser in JavaScript rendering to >> <canvas> or Cairo. >> > > Right now, I'm cooking up a stripped down PDF viewer which can be > invoked by mozplugger to view PDFs (and maybe save them to Journal - > dunno if that is possible right now). I have a basic pdf viewer > working inside Browse now (with security and everything enabled). > Expect more progress soon. > > With respect to the zoom problem, it seems to affect the Image Viewer > activity I wrote recently as well (as a result, I had to restrict zoom > to 400% in there) - if someone can do some profiling to figure out > what is going on, it would be great. >
Would it make sense to restrict zoom to a similar level in the read activity, at least for the time being? >>> Some backends which are experimental and are not >>> enabled in our builds include ones for impress files, dvi files, and >>> whatnot :-). >> >> Wiki pages like http://wiki.laptop.org/go/Image_file_formats say that DjVu >> is the best of these, and Chris Marshal on devel list cared about it. Every >> time I look at the samples at http://djvu.org/docs/ , either Browse or Read >> crashes unless I remember to zoom out (trac 6223). Interesting, but I would >> defer all such bugs until some deployment cares. >> > > I noticed some patches to Evince modifying the page caching mechanism > (right now Evince caches around 5 pages in memory, which is not good). > I'll figure out if those patches are already in our version of Evince > or not. > > Thanks, > Sayamindu > -- > Sayamindu Dasgupta > [http://sayamindu.randomink.org/ramblings] > _______________________________________________ > Library mailing list > [email protected] > http://lists.laptop.org/listinfo/library > _______________________________________________ Library mailing list [email protected] http://lists.laptop.org/listinfo/library
