readium / r2-testapp-swift Goto Github PK

The EPUB TestSuite 120 (Media Overlays) causes the application to crash, even before it displays the library or tries to open the EPUB.

Method:

1. Start the app
2. Add the module 120 to the library
3. Try to start the app

Result: Crashes every time. No message, nothing.

Tried deleting the app and adding the module alone. Same result. Other modules in EPUB TestSuite seem to work (only have tried first 5 so far).

Test App: 0.2 (2) (installed from preflight)
Device: iPad 5
OS: iOS 11.0.3
Memory: 16 GB

swipe works just fine in both landscape and portrait mode.

If an LCP license has no end date, the renew and return actions found in the LCP info panel must be hidden.

If a license is processed with passphrase 1 (hash is cache) and the user decides to change his passphrase, on the server of the bookseller / license provider, the publication cannot be open anymore. The message states: The operation couldn't be completed, which is pretty vague, and the (new) passphrase is not asked to the user.

On IOS 9.3.5 (iPad) the user setting menu does not work. Font size, night mode, scroll mode, font size, change font... :(

When we build the app with SDK 11.3, an unexpected crash occurs when adding a new book to the library. Tested on simulator and device.

• We use a deprecated method in the application delegate:
  func application(_ application: UIApplication, open url: URL, sourceApplication: String?, annotation: Any) -> Bool

• Should be replaced with:
  func application(_ app: UIApplication, open url: URL, options: [UIApplicationOpenURLOptionsKey : Any] = [:]) -> Bool

Book size on the bookshelf is calculated to fit 3 books per row when the bookshelf view first appears.

This means that if you launch the program in landscape mode you will get 3 books per row, but if you launch the program in portrait mode and switch to landscape you will get 4.

Expected behaviour: size is calculated separately for each orientation

cover, title and author should be visible in this view

The title is not visible on black background.

The appdelegate can't be compiled with the xcode9.2.
The detail is below:
Value of tuple type 'PubBox' (aka '(publication: Publication, associatedContainer: Container)') has no member 'protectedBy'

Currently, facets (the filter action) is always displayed in the UI, even when no facets are available.

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.

After the latest commit, it cannot open files from any source. I think the LCP check is not correct.
The LCP condition check should under case "lcpl" instead of cover all the cases.

#if LCP
#endif

The default case should not be covered by this. Then, it will work again.

R2LCPClient,ReadiumLCP,SiwftyJSON,ZIPFoundation,SQLite lib is Missing,the project can't compiled

After (private) feedback from an iOS app tester, I did a quick round of testing this morning and can indeed reproduce the tester’s issues with hyperlinks’ handling (and more).

As far as I can tell, this applies to the iOS test app but since it is using touchHandling.js, which place won’t eventually be in the streamer, I guess this issue can serve as a reference for future improvements.

To sum things up:

• UI and nav events (menu, go to previous page – especially with nav doc) are taking over hyperlinks pretty often;
• for some reason, it seems to work a lot better when going back to the html file for me (correlation ≠ causation so I won’t risk my life there);
• for future reference, I tested a few form elements as well:
  • buttons are currently A-OK;
  • checkboxes and radio buttons are KO.
• (native) text selection is also an issue since you can select a word/fragment but can’t unselect it so selection is active with the iOS pop-over menu (should I disable text-selection in Readium CSS?).

And that’s it.

Couldn’t test more at the moment but we actually have an EPUB 3 test file for HTML5 rendering in Readium CSS, with all form elements, so I’ll take a look at it and update this issue to report back.

Hi,
Strange issue:
I tested an epub with some JS in R2 version 0.2(2) on two iPads (iOS 11.0.2).
On iPad Air 2, JS works fine. On iPad Mini 4, it's buggy, script seems to stop. However, it works fine with iBooks or Lisa.
The script is based on this

this should be already implemented, in the last demo however something didn't work entirely.

Page Lists and Landmarks are an important feature of a Reading System, for higher education.

The UI needs first to be discussed (common to iOS and Android).

As we known, r2-navigator-swift uses the triptych view pattern to do some pre-rendering job. It looks good if both the previous and the next html contains many pages. Because it take some time for user to scroll to another previous/next html, so the reading system(WKWebView) can pre-render the new html pages during the time.

But it will not perform good enough when the html just contains a single page. If the user scroll quickly(probably by normal speed?), the reading system may not have enough time to pre-render. It will make the screen flash(blank content then loaded content) which is not very user-friendly.

I'm considering if there be some way can improve it. What do the reading system need to ensure the pre-rendering is having enough time. If user has enough pages to be read, reading system will has enough time to do pre-rendering job. So why not do we use a range of pages instead of triptych html?

For example, I assume that there should be 5-10 pages waiting for user to read. When the rest of pages is less than 5, (we can use the contentSize of the scrollView in next WebView) I initialize another webView to pre-render the next html. Then count the total pages. If not enough, do the same work again.

It just a preliminary idea. I don't know if that feasible.

When I run "carthage update --platform ios" on my terminal. It failed with exit code 65.

*** Building scheme "readium-lcp-swift" in readium-lcp-swift.xcodeproj
Build Failed
Task failed with exit code 65:
/usr/bin/xcrun xcodebuild -project /Users/cdsz_ios_dev3/ClassWizard/项目/GitDemo/r2-testapp-swift/Carthage/Checkouts/readium-lcp-swift/readium-lcp-swift.xcodeproj -scheme readium-lcp-swift -configuration Release -derivedDataPath /Users/cdsz_ios_dev3/Library/Caches/org.carthage.CarthageKit/DerivedData/9.1_9B55/readium-lcp-swift/74ce4880060c402a53a020ec7ef60cbaf99e35a7 -sdk iphoneos ONLY_ACTIVE_ARCH=NO BITCODE_GENERATION_MODE=bitcode CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES archive -archivePath ./ SKIP_INSTALL=YES GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=NO CLANG_ENABLE_CODE_COVERAGE=NO (launched in /Users/cdsz_ios_dev3/ClassWizard/项目/GitDemo/r2-testapp-swift/Carthage/Checkouts/readium-lcp-swift)
This usually indicates that project itself failed to compile. Please check the xcodebuild log for more details: /var/folders/x9/31mjtwpx06s8h52qchtd_mf80000gn/T/carthage-xcodebuild.mkZdCa.log
cdsz-ios-dev3tekiiMac:r2-testapp-swift cdsz_ios_dev3$

Then I checked the log:

/Users/cdsz_ios_dev3/ClassWizard/项目/GitDemo/r2-testapp-swift/Carthage/Checkouts/readium-lcp-swift/readium-lcp-swift/LcpSession.swift:11:8: error: module file's minimum deployment target is ios11.1 v11.1: /Users/cdsz_ios_dev3/ClassWizard/项目/GitDemo/r2-testapp-swift/Carthage/Checkouts/readium-lcp-swift/Carthage/Build/iOS/ZIPFoundation.framework/Modules/ZIPFoundation.swiftmodule/arm64.swiftmodule
import ZIPFoundation
^
** ARCHIVE FAILED **
The following build commands failed:
CompileSwiftSources normal arm64 com.apple.xcode.tools.swift.compiler
CompileSwift normal arm64
(2 failures)

It seems that the minimum deployment target of ZIPFoundation.framework was not set.

I noticed that "readium-lcp-swift" has changed ZIPFoundation's dependence 3 days ago.

https://github.com/readium/readium-lcp-swift/commit/74ce4880060c402a53a020ec7ef60cbaf99e35a7

These are all I knew by Now. How can I fix it?

Cartage won't build r2-lcp-wrapper-swift.
Xcode say:

ld:
library not found for -llcp
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I think it probably related to this issue

In order to facilitate RTL, i18n in general and the ability for apps to customize how they're deal with user settings, we're now moving to a new abstract model described in: https://github.com/readium/readium-2/blob/master/other/user-settings.md

User settings will be:

• based on a generic model
• contained in the in-memory object for a publication (which makes them potentially publication specific)
• injected by the streamer
• updated in the app using JS

I saw you removed LCP in Cartfile, but it's still in building phases as well as other dependencies.
As the result, it cannot be compiled if I want a fresh build. Probably, you still have the compiled frameworks under your Carthage folder. Not 100% sure.

After removing all the unused frameworks, it could compile and work.

EpubTest 0320 test: media overlays doesn't work.

To navigate between the bookshelf and the list of catalogs, we need tabs in the test app.

When an error occured trying to load the publication, or when there is no cover for a publication, we must set a default one.

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.

https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/DocumentPickerProgrammingGuide/Introduction/Introduction.html

How to reproduce:
Run the app on a iOS9 device, open a publication and swipe 3 page of the book.

What happen:
When the triptychView deallocate the previous webview, the following error happen.

Cannot form weak reference to instance (0x7f8d37040000) of class R2Navigator.WebView. It is possible that this object was over-released, or is in the process of deallocation.


(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
    frame #0: 0x0000000109b4075b libobjc.A.dylib`_objc_trap()
    frame #1: 0x0000000109b4089b libobjc.A.dylib`_objc_fatal(char const*, ...) + 195
    frame #2: 0x0000000109b5393e libobjc.A.dylib`weak_register_no_lock + 159
    frame #3: 0x0000000109b53f00 libobjc.A.dylib`objc_storeWeak + 358
    frame #4: 0x000000010a753bc4 UIKit`-[UIScrollView setDelegate:] + 256
    frame #5: 0x000000011ada7067 UIKit`-[UIScrollViewAccessibility setDelegate:] + 70
    frame #6: 0x000000010cb4888f WebKit`-[WKScrollView _updateDelegate] + 221
    frame #7: 0x000000010cb51d04 WebKit`-[WKWebView dealloc] + 210
    frame #8: 0x0000000109b550b8 libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 488
    frame #9: 0x000000010a76525a UIKit`-[UIScrollView _smoothScrollWithUpdateTime:] + 2943
    frame #10: 0x00000001100f8864 QuartzCore`CA::Display::DisplayLinkItem::dispatch() + 50
    frame #11: 0x00000001100f872e QuartzCore`CA::Display::DisplayLink::dispatch_items(unsigned long long, unsigned long long, unsigned long long) + 418
    frame #12: 0x000000010a027364 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
    frame #13: 0x000000010a026f11 CoreFoundation`__CFRunLoopDoTimer + 1089
    frame #14: 0x0000000109fe88b1 CoreFoundation`__CFRunLoopRun + 1937
    frame #15: 0x0000000109fe7e98 CoreFoundation`CFRunLoopRunSpecific + 488
    frame #16: 0x000000010fb88ad2 GraphicsServices`GSEventRunModal + 161
    frame #17: 0x000000010a698676 UIKit`UIApplicationMain + 171
  * frame #18: 0x00000001092f8cb7 r2-testapp-swift-DEBUG`main at AppDelegate.swift:29
    frame #19: 0x000000010dde792d libdyld.dylib`start + 1

an example of a feed using relative URLs: https://standardebooks.org/opds/all

• background and foreground of text not changing when changing the mode to sepia or night
• publisher default seems to not have any effect anymore
• font change is not being applied
• advanced settings not working except the page margins

some more info:
Before updating to the latest alpha, all we had was the following 3 css files which didn't contain any reference to other css files.

ReadiumCSS-before
ReadiumCSS-after
ReadiumCSS-default

we need to review the implementation and fix what might be missing, as it seem like several of the css files under modules are not being used.

If one opens the EPUB Test Suite 150 (Navigation) and then open the TOC, most of the elements of the TOC are rendered, but not all. In particular, the sub-category CSS class elements of the

Procedure:

1. Open the test document (see above)
2. Open the TOC
3. Observe that none of the sub-categories (e.g. landmarks, test-links, etc.) are rendered.

Test Environment:
iPad 5, 16 GB
iOS 11.0.3
R2 Test App 0.2 (2)

Problem occurs only in this context:

1. Open the user settings menu of test app
2. Open the control center, adjust brightness with its dedicated control
3. Dismiss the control center
4. The in app brightness slider value is wrong. We have to dismiss the user settings menu and open it again to have a correct value.

The solution should not be complicated, we have to catch the concerned event and then to update the brightness value of the slider.

we need to at least add some about info and copyright etc as well as version number within the R2 Reader.

When selecting an LCP file for download, the file is being presented in clear text instead of the selector to choose in which app to open.

iOS 9.3 - works as expected
iOS 10.3.1 - works as expected

ePub files still work as expected on iOS 11.3, 10.3.1, 9.4

Currently no matter the device we show just 3 books in a row. which is not ideal for larger screens like iPads

If I tap quickly several times on a cover, the book seems to "stack", be opened several times, one book appearing over the other. If I use the back action, the book isn't closed, but I "come back" to the "book below".

When loading an EPUB which is RTL (e.g EPUB Test Suite 130), the application does not use the right page progression directions. Instead, the page progression is LTR, just as in most western books.

Procedure:

1. Load the specified test book (above)
2. Page through the book.

Pages are LTR, not RTL.

Also, in the case of the book above, note that the cover is not properly displayed, but is half off the screen to the left.

Test Environment:
R2 Test App 0.2 (2)
iPAD 5
iOS 11.0.3
16 GB memory

each time a book is opened all entries of the TOC are being re-added to the previously parsed.
I noticed this on all test lcp books, and some other books I tested.
The sample books are fine.

On a "new instance" (after kill the process):

• import an epub without bitmap cover (e.g. epub30-test-300)
• imported epub duplicates the cover from another epub after displaying the correct front for a short time .
• import one more epub without cover and the display is fine.

It will become an issue for slow internet and big book. Looks and feels strange.

Also consider accessibility features, such as a little announcement.

Facets are usually handled either:

• as a scrollable list on top of a list of publications (SimplyE)
• or as an action opening a new view or a popover (iPad)

The current implementation is less than ideal since there's no way to go back and the UI could be improved.

Facets should only be displayed when the views has only publications (see #57).

@llemeurfr will have to decide between scrollable list or action.

For some reason if the feed failed to load, the app does nothing about it. We should implement some kind of error handling.