readium / mobile Goto Github PK

According to the Readium Audiobook Profile, a RWPM must contain the duration property in the Link objects to conform.

However, the mobile toolkits Publication.conformsTo() API is only checking the media type in the reading order, not the availability of duration, so it's not checking full conformance. The reason for this is that we don't have the info for Zipped Audiobooks.

As a workaround, we could add an Audio/MediaPublicationService which will compute the duration from:

• the duration Link object properties for streamed manifests
• the resource metadata for Readium Packages and ZAB

Then, the conformsTo() API could use this info to check that the duration is available for all the resources of the reading order.

The mobile toolkits are currently lacking documentation. Let's use this issue to track the work to be done.

Some of the pages will be in the shared mobile repo while platform-dependent ones will be in swift-toolkit or kotlin-toolkit.

The integration guides will be in each platform repo and will be the gateway to more abstract concepts/APIs.

• Integration guides
  • What to do if you're stuck?
    • Look in the github issues/discussions, then Slack.
    • What kind of issues we can offer support for.
  • What publication formats are supported by Readium?
  • How to open a publication and read its metadata?
  • How to render a publication on the screen?
  • How to save and restore the last read position?
  • How to save bookmarks?
  • How to display page numbers?
    • Explains the difference between page numbers, screen pages and positions
  • How to show a progress bar for the whole publication?
  • How to add new text selection menu items?
  • How to get the current progression / page number in the publication?
  • EPUB: How to add custom fonts?
  • EPUB: How to customize the text and background colors?
  • How to search through the content of a publication?
  • How to highlight a text selection?
  • How to display the table of contents?
  • How to browse an OPDS catalog?
  • How to open publications protected by Readium LCP?
• General concepts
  • Readium architecture (overview of each modules) in the context of Readium mobile
  • Core models / terms
    • Publication models and extensions
    • Publication services
      • Position
      • Cover
      • Search
      • Locator
    • Locator
    • Fetcher
    • MediaType
  • Streamer
    • PublicationParser
    • HTTP server
  • Navigator
    • Navigation
    • Decorator
    • Presentation
    • Injectable
  • Content Protection
  • Readium CSS
• Contribution guides
  • How to setup a dev environment
  • Guidelines to contribute
  • Licensing?
  • Detailed overview of each module's architecture
  • How to build the EPUB JavaScript bundles?

I can see Note (annotation) option is available in menu when selected the text in Android, but when I am trying for the same option in iOS I can't see the Note option. Please let me know if it is available for iOS or if I am missing anything to unable the Note option for iOS

Dear,
You are doing great job!, I appreciate your effort. I have one question though:
Do you have custom dictionary support. I mean lets say I have a custom dictionary in stardict format, can I call it to lookup for words I want to while I read book in epub mode??
I have dictionary in my native language ("punjabi").
I can also help you if you like to build this feature, although I am new to app development...
Thank you in advance
Sajan

LCP relies on URI templates for LSD operations, and soon Publication Services will need them as well.

Unfortunately, the implementation is subpar in both Swift and Kotlin toolkits.

The URI Template specification being quite complex, it might be worth adding an external dependency for this, instead of implementing it ourselves. We need to make sure the dependency is at least being tested using the official test suite.

Alternatively, we could support only a subset of the specification, which would be much more manageable. But it depends on the usage made of Link objects.

how can i add readium to my react native project?

Tables have always been quite an issue and their rendering can become quite terrible in CSS multicol (cells being cut off, vertical padding not being properly handled, etc.).

There’s no easy way out there, and it’s probably up to authors to find solutions but we can at least try reaching interop with some popular apps that will open the table in a dedicated web view (on top of the current one, with a close button) if the user double-clicks or double-taps one.

A few notes as to why this should be reasonable:

• authors’ scripting is already taking this feature into account since you can find it in iBooks for instance;
• for large tables, that would allow overflow-x (on the web view itself), something we can’t easily do in the paged and scrolled views (we would have to add an extra wrapper around the table since overflow won’t work for table itself…);
• it is expected styling for the table (excepted inline style="") will not apply in the dedicated web view;
• there will be huge tables to handle as people can become very creative when it comes to finding reasons why those tables must absolutely stay as they are in print (personally encountered the “moral rights of the author” justification a few years ago).

Please feel free to add your thoughts, obviously.

Who can help me? I'm helpless

Let's say that I want to add a feature where double-tapping an image in a book displays it in a native UI fullscreen. Or even better, pinching on the image turns it into a native image that I can stretch, rotate and snaps to fullscreen, like in the Photos app.

(I have done this with another app, many years ago.)

I'm wondering what the best way would be to go about implementing at least the double-tap, and ideally in a way that can be integrated into Readium, if it's something that should be in Navigator or the App or some part of the codebase.

Purely from an implementation perspective, here are some notes:

• The double-tap detection could be done in JS or Swift.
• Would detect it by putting some code on a timer and then waiting for the second tap; if it never comes, then respond to the original event.
• Because most elements don't need the double-tap would need to filter for <img> tags and only do the timer in that case; there's no reason to give all tap events a delay.

I'm tempted to do a bunch of this work in JS and then wire up a new delegate method on the Swift side, but I don't think such a thing would be merged. The double-click handler could probably be implemented on the Swift side, but what about pinch-to-zoom-out? I don't think that's going across the default tap bridge. Also, should it be customizable what elements this works for? Etc.

Anyway, I will probably hack something together for now but I wanted to discuss what the optimal route is on this. Some of it might be Swift delegate code, and some might be injected JS. I know R2 is intended to be flexible enough not be forked, and I'm not sure how much of this should be supported natively and/or what the strategy would be for enabling this kind of functionality for app devs.

I know scroll mode is still super rough around the edges in the app and work on scroll is planned for October but I’d like to point out this issue in advance (so that I don’t forget about it).

The rendition: flow values dedicated to scroll are scrolled-continuous and scrolled-doc. And it will obviously impact both @camill-a and I (again it’s not urgent at all, just recording my thoughts).

My understanding is that we currently have something like scrolled-doc: swipe left/right to navigate between documents and scroll to read them. Reminds me of the first digital magazines on tablets a little bit (and I know a lot of users were kinda confused with this navigation pattern, which is why this pattern dropped in popularity/usage over time).

It looks like Readium 1 and iBooks’ scroll modes, for instance, are more like scrolled-continuous but I may be wrong there – especially as the expected behavior is not very clear, cf. note in the spec. Well, I guess that at least it can be defined as web views on top/bottom of one another (except for vertical writing).

I don’t know if you want to support both but if this is the case, I can already tell we’ll have to create a flag for each one so that we can make adjustments in Readium CSS: if continuous, we’d better add top/bottom margins so that the reader knows it’s a new html file for instance, and we may also have to sanitize viewport height values depending on the implementation.

Since work on the test app and Readium CSS overlap there, I assume we’d better deal with this issue in the R2-testapp first then put the recommendations in the readium-css repo. Does this feel OK to you?

Changing the font size with Readium CSS is limited because if the publication has absolute font sizes then enabling advanced options is necessary: basically disabling publisher's defaults.

A possible workaround would be to use native solutions when available since Readium CSS is platform-agnostic.

text-size-adjust is promising and seems to be available on both iOS and Android: https://caniuse.com/?search=text-size-adjust

Related issue: readium/readium-css#34

Here are a few points regarding the Readium CSS integration which should be double-checked or fixed in the mobile toolkits.

• ReadiumCSS-default.css needs to be injected if the book doesn't have any style.
• When using iframes, we need to use allowtransparency to make sure that background color settings work properly.
• Check rendering on big screens.

  • Since we still limit line-length in the spread model, you might want to limit the web view/iframe size so that you don’t end up with wide gaps on large screens (or add padding to :root, and take it into account when scrolling).

• Instead of fixed fonts (Helvetica Neue, Athelas, etc.), we should expose by default the font stacks from Readium CSS, using the provided CSS variables.
• Should we use Readium CSS highlight colors? There's an on-going discussion. Nope.
• We should improve support of internationalization.

  • the app should at least offer the publisher’s font and the default (var(--RS__baseFontFamily)) for the language – which should work automatically if the correct language is set for each document;

  • Some user settings need to be disabled depending on the publication language, both in the UX and in ReadiumCSS.
  • The primary language needs to be determined from the page progression as well.

    • There's a well known bug on InDesign (addition of an extra ar-SA dc:language) which causes problems in the reading progression of apps like iBooks (they rely on the last dc:language because they can't rely on the spine attribute in EPUB2)

  • The primary language needs to be injected in the DOM with xml:lang.
    • Determining the primary language doesn't depend only on the order of <dc:language>, the page-progression-direction must be taken into account.
  • Check the list of languages for CJK support.
  • We need to inject the EBPAJ patch for Japanese.
  • We must not inject the dir= attribute with CJK languages
  • Some parts of the UX must follow the publication's direction, including search and highlights.
• Some books won't change their font size unless publisher's styles are disabled.

Original issue can be found on the ReadiumCSS’ issue tracker

This is not urgent but the issue belongs to apps and it will be more visible to developers in the apps’ issue tracker.

Users want to have control to meet their disability, preferences, taste…

Providing a Google fonts install in the reading app is a good thing but what will be better is to provide the list of fonts already aiviable in the system as most of the users would have already installed there their needed fonts.

It needs a work specific for each platform and implementation but will be the best way to provide users an install extra font features.

Most operating systems have a way to install custom fonts at a OS level so why do each app will reinvent the wheel and provide their on way to install font for their own use instead of just letting the user pick in the system installed fonts.

As an example, even iOS which was really close have add a way to install fonts through Apple configurator app and the process is even simpler through http://sub.pentacom.jp/custom-ios-fonts/ or an app like Anyfont. Even font vendors like Myfonts eased the process with an install function directly on the order page.

Before this, each app which want to give this option have done an install in app with the major drawback that the font was only aiviable in the app. Now with system install, all app could browse and pick a font from the system as other OS.

This is an example but most platform have this possibility. Its works to done for each one but this seems the way to go as users willing to install a custom fonts in their reading apps must probably have ever installed it on the system for use in other apps.