Intity Epubreader #2
Comments
|
Hi @dunxd glad you like it :-) I used the fork from intity as starting point because its distribution was kept up to date, but the original is still the Right now the "integration" with COPS is limited to 1 template + 1 zipfs.php file, with the actual functionality provided by the For annotations there's an option to share them with hypothes.is. Calibre has its own annotations table, but I haven't seen any example of integrating them with epubjs-reader. And I don't know if anything is available for bookmarks. |
|
Maybe one more remark: COPS has always taken a "read-only" approach for the Calibre database, and it has no custom database of its own. If we want to save/restore bookmarks and/or annotations with epubjs-reader (beyond local storage in the browser), it would need to be:
From PHP design perspective, I'm not a fan of any of those myself, except maybe options 1 or 2 - what do you think? |
|
I switched it on yesterday. Unfortunately it doesn't render nicely in a
mobile browser. See attached. All pages look like that in all books. This
is in Chrome on an Android phone. I suspect it is a display port issue.
Changing the width setting in Intity doesn't seem to fix it.
My preference now would be to have an option in the customise page, and set
this to default to Intity - on a mobile browser if someone cared they could
switch back to Monocle. If you agree this is a way forward I'll work on a
pull request.
Or maybe there is a fix to Intity to handle mobile browsers.
…On Mon, 11 Mar 2024, 9:31 am mikespub, ***@***.***> wrote:
Hi @dunxd <https://github.com/dunxd> glad you like it :-)
I used the fork from intity <https://github.com/intity/epubjs-reader> as
starting point because its distribution was kept up to date, but the
original is still the epub.js reader from futurepress
<https://github.com/futurepress/epubjs-reader>
Right now the "integration" with COPS is limited to 1 template + 1
zipfs.php file, with the actual functionality provided by the
epubjs-reader package, so any changes would need to come from the
upstream repos. I haven't explored all its capabilities, but from what I
can see local storage is what you use by default.
For annotations there's an option to share them with hypothes.is
<https://web.hypothes.is/>. Calibre has its own annotations table, but I
haven't seen any example of integrating them with epubjs-reader. And I
don't know if anything is available for bookmarks.
—
Reply to this email directly, view it on GitHub
<#2>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AD6W2HIHKYOOFWT3A5S2EFLYXV2YNAVCNFSM6AAAAABEPJ5OF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXHE3TGNJXG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Hi @dunxd I'm afraid the screenshot didn't make it via email. Some settings you can change in the epubjs-reader interface itself, like:
But I haven't tried most of those out, so if there's a particular configuration that works well for you let me know :-) |
|
Here is the screenshot. Every page looks like this on a mobile phone. Changing the width in the Intity settings from 800 to 100 doesn't change it, nor does changing the font size to 50%. This is when viewing the book with Chrome on a Samsung Android 14 phone. |
|
Huh - that's definitely not what we're looking for here :-( I'm not familiar with CSS but there seem to be some hard-coded calculations in main.css of the intity epubjs-reader like If you do find a work-around, it might be worth sending a PR to https://github.com/intity/epubjs-reader Otherwise you might be better off with Monocle for mobile viewing... |
|
I'll find some time to look into this, and if I find a fix, I will
contribute to Intity and hopefully it works its way into COPS that way.
That's better for everyone right?
In the meantime I'm reverting HA-COPS to monocle until we have this fixed.
…On Tue, 12 Mar 2024 at 18:57, mikespub ***@***.***> wrote:
Huh - that's definitely not what we're looking for here :-(
I'm not familiar with CSS but there seem to be some hard-coded
calculations in main.css of the intity epubjs-reader like
https://github.com/intity/epubjs-reader/blob/e9e7b8adb4246b9893ce1c71d3e4972b5862a1f2/dist/css/main.css#L58
If you do find a work-around, it might be worth sending a PR to
https://github.com/intity/epubjs-reader
Otherwise you might be better off with Monocle for mobile viewing...
—
Reply to this email directly, view it on GitHub
<#2>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AD6W2HPFIJSBVZEKXHD4UG3YX5FZ5AVCNFSM6AAAAABEPJ5OF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJSGMZTSNZUHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I really like the new epub-reader over monocle. Tomorrow I can test it with iOS ipadOS if you want. What I would really like in this epubreader is the ability to set the font-size (to larger) if possible. |
|
That'd be great, thanks. You're supposed to be able to change the font size via the settings in the sidebar on the left |
|
Thank you! I found the font setting in the sidebar. Just what I needed. Then on to my findings with iPhone and iPad.
|
|
Thanks for the feedback - I guess my hope of finding a decent replacement for monocle isn't quite realized yet... If anyone knows of other potential candidates please let me know. Pre-conditions would be:
Note: that last part seems to be a dead end so far, as apparently every viewer uses its own variation on the EPUB CFI standard - see comments and links at futurepress/epub.js#1358 |
|
Take a look at ../cops/vendor/mikespub/epubjs-reader/dist/css/main.css Not 100% perfect, but now it is usable. @dunxd |
|
Hmm - that's some interesting CSS going on. Not only in the CSS files, but I think there are some styles that are written in via the CSS at least to generate the columns that are displayed when the viewport is over a certain width. Lines 58 and 59 of width: calc(100% - 50px);
height: calc(100% - 90px);I just made this change using the inspector in Chrome, and then resized the browser window to see the effect at different sizes. At first glance that seems to work ok for smaller screens. On larger screens it starts to render the page in multiple columns so it looks like a book, and then on a wide screen it starts to look a bit too wide, which I guess is why they made them so large. I also don't know what it will look like when changing the font size and width setting in the reader's menu. With much fiddling it might be possible to get this working better using @media directives in the CSS to have different sets of these values for different screen sizes. I may find some time this weekend to look at this deeper, but if you try the above changes to main.css and let me know what you see that would help me know if I am onto the right thing. |
|
If I fork Intity's epubjs-reader how do I then get my fork of this repo to use it so I can test changes I make. I have still not figured out composer. I fear that I will eat up a lot of time just preparing to experiment - any pointers? |
|
Hi @dunxd here's a short description: https://getcomposer.org/doc/05-repositories.md#loading-a-package-from-a-vcs-repository What I tend to do for minor tweaks in libraries is
(*) you'll need to fork from https://github.com/mikespub-org/intity-epubjs-reader if you want to update the package, since https://github.com/intity/epubjs-reader doesn't have a composer package definition In this case, once you've done step 5 I can merge it into my fork too, and have it required in future COPS versions |
|
I player around with some of the settings in ../cops/vendor/mikespub/epubjs-reader/dist/css/main.css and I like for webbrowser (firefox), iPad and iPhone: change to The latest changes in https://github.com/intity/epubjs-reader make it look slightly nicer. On a very wide screen (I have a 3840x1600 monitor) it's perhaps a bit to much to comfortably read a book. ;-) |
|
I've created a PR on https://github.com/mikespub-org/intity-epubjs-reader which changes the CSS to detect screens with the same or smaller width as an iPhone X, and makes the viewer wider (100% - 60px) and the page turn arrows smaller. Thanks @marioscube for the suggestion - I've made it wider than you suggested. I've tested on my Samsung Galaxy A53 and it works great. Would be good to get feedback. Here is the css: @media only screen and (max-width: 812px){ /* This should catch smart phones with a screen width of, or narrower than, an iPhone X */
#viewer {
width: calc(100% - 60px);
}
.arrow span {
font-size: 24px;
}
}I didn't notice any difference for the height settings or the divider, so I took them out. Would love to hear how it works with your own phones. I'm not sure whether the same width is detected if the phone is in portrait or landscape mode. The rule could be further modified to detect that, but I wanted to start simple and get it right for the most common use case first. |
|
I've done some more tweaking to my PR. If you want to try it locally, it is now: @media only screen and (max-width: 812px){ /* This should catch smart phones with a screen width of, or narrower than, an iPhone X */
#viewer {
width: calc(100% - 60px);
height: calc(100% - 60px);
margin-top: 45px;
box-shadow: 0 0 5px rgba(0,0,0,.12), 0 5px 5px rgba(0,0,0,.24);
}
.arrow span {
font-size: 24px;
}
}This reduces the wasted space at the bottom of the screen, and looks better in landscape mode too. This only applies to smaller screens, so no change for iPads etc. |
|
Your second "tweak" is definitely better. It works well on both an iPhone 6s and iPhone 13 in portrait mode. On the iPhone 13 a margin-top of 30px looks slightly better. as does a width pf -80px. But that's a personal preference. In landscape mode this PR works as well on both the iPhone's. The divider only needs to be adjusted is you change something with height and there are 2 columns. |
|
Thanks for feedback. I'm not seeing the hamburger icon disappearing for any screen width in Chrome browser or Safari on a Mac, so perhaps I don't quite understand what you mean. The book title isn't displaying for me at all so I am not sure what would cause this to disappear. Could you share a screenshot? I've put the divider back in so it handles the height setting for smaller screen. You will only see this if you reduced the page width setting to narrow enough that it splits into columns on the phone screen - e.g. set it to 200. 100%-80px works does indeed look better with the visible page turn buttons. I tweaked the top margin so the top menu appears more vertically centered, but that, as you say, is very subjective. @media only screen and (max-width: 812px){ /* This should catch smart phones with a screen width of, or narrower than, an iPhone X */
#viewer {
width: calc(100% - 65px);
height: calc(100% - 60px);
margin-top: 40px;
box-shadow: 0 0 5px rgba(0,0,0,.12), 0 5px 5px rgba(0,0,0,.24);
}
.arrow span {
font-size: 24px;
}
#divider {
margin-top: 40px;
height: calc(100% - 60px);
}
}Some ideas for further improvement:
|
|
Thanks for testing this out :-) Regarding the book title, this was actually moved to a new metadata panel by @intity last week I believe - which might explain the confusion. I've merged the pull request and added a new tag so that you can update the package via composer if you want... |
|
See picture from my iPhone in portrait.
And at the bottom it does not look to nice. |
|
I think I need to clarify some details regarding the epubjs-reader fork. This is actually an experimental project for me to learn some concepts of JavaScript application development. To use this reader on a mobile device, you need to thoroughly develop style sheets and implement the additional |
|
Thanks for the feedback @intity - it's good to know what you're aiming for :-) As mentioned above #2 we are looking for a possible alternative for the very old Monocle-based epub reader that was included with COPS, and an The reason I started epubjs-reader from your fork was because it was kept up to date and you seemed to actively work on it, as opposed to the original epubjs-reader repo from futurepress. One of the challenges for COPS is that it's targeted not just for large screens, so if mobile devices or old e-readers are not on your roadmap at all, we may need to start from another fork or find some other starting point... |
|
As a user of COPS I must say that the new epub viewer based on epub.js is much, much better than monocle. It works very well with my iPhone(s) and iPad(s). Maybe not for really reading an epub. I have epub-reader apps for that. But to just view an epub to see if I want to start reading it, it just works. It's a good addendum to COPS. |
|
I am with @marioscube on this - @intity has made great improvements on the futurepress epubreader, and I believe with some tweaks we can get it working well for our use case. However, we haven't been able to test it against many different devices so there could well be snags waiting to bite us. What I get from this discussion is that the fork made by @intity is only being developed by them, and we should not hold any expectation about future development. That is fair enough. Would it make sense to make the @mikespub fork from the @intity one instead a fork from the futurepress version, and incorporate intity's changes which we like (of course with full acknowledgement and thanks).?This would allow us to incorporate any improvements to futurepress version in future (if they happen) or even contribute PRs to futurepress. That stops the version we use being dependant on continued maintenance by intity. Is that reasonable? |
|
As I see it we have 2 separate steps here:
|
|
Is adopting intity's epubreader.js without taking on the upstream epub.js reader any worse than sticking with monocle? It's not like monocle is more actively maintained. The last update was 7 years ago, and there are no forks with updates in the last five. In my opinion, the Intity refer is a cool improvement on the current browser based reader. I also note that in my opinion the browser based reader isn't a core function of COPS. As @marioscube said it is a nice addendum. Would it be so bad if we just adopted @mikespub fork of Intity, tweaked it for mobile phones (I think we are 90% there already) and accepted there will be no upstream development of Intity or epub.js ever. |
|
Does manager do anything other than force Similarly, I'm not sure the desirability of visible arrows is any different on a mobile phone than anywhere else. They didn't look bad the way you had them previously, and I think they can be made responsive through simpler mechanisms than JavaScript browser detection. I'm happy to do some work on this to try out different options - just run out of time this weekend. |
FYI, if you want to go back to one particular version, you can specify it directly in composer.jon (without the caret) "mikespub/epubjs-reader": "2024.3.31",Or if you want to remain in the 2024.3.* family, you can specify one more level down |
|
Major changes in the theme branch:
Example 1 (pre-config <script type="text/javascript">
const path = "https://s3.amazonaws.com/epubjs/books/alice.epub"
window.onload = (e) => {
epubreader.main(path, {
flow: "scrolled",
spread: {
mod: "none",
min: 800
}
})
e.stopPropagation()
}
</script>Note that if the Example 2 (pre-config <script type="text/javascript">
const path = "https://s3.amazonaws.com/epubjs/books/alice.epub"
window.onload = (e) => {
epubreader.main(path, {
arrows: "toolbar"
})
e.stopPropagation()
}
</script>This will force the toolbar arrows to be enabled for all devices, regardless of Example 3 (pre-config <script type="text/javascript">
const path = "https://s3.amazonaws.com/epubjs/books/alice.epub"
window.onload = (e) => {
epubreader.main(path, {
bookmarks: false,
annotations: false
})
e.stopPropagation()
}
</script>This will completely disable the Please test on your devices. |
|
New COPS release 2.5.4 using new intity-epubjs-reader tag 2024.4.9 I added the epubjs-reader settings as template variable that can be configured via $config['cops_epubjs_reader_settings'] = '{ in your COPS config_local.php file - see config_default.php for details. That way you can experiment with the different settings via your config_local.php file - but some of them may be cached by the browser |
The epubjs library provides only two managers:
For manager (2) to work correctly in |
|
In order for me to merge with the |
|
Hi @intity I'm not sure I get your point here. At this stage in COPS, I'm using template variables to fill in a template that looks like this (not updated here in theme yet): <!-- Initialize bookPath and settings -->
<script>
// string containing the initial book path - link / to get content from file /{component}
const bookPath = "{{=it.link}}";
// js object containing the initial settings (use text for template variable)
const settings = {{=it.settings}};
window.onload = (e) => {
epubreader.main(bookPath, settings);
e.stopPropagation();
};
</script>Where {{=it.settings} is replaced by the [text string defining the] js array in config_local.php: $config['cops_epubjs_reader_settings'] = '{
// ...
}';By default this will be an empty array, so if on your end you need to change the default handling of settings in epubjs-reader to cover some other issue, that's fine by me :-) |
|
BTW I'm thinking of loading the settings directly from a separate .json file instead in javascript, but that would mean another place where configurations are made. |
|
@mikespub If you want to save session data in the server database, then this will require an additional API implementation to upload the settings object in json format to the server. Ideally, the server should provide the |
|
Thanks @intity in the COPS use case there's no problem if the browser local storage overrides whichever settings are set initially in the template. After all, the idea is that COPS serves the books and epubjs-reader html/js/css files to the browser, and then epubjs-reader does its own thing in the browser :-) So if after the initial page load the user wants to change settings in the browser etc. when reading a particular book, and have these settings re-used the next time he/she continues reading it, that's perfectly OK. And COPS doesn't want or need to know what settings the user changed, so there's no need for a .json API to change/save settings - I was merely thinking to simplify the initial loading of the settings in index.html |
|
@mikespub I renamed the epubjs-reader repository to epubreader-js. Please update the links. |
|
No, the open book feature is not relevant in this case, as @marioscube mentioned earlier. I'll have a look at the link later this weekend when I re-package a new version, thanks |
Please, if you are doing a test, you need to write more detailed information:
Ideally this should be the |
|
That would probably be @marioscube rather than me :-) |
|
I will redo my "testing" probably over the weekend with the asked for information added. To test I will use the latest version of COPS. (not the git clone version) For devices I have:
Any things I should especially test? |
|
@marioscube |
|
I am able to give you something like this from my apache logs: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36 Is that what you want? |
|
@marioscube yes this is what I need. |
|
OK that is easy, I just look at my (apache2) logs. I could not find "navigator.userAgent" in the firefox console. Maybe I did something wrong. But now that's not needed. |
|
I did bundle optimization to reduce loading time. Also, I changed the package type to
Please test on your devices. |
|
I promised some quick testing and here it is: Server = Debian 12 BookwormWebserver = Apache/2.4.59 (Debian) Device = nucintoshOS = macOS 10.14.6 Font size (%) = 150 Layout = Scrolled Device = Apple iPhone 13OS = iOS 17.4.1 Font size (%) = 150 Orientation = Portrait Review = does not wrork properly for me
Orientation = Portrait Orientation = Landscape
Orientation = Landscape
Device = Apple iPhone 6sOS = iOS 15.8.2 Font size (%) = 150 Orientation = Portrait Review = does not wrork properly for me
Orientation = Portrait Orientation = Landscape
Orientation = Landscape
Device = Apple iPad 9.7"OS = iPadOS 17.4.1 Font size (%) = 150 Orientation = Portrait Review = just works
Orientation = Portrait
Orientation = Landscape
Orientation = Landscape
Device = Apple iPad Pro 1st generation 12"OS = iPadOS 16.7.7 Font size (%) = 150 Orientation = Portrait Review = just works (I personally do not like this mode)
Orientation = Portrait
Orientation = Landscape
Orientation = Landscape
|
|
@marioscube As you noticed, |
|
Ah, that was what you were looking for! Very deep in the Safari settings there is a setting REQUEST DESKTOP WEBSITE ON to which my settings on the iPad's say ON (slider to the right). |
|
I think to get maximum performance from the epubreder-js application, you need to move towards component-based assembly. That is, the configuration should be configured not at the application level, but at the webpack or rollup builder configuration level. This way, everything unnecessary will be removed from the final application build. For example, if you disable the |
|
@marioscube |
|
I don't agree with using the User Agent string to figure out anything about the device or the browser being used. It's terribly inconsistent, reliant on text parsing, can change with any update and prone to being spoofed for various reasons. Mozilla strongly advise against it. Better to use other information that is more reliable such as display size (which also works for windowed browsers) and user configurable preferences. Just because I am reading on a phone doesn't mean I like continuous scrolling as opposed to turning pages. How are you going to handle ereader browsers should they ever get up to date CSS and JavaScript support? We already found that the User Agent strings for these is not very useful (e.g. no difference across completely different models produced 10+ years apart). My suggestion is to use display size (easily accessed through CSS media queries) to apply settings likely to work well but override them with user preferences if they are set, and have reasonable fallbacks when neither apply. |
|
@dunxd I also added manager to the settings so that the user can use his own function to detect the device. For example: <script type="module">
import { Reader } from "./js/epubreader.min.js"
const isMobile = () => { /* your code for mobile device detection */ }
const url = "{{bookPath}}"
window.onload = (e) => new Reader(url, {
arrows: isMobile() ? "none" : "content",
manager: isMobile() ? "continuous" : "default"
})
</script> |
|
I've created a new release 2024.4.23 of this package for composer + updated the COPS template accordingly: mikespub-org/seblucas-cops@2.5.4...2.5.5 Any further tweaks of the arrows/manager/... settings for COPS can be changed in config_local.php if needed. Thanks to everybody for all the improvements and testing - I'm going to mark this issue closed for now. Please open any new issues here or better yet, directly at https://github.com/intity/epubreader-js/issues :-) |
I really like the look of the inity epub reader. I've taken a chance and made it the epubreader for HA-COPS.
Really nice table of contents, and bookmarks and notes! However, where does it store the bookmarks and notes? Looks like Local Storage in the browser. Very cool, but how persistant?
The text was updated successfully, but these errors were encountered: