Git Product home page Git Product logo

readium-js's Introduction

readium-js

EPUB core processing engine written in Javascript.

This is a software component used by the Readium Chrome extension and the "cloud reader" ( https://github.com/readium/readium-js-viewer ).

Please see https://github.com/readium/readium-shared-js for more information about the underlying rendering engine.

You can try Readium here:

License

BSD-3-Clause ( http://opensource.org/licenses/BSD-3-Clause )

See license.txt.

Prerequisites

Development

Initial setup:

  • git submodule update --init --recursive to ensure that the readium-js chain of dependencies is initialised (readium-shared-js and readium-cfi-js)
  • git checkout BRANCH_NAME && git submodule foreach --recursive "git checkout BRANCH_NAME" to switch to the desired BRANCH_NAME
  • npm run prepare:all (to perform required preliminary tasks, like patching code before building)
  • OR: yarn run prepare:yarn:all (to use Yarn instead of NPM for node_module management)

Note that in some cases, administrator rights may be needed in order to install dependencies, because of NPM-related file access permissions (the console log would clearly show the error). Should this be the case, running sudo npm run prepare:all usually solves this.

Note that the above command executes the following:

  • npm install (to download dependencies defined in package.json ... note that the --production option can be used to avoid downloading development dependencies, for example when testing only the pre-built build-output folder contents)
  • npm update (to make sure that the dependency tree is up to date)

Typical workflow:

No RequireJS optimization:

  • npm run http (to launch an http server. This automatically opens a web browser instance to the HTML files in the dev folder, choose index_RequireJS_no-optimize.html, or the *LITE.html variant which do include only the reader view, not the ebook library view)
  • Hack away! (e.g. source code in the src/js folder)
  • Press F5 (refresh / reload) in the web browser

Or to use optimized Javascript bundles (single or multiple):

  • npm run build (to update the RequireJS bundles in the build output folder)
  • npm run http:watch (to launch an http server. This automatically opens a web browser instance to the HTML files in the dev folder, choose index_RequireJS_single-bundle.html or index_RequireJS_multiple-bundles.html, or the *LITE.html variants which do include only the reader view, not the ebook library view)
  • npm run http (same as above, but without watching for file changes (no automatic rebuild))

Plugins integration:

When invoking the npm run build command, the generated build-output folder contains RequireJS module bundles that include the default plugins specified in readium-js-shared/plugins/plugins.cson (see the readium-js-shared/PLUGINS.md documentation). Developers can override the default plugins configuration by using an additional file called plugins-override.cson. This file is git-ignored (not persistent in the Git repository), which means that Readium's default plugins configuration is never at risk of being mistakenly overridden by developers, whilst giving developers the possibility of creating custom builds on their local machines.

For example, the annotations plugin can be activated by adding it to the include section in readium-js-shared/plugins/plugins-override.cson. This way, after invoking npm run http, the ./dev/index*.html demo apps can be used to create / remove highlighted selections in the web browser.

NPM (Node Package Manager)

All packages "owned" and maintained by the Readium Foundation are listed here: https://www.npmjs.com/~readium

Note that although Node and NPM natively use the CommonJS format, Readium modules are currently only defined as AMD (RequireJS). This explains why Browserify ( http://browserify.org ) is not used by this Readium project. More information at http://requirejs.org/docs/commonjs.html and http://requirejs.org/docs/node.html

Note: the --dev option after npm install readium-js can be used to force the download of development dependencies, but this is kind of pointless as the code source and RequireJS build configuration files are missing. See below if you need to hack the code.

How to use (RequireJS bundles / AMD modules)

The build-output directory contains common CSS styles, as well as two distinct folders:

Single bundle

The _single-bundle folder contains readium-js_all.js (and its associated source-map file, as well as a RequireJS bundle index file (which isn't actually needed at runtime, so here just as a reference)), which aggregates all the required code (external library dependencies included, such as Underscore, jQuery, etc.), as well as the "Almond" lightweight AMD loader ( https://github.com/jrburke/almond ).

This means that the full RequireJS library ( http://requirejs.org ) is not actually needed to bootstrap the AMD modules at runtime, as demonstrated by the HTML file in the dev folder (trimmed for brevity):

<html>
<head>

<!-- main code bundle, which includes its own Almond AMD loader (no need for the full RequireJS library) -->
<script type="text/javascript" src="../build-output/_single-bundle/readium-js_all.js"> </script>

<!-- index.js calls into the above library -->
<script type="text/javascript" src="./index.js"> </script>

</head>
<body>
<div id="viewport"> </div>
</body>
</html>

Multiple bundles

The _multiple-bundles folder contains several Javascript bundles (and their respective source-map files, as well as RequireJS bundle index files):

  • readium-external-libs.js: aggregated library dependencies (e.g. Underscore, jQuery, etc.)
  • readium-shared-js.js: shared Readium code (basically, equivalent to the js folder of the "readium-shared-js" submodule)
  • readium-cfi-js.js: Readium CFI library (basically, equivalent to the js folder of the readium-cfi-js submodule)
  • readium-js.js: this Readium code (see the js folder, which includes epub-fetch and epub-model source code)
  • readium-plugin-example.js: simple plugin demo
  • readium-plugin-annotations.js: the annotation plugin (DOM selection + highlight), which bundle actually contains the "Backbone" library, as this dependency is not already included in the "external libs" bundle. )

In addition, the folder contains the full RequireJS.js library ( http://requirejs.org ), as the above bundles do no include the lightweight "Almond" AMD loader ( https://github.com/jrburke/almond ).

Usage is demonstrated by the HTML file in the dev folder (trimmed for brevity):

<html>
<head>

<!-- full RequireJS library -->
<script type="text/javascript" src="../build-output/_multiple-bundles/RequireJS.js"> </script>



<!-- individual bundles: -->

<!-- readium CFI library -->
<script type="text/javascript" src="../build-output/_multiple-bundles/readium-cfi-js.js"> </script>

<!-- external libraries -->
<script type="text/javascript" src="../build-output/_multiple-bundles/readium-external-libs.js"> </script>

<!-- readium itself -->
<script type="text/javascript" src="../build-output/_multiple-bundles/readium-shared-js.js"> </script>

<!-- simple example plugin -->
<script type="text/javascript" src="../build-output/_multiple-bundles/readium-plugin-example.js"> </script>

<!-- annotations plugin -->
<script type="text/javascript" src="../build-output/_multiple-bundles/readium-plugin-annotations.js"> </script>

<!-- readium js -->
<script type="text/javascript" src="../build-output/_multiple-bundles/readium-js.js"> </script>


<!-- index.js calls into the above libraries -->
<script type="text/javascript" src="./index.js"> </script>

</head>
<body>
<div id="viewport"> </div>
</body>
</html>

Note how the "external libs" set of AMD modules can be explicitly described using the bundles RequireJS configuration directive (this eliminates the apparent opacity of such as large container of library dependencies):

<script type="text/javascript">
requirejs.config({
    baseUrl: '../build-output/_multiple-bundles'
});
</script>

<script type="text/javascript" src="../build-output/_multiple-bundles/readium-cfi-js.js.bundles.js"> </script>

<script type="text/javascript" src="../build-output/_multiple-bundles/readium-external-libs.js.bundles.js"> </script>

<script type="text/javascript" src="../build-output/_multiple-bundles/readium-shared-js.js.bundles.js"> </script>

<script type="text/javascript" src="../build-output/_multiple-bundles/readium-plugin-example.js.bundles.js"> </script>

<script type="text/javascript" src="../build-output/_multiple-bundles/readium-plugin-annotations.js.bundles.js"> </script>

<script type="text/javascript" src="../build-output/_multiple-bundles/readium-js.js.bundles.js"> </script>

CSON vs. JSON (package.json)

CSON = CoffeeScript-Object-Notation ( https://github.com/bevry/cson )

Running the command npm run cson2json will re-generate the package.json JSON file. For more information, see comments in the master package.cson CSON file.

Why CSON? Because it is a lot more readable than JSON, and therefore easier to maintain. The syntax is not only less verbose (separators, etc.), more importantly it allows comments and line breaking!

Although these benefits are not so critical for basic "package" definitions, here package.cson/json declares relatively intricate script tasks that are used in the development workflow. npm run SCRIPT_NAME offers a lightweight technique to handle most build tasks, as NPM CLI utilities are available to perform cross-platform operations (agnostic to the actual command line interface / shell). For more complex build processes, Grunt / Gulp can be used, but these build systems do not necessarily offer the most readable / maintainable options.

Downside: DO NOT invoke npm init or npm install --save --save-dev --save-optional, as this would overwrite / update the JSON, not the master CSON!

API

See separate API doc.

readium-js's People

Contributors

67726e avatar aadamowski avatar bormind avatar ceithir avatar chine avatar da70 avatar danielweck avatar ddr0 avatar dmitrym0 avatar ep-sas avatar ep-williaml avatar euro-fly avatar idov-isd avatar jccr avatar johanpoirier avatar julien-c avatar justinhume avatar matthewrobertson avatar matwood avatar rkwright avatar ryanackley avatar yuriyp avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

readium-js's Issues

Text search over entire book

We use jQuery to search through a book. In previous Readium versions, with eager loading enabled, we were able to search through the entire book. But eager loading has been removed.

We would prefer a Readium native way to search through the entire book. This could use the same approach as Total Page Numbers Issue #16 with a second hidden readium and iterating over that.

Make reuse of the Readium object mandatory and document it

If the Readium object were reused for opening books, we would be able to install cleanup logic on the openPackageDocument() method, as an initial step before opening a new EPUB document. Such logic is needed for properly disposing of (revoking) of any object URLs and their related Blob objects.

Note that reuse of the Readium object would need to be made obligatory and documented in the ReadiumJS API documentation.

font size bug on iOS

safari and chrome show same bug

what I found is...

  • when I go to next spine (by pressing next button), the font size is changed to any big size.
  • when i change the screen mode(portrait <-> landscape), the right font size comes back
  • non-working devices: iphone5s(8.3), iphone4s(7.0.4)
  • working devices: iphone6(8.3), iPad-mini(8.2)

this is my test epub file
https://www.dropbox.com/s/livmyrv8nsmv6ic/bookcube_sample.epub?dl=0

Resource cache (Blob URIs) algorithm incorrect: downshiftedEntry.orderingByLastUseTimestampIdx

Cloud reader, Chrome web browser, on Windows 8.1

To reproduce, navigate (using the TOC) several pages / spine items in SmokeTestFXL.

"algorithm incorrect: downshiftedEntry.orderingByLastUseTimestampIdx"

This assertion error occurs when ResourceCache.getResourceURL() is invoked.

https://github.com/readium/readium-js/blob/master/epub-modules/epub-fetch/src/models/resource_cache.js#L68

            function removeCacheEntryFromOrderedIndex(cacheEntry) {
                // Remove the previous entry from the ordered index, if present:
                if (typeof cacheEntry.orderingByLastUseTimestampIdx !== 'undefined') {
                    var orderingByLastUseTimestampIdx = cacheEntry.orderingByLastUseTimestampIdx;
                    _orderingByLastUseTimestamp.splice(orderingByLastUseTimestampIdx, 1);
                    // Decrement index values for all downshifted entries:
                    for (var i = orderingByLastUseTimestampIdx; i < _orderingByLastUseTimestamp.length; i++) {
                        var downshiftedEntry = _orderingByLastUseTimestamp[i];
                        // Assertion
                        if ((downshiftedEntry.orderingByLastUseTimestampIdx - 1) != i) {
                            console.error('algorithm incorrect: downshiftedEntry.orderingByLastUseTimestampIdx: ' +
                                downshiftedEntry.orderingByLastUseTimestampIdx + ', i: ' + i);
                        }
                        downshiftedEntry.orderingByLastUseTimestampIdx = i;
                    }
                }
            }

HTML spine item inner iframes (e.g. widgets) lack MathJax and navigator.epubReadingSystem

Follow-up to: readium/readium-js-viewer#356

Spine item documents are correctly pre-processed ( https://github.com/readium/readium-js/blob/develop/epub-modules/Readium.js#L39 ) in order to:
(1) inject the navigator.epubReadingSystem object
(2) inject the MathJax "bootstrapper"
(3) plug / block / redirect the window.top/parent properties
This process relies on a "shallow" content parser (HTML DOM only), just to load the spine item HTML markup in the top-level iframe, via BlobURi. Consequently, inner iframes are not pre-processed, resulting in EPUB "widgets" lacking support for MathML and the epubReadingSystem object.

Note that loading zipped-EPUB (and expanded EPUBs that contain obfuscated fonts) relies on a "deep" content parser (HTML DOM, CSS, etc.) so that all resources are loaded via BlobURis, including inner iframes (this process was coined "programmatic fetching"). Unfortunately, in that particular scenario web browsers fail to instantiate "nested" BlobURi instances, and inner iframes fail to load. See #105 (comment)
I suspect that the same implementation caveat might exist for the generic cloud reader...to be verified.

Unprecise CFI for getFirstVisibleElementCfi() / cfi_navigation_logic.js

The CFI returned by getFirstVisibleElementCfi() in cfi_navigation_logic.js is unprecise.

Procedure to reproduce

Open the redium-js-viewer with the embedded book 'accessible epub 3'. Go to chapter 2 and turn a few pages. Launch getFirstVisibleElementCfi()

Actual result

The partial CFI returned is always ""/4/2[building_a_better_epub]/2@0:xx". This targets the first <section> of the chapter, which include the whole text content of the chapter, then add a positionning in % in that chapter.

Expected result

CFI returned should be more precise and return an CFI pointing to an inner <p>inside the <section>, like "/4/2[building_a_better_epub]/10/32/12@0:xx".

Explaination

This is because the first child of the <section> element, which is a blank text node, is reported by both Chrome and Firefox as visible on all columns in a multi-columns layout. When walking the DOM to find the first visible text node, this one is always checked first and always answer "yes".

The code should ignore blank text nodes but this one is not ignored. Probably because it contains tabulations, carriage returns or other characters than space and line feed.

Fix

In cfi_navigation_logic.js :

function isValidTextNode(node) {
    if(node.nodeType === Node.TEXT_NODE) {
        return (! node.nodeValue.match(/^\s*$/) );
     }
     return false;
}

This replace the all code that just strip spaces and line feeds then check that the length is not 0.

Problem

I did not send a PR because when fixing this bug, I trigger a browser bug on Firefox which forbids Firefox from being able to jump to these more precise CFI (the getClientRects() of the targeted element are always totally incoherent).

In 2 pages mode, the second page may not show up entirely

readium

See screenshot (in the right page : lack of a few characters on end of line, and lack of the blue right border of the "note"). Both reproduceable in Firefox and Chrome, both in master and in develop branches. This example is with the file "accessible epub 3" from readium-js-viewer.

When resizing little step per little step, it is easy to find a step where the second column is truncated of a few pixels.

In my example, here a few metrics :

  • #reflowable-content-frame (<div> surrounding the <iframe>) is of 766.5 pixels
  • iframe is of 767 pixels
  • inner html document is 767 pixels with 353px columns and 60px gap

The total (2 columns + gap) should fit in the iframe, but does not.

<p>in the columns have 353.5px (and not 353px) however there are more than 1 pixel missing at right so I doubt this rounding error is the root problem.

However, the <aside> surrounded by a blue border has 335.5px widht + 2_8px padding + 2_1px border. This may have to be investigated as a potential cause of the problem.

packed / zipped EPUB fetching: assets resolved to wrong absolute URL (package OPF root)

https://github.com/readium/readium-js/blob/master/epub-modules/epub-fetch/src/models/content_document_fetcher.js#L100

var resourceUriRelativeToPackageDocument = (new URI(refAttrOrigVal)).absoluteTo(_contentDocumentPathRelativeToPackage).toString();

The use of _contentDocumentPathRelativeToPackage as the reference for all EPUB assets means that files stored within folder hierarchies not rooted to the OPF directory resolve to incorrect absolute URL.

Test file: logger-demo.epub (ESC EPUB Embedded Scriptable Components / Widgets)
https://groups.google.com/d/msg/epub-working-group/6asTqzQTxyc/LD-vvpny0-EJ

Conversion of NCX toc navPoints to <ol> produces different structure

I would appear as though addNavPointElements() in package_document.js is producing output that doesn't match the structure of the original navPoints.

For example:

<navPoint>
    <navLabel></navLabel>
    <content></content>
    <navPoint></navPoint>
    <navPoint></navPoint>
    ...etc.
</navPoint>

becomes:

<li>
    <a></a>
</li>
<li>
    <ol>
        <li></li>
        <li></li>
        ...etc.
    </ol>
</li>

Unless there's something of which I'm not aware, shouldn't it instead be:

<li>
    <a></a>
    <ol>
        <li></li>
        <li></li>
        ...etc.
    </ol>
</li>

The offender appears to be here

I'd be happy to submit a pull request if this is a desired change.

Enabling scroll view blocks the touch events in IOS8 Tablet webkit application

I have used Readium.syncload.js(version release/0.15) and cordova wrapped to build epub reader mobile application for Android and IOS devices.
I have enabled scroll view in the reader as follows:
reader.updateSettings({
"scroll": "scroll-doc",
"syntheticSpread": "single"
});
Scroll works fine but the touch events are not triggered so internal links are not working.

Observation:

Enabling Reflowable view works fine for touch events

Programmatic fetch: works with SVG spine items? (cloud reader with zipped EPUB or obfuscated fonts)

I have not tested this, but judging by the code it seems that outerHTML would be called on a SVGDocument instance:

https://github.com/readium/readium-js/blob/develop/epub-modules/epub-fetch/src/models/markup_parser.js#L17

new window.DOMParser().parseFromString(" ... ", "image/svg+xml");

https://github.com/readium/readium-js/blob/develop/epub-modules/epub-fetch/src/models/iframe_zip_loader.js#L41

SVGDOM.documentElement.outerHTML

This may not be supported in all of Readium's target web browsers. To verify.

Maybe:

new XMLSerializer().serializeToString(DOM)

Add a LICENSE in the repo root dir

Issue: deciphering which license applies to the code in the repo is not trivial. (I believe it is the "3-clause/New BSD license".)

Suggested Fix: Add a LICENSE file in the repo root directory, and maybe mention it in the README

Thanks.

epub-fetch module treatment of css ressources

Firstly thank you.

I have been integrating readium.js into our mobile viewer project for a a few months now ( I am aware of the mobile started packs ) in a html5 strategy ( crazy I know ) and have come to a fairly stable alpha build of our product.

I wonder if the treatment of CSS files as part of epubFetch.resolveInternalPackageResources is proper. Indeed it treats most if not all of these as blobs, and while this is true for most internal ressources, it seems to me that we should deal with the css ressources as text and load them as such.

The behaviour that I have been observing on mobile browsers (iOS and Android) using the codova Web View is that the css does not seem to be loaded ( in time? ) before th rendering. And while this behaviour does not affect us on Chrome, I wonder if this is an oversight or by design.

When I download the epub and unzip it in the HTML File system using plain package exploder, the css is loaded and the epub renders properly.

Handle programmatic navigation in zipped epubs (and exploded EPUBs?)

Hi,

I encountered a serious issue with a zipped epub 3.
There is one page with an and many empty <div> (like a handmade <map>).
There is a little javascript that listens to clicks on the divs and then calls the following code (the page param is the id of the div):

function goto(page){    
    window.location.href = "../page/"+page+".xhtml";
}

And this doesn't work at all with a zipped epub because the url is not replaced by a blob url.
And I can't see how to handle such dynamic requests, do you?

In the future, we would use the Service Worker API but we ain't there yet.

Blob URLs violates CSP in Firefox OS apps

Privileged and certified apps in Firefox OS enforce a CSP by default.

Therefore, <link href="blob:xxxx-xxxx-xxxx-xxxx" rel="stylesheet"> is rejected. The only workaround I found is to put the stylesheet data in a <style type="text/css"> element as 'unsafe-inline' is authorized for privileged apps. I can't submit a PR yet because I don't like my implementation.

But I'm very interested in your thoughts about this.

Adobe-obfuscated fonts are not being de-obfuscated

My Tiny-Obf testfile is not working. I am using the ruby scripts that are from the epub-testsuite repo. The commands I used are:

GORT:mangled rkwright$ ruby mangle_font_adobe.rb zantroke.adb.otf org.readium.test.tinyobf >out.txt
GORT:mangled rkwright$ ruby mangle_font_idpf.rb zantroke.obf.otf org.readium.test.tinyobf >out.txt
GORT:mangled rkwright$ ruby mangle_font_adobe.rb sandome.adb.ttf org.readium.test.tinyobf >out.txt
GORT:mangled rkwright$ ruby mangle_font_idpf.rb sandome.obf.ttf org.readium.test.tinyobf >out.txt

The ruby I am using (on OSX 10.9) is ruby 2.0.0p451 (2014-02-24 revision 45167) [universal.x86_64-darwin13]

The file is here
https://readiumfoundation.box.com/s/1xjal4e0yzigkg4m1mq5

BTW, the file passes EPUBCheck without errors. Interestingly, NONE of the fonts are displayed in iBooks, not even the non-obfuscated OpenType (Zantroke). We only display the non-obfuscated fonts.

Ah, checking the console, I see:

Failed to load resource: net::ERR_FILE_NOT_FOUND filesystem:chrome-extension://hfhdfihjnecbeaocmenccjjikddhaijm/persistent/1407418041675808/META-INF/encryption.xml
Error when AJAX fetching filesystem:chrome-extension://hfhdfihjnecbeaocmenccjjikddhaijm/persistent/1407418041675808/META-INF/encryption.xml
error
Document doesn't make use of encryption.

IIRC, we should be de-obfuscating when the file is expanded on being loaded into the library. Apparently that isn’t happening?

Application crashes in ios devices on increasing the font size

Steps to Reproduce:

  1. Initialize readium
  2. Read any epub of size more than 1MB
  3. Increase the font size inside the reader by updating the settings
    Below is the code snippet:
    • Initial fontSize = 100
    • On font increase = font size +10
    • On font decrease = font size - 10
    • readium.reader.updateSettings({"fontSize": fontSize)

Observation:

Application terminates with the memory warning error

SVG spine item: no head element => base injection fatally fails

culprit:

https://github.com/readium/readium-js/blob/develop/epub-modules/epub-fetch/src/models/content_document_fetcher.js#L73

function setBaseUri(documentDom, baseURI) {
                var baseElem = documentDom.getElementsByTagName('base')[0];
                if (!baseElem) {
                    baseElem = documentDom.createElement('base');

                    var anchor = documentDom.getElementsByTagName('head')[0];
                    anchor.insertBefore(baseElem, anchor.childNodes[0]);
                }
                baseElem.setAttribute('href', baseURI);
            }

Readium WEB ASP.net

How i can using it with my Asp.net project please and give me example if you can
Kind Regards,

openPackageDocument callback should wait for iframe to render

We need a synchronous callback after the iframe is loaded to have CFI's etc. work properly. We currently it do the following as a workaround:

$iframe.one("load", function () {
  // our own callback
});

Really though, this should be fixed in Readium proper.

iframe loader, resource / publication fetcher => vendor-specific configuration (RequireJS Grunt overrides?)

This seems like a reasonable candidate for the upcoming refactoring, either via the introduction of a new plugin mechanism (extensibility API) ; or simply by leveraging the existing RequireJS dependency injection framework ; thereby ensuring that the existing "useSimpleLoader" and "shouldConstructDomProgrammatically" + "shouldFetchMediaAssetsProgrammatically" (etc.) parameters can be controlled at build time (vendor-specific Grunt script overrides), in addition to the runtime decision tree (as the choice of loader / fetcher depends on the nature of EPUB to open, see comment below for details).

https://github.com/readium/readium-js/blob/develop/epub-modules/epub-fetch/src/models/publication_fetcher.js#L88

https://github.com/readium/readium-js/blob/develop/epub-modules/epub-fetch/src/models/iframe_zip_loader.js#L36

https://github.com/readium/readium-js-viewer/blob/develop/chrome-app/extended-config.js#L23

Cloud reader: audio / video / track (subtitles) "programmatic" content fetch (binary blobs) fails when source element is used instead of src attribute (affects zipped EPUB and EPUBs with obfuscated fonts)

https://github.com/readium/readium-js/blob/develop/epub-modules/epub-fetch/src/models/content_document_fetcher.js#L297

            function resolveDocumentAudios(resolutionDeferreds, onerror) {
                resolveResourceElements('audio', 'src', 'blob', resolutionDeferreds, onerror);
            }

            function resolveDocumentVideos(resolutionDeferreds, onerror) {
                resolveResourceElements('video', 'src', 'blob', resolutionDeferreds, onerror);
                resolveResourceElements('video', 'poster', 'blob', resolutionDeferreds, onerror);
            }

For example:

https://code.google.com/p/epub-samples/source/browse/trunk/30/cc-shared-culture/EPUB/xhtml/p30.xhtml#15

            <video id="video1" autoplay="" role="button" aria-controls="video1" controls="">
                <source src="../video/shared-culture.mp4" type="video/mp4"/>
                <source src="../video/shared-culture.webm" type="video/webm"/>

                <track src="../captions/cc-en.vtt" srclang="en" kind="subtitles" label="English"/>
                <track src="../captions/cc-fr.vtt" srclang="fr" kind="subtitles" label="Français"/>                
            </video>

External compressed ZIP ePubs not functioning on iPad (Safari, Chrome iOS)

Originally posted by @danielcrenna
at
readium/readium-js-viewer#65

We have set up an example of loading externally-(Azure) and internally-(our server) sourced compressed EPUB files, which works as expected on desktop browsers, and even when the compressed content is served locally via Http Byte Serving on Safari for iPad.

However, remote compressed EPUBs do not function on Safari iOS or Chrome iOS, and internal compressed EPUBs do not function on Chrome iOS (they work on Safari iOS).

We know that CORS is set up properly because this setup works on every desktop browser we've tried. As always, uncompressed content works fine. Is there something specific about the EPubUnzipper or PackageParser implementations that cause this on iOS?

I am happy to share our reference implementation privately if you're interested.

Font decryption fails

When I open an epub with encrypted fonts readium tries to decrypt them. It fails to create encryption data (encryption_handler.js:114), because lib/2.5.3-crypto-sha1.js isn't loaded.

I don't see it in rjs_require_config.js, shouldn't it be there? Adding it there (plus in define clause in envryption_handler) or simply loading this file in </script> tag solves the problem.

Reproduced on versions 0.14 and 0.15.

Total Page Count and Current Page Index for entire book

Currently there is no obvious way of getting the total page count and current page index for the entire book. In previous versions of Readium, we eager loaded the entire book, which allowed us to do this, with performance drawbacks.

One workaround in our code could be to make a second hidden Readium container and iterating through each SpineItem to get the page count.

We would prefer an official way of doing this, while still maintaining performance considerations and clean code.

Reading position is lost when resizing the browser window in a reflow document

Reproduce

Open the readium-js-viewer (but this is not viewer-specific), go to a reflow book (like the embedded accessible epub 3). Go to chapter 2, turn a few pages. Look at the text visible in the top left corner. Change the size of the browser

It is easier to reproduce if you go next to the end of the chapter and then you reduce the browser window by a factor of 2.

Actual result

The text that were visible in the top left corner is no more visible after the resize / layout. It may be multiple pages forward or backwards. The user has to turn pages until he finds again his reading position.

Expected result

The text that was in the top left corner is still visible (but probably not in the top left) after the resize / layout.

Fix

Possible fix : https://github.com/edas/readium-shared-js/commit/f61b9a9d371227f1046238efe7d826e11257ed27

But when done in addition of #47 , Firefox bugs on restoring the current page : The targeted element often returns inconsistent values in getClientRects() so we cannot find the new spread to show.

NCX supported in code, but unused feature? (only EPUB3 navigation document?)

It looks like this code is effectively unused (I can't find any references anywhere), and I get reports of EPUB2 ebooks failing to work properly because of missing TOC:

https://github.com/readium/readium-js/blob/develop/epub-modules/epub/src/models/package_document.js#L109

        // Unused?
        this.generateTocListDOM = function(callback) {
            var that = this;
            this.getTocDom(function (tocDom) {
                if (tocDom) {
                    if (tocIsNcx()) {
                        var $ncxOrderedList;
                        $ncxOrderedList = getNcxOrderedList($("navMap", tocDom));
                        callback($ncxOrderedList[0]);
                    } else {
                        var packageDocumentAbsoluteURL = new URI(packageDocumentURL).absoluteTo(document.URL);
                        var tocDocumentAbsoluteURL = new URI(that.getToc()).absoluteTo(packageDocumentAbsoluteURL);
                        // add a BASE tag to change the TOC document's baseURI.
                        var oldBaseTag = $(tocDom).remove('base');
                        var newBaseTag = $('<base></base>');
                        $(newBaseTag).attr('href', tocDocumentAbsoluteURL);
                        $(tocDom).find('head').append(newBaseTag);
                        // TODO: fix TOC hrefs both for exploded in zipped EPUBs
                        callback(tocDom);
                    }
                } else {
                    callback(undefined);
                }
            });
        };

        function tocIsNcx() {

            var tocItem = getTocItem();
            var contentDocURI = tocItem.href;
            var fileExtension = contentDocURI.substr(contentDocURI.lastIndexOf('.') + 1);

            return fileExtension.trim().toLowerCase() === "ncx";
        }

        // ----------------------- PRIVATE HELPERS -------------------------------- //

        function getNcxOrderedList($navMapDOM) {

            var $ol = $("<ol></ol>");
            $.each($navMapDOM.children("navPoint"), function (index, navPoint) {
                addNavPointElements($(navPoint), $ol);
            });
            return $ol;
        }

        // Description: Constructs an html representation of NCX navPoints, based on an object of navPoint information
        // Rationale: This is a recursive method, as NCX navPoint elements can nest 0 or more of themselves as children
        function addNavPointElements($navPointDOM, $ol) {

            // Add the current navPoint element to the TOC html
            var navText = $navPointDOM.children("navLabel").text().trim();
            var navHref = $navPointDOM.children("content").attr("src");
            var $navPointLi = $('<li class="nav-elem"></li>').append(
                $('<a></a>', { href: navHref, text: navText })
            );

            // Append nav point info
            $ol.append($navPointLi);

            // Append ordered list of nav points
            if ($navPointDOM.children("navPoint").length > 0 ) {

                var $newLi = $("<li></li>");
                var $newOl = $("<ol></ol>");
                $.each($navPointDOM.children("navPoint"), function (navIndex, navPoint) {
                    $newOl.append(addNavPointElements($(navPoint), $newOl));
                });

                $newLi.append($newOl);
                $ol.append($newLi);
            }
        }

Images not resizing to fit the screen in scrollview

Steps to Reproduce:

  1. Enable scroll view - readium.reader.updateSettings({
    scroll: "scroll-doc"
    }); in the Epub reader view
  2. Read any article containing big image sizes like 600x511, 600X300 and etc.,
    Observation:

    Images are not resizing to fit the screen as shown in the attached image.
    image_notresizing

Note: We have fixed in our application by adding css properties to the image tags after the content documents are loaded
$(imgTags).css('max-width', '98%');
$(imgTags).css('max-height', '98%');

Please fix in the readium library

Empty title in HTML file causes IE to display a blank page

Hi,

I have an excerpt from an epub file that have some html files with empty titles : <title></title>.
If the epub is packaged, the iframe_zip_loader is used to open files and parse the content.
DOMParser is then used to parse the html content : DOMParser is a XML parser and outputs <title/>which is not allowed in HTML (and causes IE to display a blank page).

I have a quick fix in mind : fill the <title>tag if it's empty. Do you have a better solution ?

Thanks,
Johan

Make it possible for epubs to be served from a different domain

Verified using readium-js-viewer in different browsers with enabling Access control allow origin in the backend from where the epubs are fed to the readium-js-viewer . Below are the errors:
-In Firefox Browser
"epubReadingSystem INJECTION ERROR! Permission denied to access property 'navigator'"

-In Chrome Browser
epubReadingSystem INJECTION ERROR! Blocked a frame with origin "http://portal.newgen.co" from accessing a cross-origin frame.
Uncaught SecurityError: Failed to read the 'contentDocument' property from 'HTMLIFrameElement': Blocked a frame with origin "http://portal.newgen.co" from accessing a frame with origin "http://commondatastorage.googleapis.com". Protocols, domains, and ports must match.

we had to get around this problem by running Chrome with cross-origin security turned off: path/to/chrome --disable-web-security. This is not feasible when the readium reader is deployed in the apache server as a part of our web site.

programmatic fetching of Blob URIs (zipped EPUBs and obfuscated fonts) => support for nested iframes widgets

https://github.com/readium/readium-js/blob/master/epub-modules/epub-fetch/src/models/content_document_fetcher.js#L57

// TODO: recursive fetching, parsing and DOM construction of documents in IFRAMEs,
// with CSS preprocessing and obfuscated font handling
resolveDocumentIframes(resolutionDeferreds, onerror);

https://github.com/readium/readium-js/blob/master/epub-modules/epub-fetch/src/models/content_document_fetcher.js#L310

            function resolveDocumentIframes(resolutionDeferreds, onerror) {
                resolveResourceElements('iframe', 'src', 'blob', resolutionDeferreds, onerror);
            }

I experimented with the proposal below, to no avail (because nested Blob URIs iframes have a null contentWindow, and the sub-Blob is not supported by the web browser).

Media Overlays support in ZIP EPUB mode (files not expanded)

Originally reported by @aadamowski
at
#28

Media overlays currently do not work for zipped EPUBs when read using plain browser-based viewer utilizing the readium-js library - that's a known issue that will require non-trivial changes to be solved (due to inherent limitations of a pure JS, pure client side, browser-based environment).

Taking this into account, does anyone still have problems:

  • on Safari,
  • with reading zipped EPUBs,
  • served through the embedded server launched from the Grunt build, listening on port 8080,
  • while the same zipped EPUBs work fine on Chrome browser, while accessed from the aforementioned server?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.