Ticket #2448 (closed enhancement: fixed)

Opened 7 years ago

Last modified 6 years ago

Xbook needs djvu-libre support; Read activity should support djvu in a STABLE build

Reported by: sj Owned by: dgilmore
Priority: high Milestone: Not Triaged
Component: read-activity Version:
Keywords: Cc: sj, tomeu, dgilmore, manu, marco, coderanger, walter
Action Needed: never set Verified: no
Deployments affected: Blocked By:
Blocking:

Description (last modified by jg) (diff)

Evince supports djvu, among other formats; this was removed from xbook, presumably to keep it small, but it would be very useful. among other things, it will let people access much smaller scan-sets of printed texts.

A brief email thread follows. Luke Hutchison is at Google this summer working on books, and trying to help out with accessing and reading feeds of books and metadata; some collections are primarily in djvu.

Related to bug #2839

On Tue, 2007-07-24 at 12:49 +0200, Tomeu Vizoso wrote:

On Tue, 2007-07-24 at 03:36 -0700, Luke Hutchison wrote:

PS anyone know why xbook doesn't support djvu-libre, when evince does? A lot of public domain scanned books are available in deja vu format.

Evince needs to be compiled with dejavu support. I think it's only that.

Attachments

djvulibre.spec (8.5 kB) - added by coderanger 7 years ago.

Change History

  Changed 7 years ago by jg

  • cc sj added
  • type changed from defect to enhancement
  • milestone changed from Untriaged to Trial-3

sj, you know the drill by now, or should:

1) what are the dependencies? 2) what are the sizes of the dependencies? 3) candidates of where we get the space (there's lots of fat to trim; and you should help find it...).

  Changed 7 years ago by HoboPrimate

In Kubuntu, for evince to support djvu, it needs the package libdjvulibre15 (2302k unpacked), which itself depends on JPEG library (197k unpacked but that's probably already part of the base system, I assume).

  Changed 7 years ago by sj

Marco killed mime type detection in evince-olpc a while back not for size of support for individual formats, but because detection was using gnome-vfs. Now that we're shipping gnome-vfs, we should be able to add real detection back in...

  Changed 7 years ago by tomeu

  • milestone changed from Trial-3 to Untriaged

  Changed 7 years ago by jg

  • description modified (diff)
  • milestone changed from Untriaged to First Deployment, V1.0

  Changed 7 years ago by tomeu

  • milestone changed from First Deployment, V1.0 to Untriaged

Don't think I'll be able to work on this for FRS unless it gets higher priority from Jim or Kim.

If someone gives it a try, please add also support for gdkpixbuf and update #2839.

  Changed 7 years ago by jg

  • milestone changed from Untriaged to V1.1

  Changed 7 years ago by tomeu

  • cc tomeu added
  • component changed from distro to read-activity

Simon is updating evince.

  Changed 7 years ago by tomeu

  • owner changed from tomeu to erikos

  Changed 7 years ago by tomeu

  • owner changed from erikos to rwh

Sorry, I wanted to move it to Reinier, not Simon.

  Changed 7 years ago by rwh

Easy to do, but the current djvu-libre package depends on QT (3.5MB), which is unacceptable now. Perhaps this can be rebuilt without this dependency.

  Changed 7 years ago by tomeu

  • cc dgilmore, manu, marco added

Marco has looked into it and looks to be just a matter of rebuilding djvulibre without the qt dependency (see attached spec file) and rebuild evince with djvu support.

If this is needed for update.1, then we should put it into the builds ASAP.

Manu, can you talk to whoever is needed so we know if this really needs to get into update.1? I guess Dennis can rebuild djvulibre and evince afterwards?

  Changed 7 years ago by marco

  • cc coderanger added

Here is the spec, trac does not let me attach it:

http://dev.laptop.org/~marco/djvulibre.spec

Changed 7 years ago by coderanger

  Changed 7 years ago by sj

This is great news; thank you. This saves us around 60% of used disk space for high-quality pdfs that really make use of the screen's resolution; including entire collections kept by the internet archive.

  Changed 7 years ago by manu

  • cc walter added

Dennis, Could you please branch the module and make Marco its owner.

SJ, I remember you wanted to test certain files in djvu format. Kindly email them to me.

  Changed 7 years ago by marco

  • owner changed from rwh to dgilmore

follow-up: ↓ 18   Changed 7 years ago by sj

  • priority changed from normal to high

An update, also made to #6223:

A full-color DJVU is about 20% smaller than a black-and-white PDF of the same document, and is TEN TIMES faster to render pages. This makes it possible to actually load and read a normal-length book, which is currently completely unusable with xbook.

As a result of this flaw in the current Read implementation, few people are using it for serious book reading anyway; as this change imposes small changes in executed codepaths and should not impact packages outside of Read, I hope it will be considered for testing with an update.1 build.

in reply to: ↑ 17   Changed 7 years ago by tomeu

Replying to sj:

As a result of this flaw in the current Read implementation, few people are using it for serious book reading anyway; as this change imposes small changes in executed codepaths and should not impact packages outside of Read, I hope it will be considered for testing with an update.1 build.

Not discussing the convenience of adding djvu to any milestone, but I'm interested in knowing more details about the current Read being unsuitable for serious book reading. Is it only for performance reasons? Can you give some examples? Also, what do you consider "serious book reading"?

  Changed 7 years ago by kimquirk

  • milestone changed from Future Release to Update.2

From the simple perspective that this is not blocking or critical to Update.1, I don't believe there is anything reason to get the testing and documentation done on this. We passed feature freeze and code freeze, so we are only considering triaged blocking bugs for Update.1 at this time. Since it has started to get testing by being in joyride, then I believe it is a good candidate for Update.2.

Moving to Update.2.

  Changed 7 years ago by marco

  • status changed from new to closed
  • resolution set to duplicate

Looks like a dup of #6223

follow-up: ↓ 23   Changed 7 years ago by tomeu

  • status changed from closed to reopened
  • resolution deleted

Well, I think that this is about adding support to Read for reading djvu files, and #6223 is about making sugar (clipboard and journal) show a more meaningful representation of djvu files. Right now is showing those as unknown objects, I think.

As we already have working djvu support in joyride, I think this can be closed as fixed.

  Changed 7 years ago by tomeu

  • status changed from reopened to closed
  • resolution set to fixed

in reply to: ↑ 21 ; follow-ups: ↓ 24 ↓ 25   Changed 6 years ago by docdtv

  • status changed from closed to reopened
  • summary changed from Xbook needs djvu-libre support to Xbook needs djvu-libre support; Read activity should support djvu in a STABLE build
  • resolution deleted
  • milestone changed from Update.2 to Retriage, Please!

Replying to tomeu:

Well, I think that this is about adding support to Read for reading djvu files, and #6223 is about making sugar (clipboard and journal) show a more meaningful representation of djvu files. Right now is showing those as unknown objects, I think. As we already have working djvu support in joyride, I think this can be closed as fixed.

Huh? But I thought "joyride" was an "unstable" family of builds! Does this mean an official build will never support reading Djvu files via the Read activity? That sounds like TERRIBLE news to me; I think the impact of the e-book reader role for XO hasn't gotten the respect it deserves, given typical pedagogical culture.

By the way, I am clueless where non-official builds are archived online; URL please?

-

in reply to: ↑ 23   Changed 6 years ago by marco

Replying to docdtv:

Huh? But I thought "joyride" was an "unstable" family of builds! Does this mean an official build will never support reading Djvu files via the Read activity?

Nope, the feature missed Update.1 (I think) but it will certainly be in Update.2.

in reply to: ↑ 23   Changed 6 years ago by docdtv

Replying to docdtv:

Replying to tomeu:

Well, I think that this is about adding support to Read for reading djvu files, and #6223 is about making sugar (clipboard and journal) show a more meaningful representation of djvu files. Right now is showing those as unknown objects, I think. As we already have working djvu support in joyride, I think this can be closed as fixed.

Huh? But I thought "joyride" was an "unstable" family of builds! Does this mean an official build will never support reading Djvu files via the Read activity? That sounds like TERRIBLE news to me; I think the impact of the e-book reader role for XO hasn't gotten the respect it deserves, given typical pedagogical culture. By the way, I am clueless where non-official builds are archived online; URL please? -

I am finding my way around (the hint I needed was found at http://wiki.laptop.org/go/Joyride#Output_from_the_Build_System ) One can find the Joyride build (1790) supporting Djvu via the Read activity at: http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1790/devel_jffs2/

-

  Changed 6 years ago by marco

  • status changed from reopened to closed
  • next_action set to never set
  • resolution set to fixed

I think this is fixed.

  Changed 6 years ago by sj

The latest updates on this are at #6223.

Note: See TracTickets for help on using tickets.