> But that all sounds like PDF so far. PDFs need to be linearized to > support random page access, but that's easy and can be done with free > tools.
Unfortunately, linearized PDFs do not actually facilitate true random access. The linearized format puts the index and all objects required to produce the first page at the beginning of the file. The entire file continues to download, page-by-page, while the user can make use of any content that has already been downloaded. It's a better user experience, for sure, but not ideal. If, for example, you want to view the last page of a file, you will have to wait for the entire file to download. For a PDF of a book, consisting of hundreds (or thousands) of scanned images, this can represent a significant investment, in both user time, and bandwidth. > I feel that this stuff belongs in the browser. I think you're right, however, you will continue to run into this general problem: the user will be challenged by the size of the object you are attempting to give them. As it increases, usability decreases. There are ways around this, currently: you either convert the objects to a format that can be streamed, or you break the objects into smaller parts (the traditional "page turning" approach employed by digital libraries). --Hardy > -----Original Message----- > From: Mark H. Wood [mailto:mw...@iupui.edu] > Sent: Thursday, January 06, 2011 11:37 AM > To: dspace-tech@lists.sourceforge.net > Subject: Re: [Dspace-tech] Online Document Viewer Functionality > > On Wed, Jan 05, 2011 at 01:41:32PM -0600, Pottinger, Hardy J. wrote: > > > I guess I don't understand the problem. I thought we called that a > > > web browser. It either says, "oh, I know how to show that" and does > > > it, or "ah, you use Adobe Reader/OpenOffice/VLC/JMol/whatever for > those, > > > I'll fire it up." > > > > Hi, Mark, that approach works great for born-digital materials, and > for anything that will load in a browser within a reasonable span of > time. As the size of the object you are storing grows, you reach a point > where downloading the entire object before you can use it becomes a > problem. Additionally, if the content you are storing has previously > been presented in way that provides instant access--say, in this case, a > page turner in a digital library--users would have certain expectations > of any future presentation of that material. They don't really care all > that much about how the material is stored, but they care a great deal > if the content isn't available with the same, or similar, level of > usability. > > OK, that's a problem. > > But that all sounds like PDF so far. PDFs need to be linearized to > support random page access, but that's easy and can be done with free > tools. > > > In addition to page turning, we're also interested in adding large- > scale image viewing capabilities to DSpace. Something more akin to > Google Maps (and many of the images we're wanting to store and display > are in fact maps). Without a pan and zoom interface of some sort, it can > be difficult to ascertain whether the image you're downloading is in > fact the image you want to download. > > > > I think most of this still falls squarely in the realm of theme > development, in DSpace terms. But it would be great to trade approaches > with other DSpace users. I have the feeling a fair number of us are > storing (or planning to do so) more "digital library" kinds of materials > in our repositories. If there were a standardized way to enable, or > facilitate, external viewing software, that would be a benefit to us > all. > > Also a problem. Thanks for explaining. > > While we need *something* soon, I think that the proper scope for such > standardization is wider than just DSpace. The real problem, it seems > to me, is that neither HTML nor CSS defines an 'unscaled' attribute. > Would the DSpace community want to get together to promote a standard > way to indicate that an image should not be shrunk to fit the browser > window? > > I suppose you can play games with the 'height' and 'width' attributes, > but that means either hand-coding them or having your service > (e.g. DSpace) delve into the image on the fly to discover the > necessary values. I don't believe the browser is required to obey > them. And if it does, that just makes the whole page bigger, but what > we would want (I think) is just to move a viewport around the image > without moving other controls offscreen in the process. > > I feel that this stuff belongs in the browser. To do it in the > service feels like mission creep, and means that the work has to be > duplicated across all services that want to deliver large-scale images > or paginated documents. > > -- > Mark H. Wood, Lead System Programmer mw...@iupui.edu > Balance your desire for bells and whistles with the reality that only a > little more than 2 percent of world population has broadband. > -- Ledford and Tyler, _Google Analytics 2.0_ ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
