Register Guidelines E-Books Search Today's Posts Mark Forums Read

Go Back   MobileRead Forums > E-Book Software > EPUBReader

Notices

Reply
 
Thread Tools Search this Thread
Old 12-29-2009, 12:52 PM   #1
mikelv
Developer of EPUBReader
mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.
 
Posts: 259
Karma: 1922
Join Date: Oct 2009
Device: none
New version 1.2.5 available

I've removed the attached 1.2.5, because it's now available at the Mozilla website: https://addons.mozilla.org/en-US/firefox/addon/45281

Here is what I changed:

Changes
- Downloaded ePub-files open now in a new tab or in the already opened EPUBReader-tab.

- Every unique ePub is now added only once to the ePub-Library. This works for every ePub which has been added with version 1.2.5.

- Font-color of the ePub-content can now be changed via the preferences window.

- Fault tolerance has been further improved. Now there are even less ePub-files which can't be read.

- EPUBReader is now multilingual. As first German translation has been added.

Bugfixes
- When more than one ePub-file was deleted from ePub-Library directly one after another, an error occured.

- On Unix-Sytems the bottom of the TOC was distorted.

Please let me know if you experience any problems and for the case you like the new features, I'm also very happy to hear from you .

I'll wait a bit until I upload this new version to the Mozilla website. The Mozilla reviewers are not so happen if you permanently upload new versions because they need to test it every time.

Last edited by mikelv; 01-11-2010 at 07:58 AM.
mikelv is offline   Reply With Quote
Old 12-30-2009, 04:30 AM   #2
johnnyS
Junior Member
johnnyS began at the beginning.
 
Posts: 5
Karma: 12
Join Date: Dec 2009
Device: iRex DR
Thanks and suggestions

Hi Michael,

Many thanks for the version 1.2.5!

Three features I find especially nice:

1) opening just downloaded publication in a new tab;
2) possibility to choose font color;
3) possibility to set margin width without any restrictions. It may sound weird, but on my 25 inch wide monitor I read .epubs having set margin width 450 px wide.

As always I have a head full of suggestions:

1) It seems to me that similarly to opening just downloaded publication in a new tab, the "Library" button should open library page in a new tab. It happens quite often that I want to open Library page but do not want to close currently opened publication.

2) Bookmarking is a great feature, but the problem is that before closing publication I do quite often forget to bookmark the last page I read. I would be great it before closing publication a dialog would be displayed asking "Would you like to bookmark currently opened page?"

3) If you would allow me to display some pedantry - I'm not very happy with current placement and behavior of the buttons.

First, it seems to me that buttons should display tooltips.

Second, some of the buttons are of more "systematic" nature (Preferences, Link to FAQ, Library and Download buttons), while others pertain to the reading of currently opened publication (Bookmark, Previous/Next, Increase/ Decrease font buttons). It seems that correct place for all those buttons of more "systematic" nature is the left pane, while in the content pane should be displayed only buttons directly relevant to the reading process of currently opened publication.

Third, I like Google Chrome browser's approach to space - to allocate as much space as possible to content and minimize chrome as much as possible. It seems that other browsers are taking this approach to space also. From this point of view it seems to me that the bottom bar in content pane is unnecessary and takes precious space which can be used for displaying publication. Of course, bottom bar contains much used buttons, but instead of Bookmark, Previos/Next, Increase/ Decrease font buttons keybindings can be used or functionality of some of these buttons can be placed in browsers toolbar (Bookmark and Increase/decrease font). It seems to me that it would be great if in Preferences dialog it were an option enabling to hide/display bottom bar of the content pane.

Thanks again and happy New Year for you and your family!
johnnyS is offline   Reply With Quote
 
Enthusiast
Old 12-30-2009, 12:05 PM   #3
DaleDe
Grand Sorcerer
DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.
 
DaleDe's Avatar
 
Posts: 9,616
Karma: 5071748
Join Date: Aug 2007
Location: Grass Valley, CA
Device: EB 1150, EZ Reader, Literati, iPad 2
For me the biggest outstanding issue is saving eBooks with useful names.

Dale
DaleDe is offline   Reply With Quote
Old 01-03-2010, 06:47 AM   #4
mikelv
Developer of EPUBReader
mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.
 
Posts: 259
Karma: 1922
Join Date: Oct 2009
Device: none
Thanks for your feedback Johnny!

Quote:
1) It seems to me that similarly to opening just downloaded publication in a new tab, the "Library" button should open library page in a new tab. It happens quite often that I want to open Library page but do not want to close currently opened publication.
Okay, I put it on the change list.

Quote:
2) Bookmarking is a great feature, but the problem is that before closing publication I do quite often forget to bookmark the last page I read. I would be great it before closing publication a dialog would be displayed asking "Would you like to bookmark currently opened page?"
Okay, I see. In my opinion it could be pretty annoying if you are asked every time if you want to set a bookmark when you close an epub. I put it on the change list in the new "ideas" section. I'll think about it, perhaps I'll have an idea how to implement this in a not annoying way .

Quote:
3) If you would allow me to display some pedantry - I'm not very happy with current placement and behavior of the buttons.

First, it seems to me that buttons should display tooltips.
Okay, I put this on the change list.

Quote:
Second, some of the buttons are of more "systematic" nature (Preferences, Link to FAQ, Library and Download buttons), while others pertain to the reading of currently opened publication (Bookmark, Previous/Next, Increase/ Decrease font buttons). It seems that correct place for all those buttons of more "systematic" nature is the left pane, while in the content pane should be displayed only buttons directly relevant to the reading process of currently opened publication.
The logic is the following: I've placed the buttons which don't belong to an opened epub, on the left side. One exception: the library button. The reason why I did this is, that the left frame can be closed, so the library wouldn't be accessible directly. And in my opinion direct access is important.

Quote:
Third, I like Google Chrome browser's approach to space - to allocate as much space as possible to content and minimize chrome as much as possible. It seems that other browsers are taking this approach to space also. From this point of view it seems to me that the bottom bar in content pane is unnecessary and takes precious space which can be used for displaying publication. Of course, bottom bar contains much used buttons, but instead of Bookmark, Previos/Next, Increase/ Decrease font buttons keybindings can be used or functionality of some of these buttons can be placed in browsers toolbar (Bookmark and Increase/decrease font). It seems to me that it would be great if in Preferences dialog it were an option enabling to hide/display bottom bar of the content pane.
I understand your point but I think, if you have a 25 inch display, 35 pixel for the navigationbar shouldn't be a problem . If you have a smaller display, you can hide Firefox itself completely (F11), so you have much more space for reading. So for the moment I won't change this, but I've put accessibility of buttons via keys on the change list because I think that this is handy in general.

Quote:
Thanks again and happy New Year for you and your family!
Thanks, the same for you!
mikelv is offline   Reply With Quote
Old 01-03-2010, 06:48 AM   #5
mikelv
Developer of EPUBReader
mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.mikelv once ate a cherry pie in a record 7 seconds.
 
Posts: 259
Karma: 1922
Join Date: Oct 2009
Device: none
Quote:
Originally Posted by DaleDe View Post
For me the biggest outstanding issue is saving eBooks with useful names.

Dale
Thanks for your feedback Dale! I'll change this in the next version.
mikelv is offline   Reply With Quote
Old 01-04-2010, 02:40 AM   #6
johnnyS
Junior Member
johnnyS began at the beginning.
 
Posts: 5
Karma: 12
Join Date: Dec 2009
Device: iRex DR
Hi Michael,

Quote:
In my opinion it could be pretty annoying if you are asked every time if you want to set a bookmark when you close an epub. I put it on the change list in the new "ideas" section. I'll think about it, perhaps I'll have an idea how to implement this in a not annoying way
It seems to me that the dialog which Firefox displays when user tries to close it with at least one tab open can be a good example of not annoying dialog. This dialog doesn't annoy, but sometimes prevents unintentional closing of browser window.

Quote:
I've placed the buttons which don't belong to an opened epub, on the left side. One exception: the library button. The reason why I did this is, that the left frame can be closed, so the library wouldn't be accessible directly. And in my opinion direct access is important.
I agree that direct access to Library is important. But why direct access to saving a publication as a file? - "Save as file" button is used rarely and is not needed at all on publication page. It seems to me that the functionality of saving publications as files properly belong to Library page. On library page "Save as file" buttons are already present.

But on Library page 2 things are needles: bottom bar because no button in this bar does anything on Library page; and left pane because it is empty on Library page.

It seems to me that it would be better if in Publication page "Save as file" button would be removed and in Library page both bottom bar and left pane would be removed.

Quote:
if you have a 25 inch display, 35 pixel for the navigationbar shouldn't be a problem . If you have a smaller display, you can hide Firefox itself completely (F11), so you have much more space for reading.
I do not find much use of full-screen functionality (F11) because while hiding Firefox's chrome you also hide much needed browser functionality such as tabs.

The question about bottom is not so much about saving 35 pixels but more about intrusiveness of EPUBReader's interface. From my point of view EPUBReader should not force on user the ways of navigating through and customizing of the publication. Ways of navigating and customizing should result from choices of publication authors and readers. Since EPUB format is essentially HTML + CSS and possibly some scripting, in many ways navigation and customizing can be built-in inside publication. For example, nothing prevents to add Previous/Next links inside each page; or, with the help of some scripting, to add font chooser or font size chooser, or style switcher allowing to choose among completely different page styles. In such cases some or all bottom bar buttons would duplicate publication's functionality or even interfere with it. (EPUB specification does not incourage scripting, but also does not forbid it - it says user agents "should not" execute scripts inside publication; it does not say "must not").

That's main reason because I advocate the concept that botton bar buttons and all bottom bar should be optional (shown by default but having possibility to be hidden).

Thanks again for your relentless efforts and amazing extension!

Last edited by johnnyS; 01-04-2010 at 02:45 AM.
johnnyS is offline   Reply With Quote
Old 01-14-2010, 06:54 AM   #7
Laisvunas
Enthusiast
Laisvunas began at the beginning.
 
Posts: 34
Karma: 10
Join Date: Nov 2009
Device: none
johnnyS:

Quote:
I like Google Chrome browser's approach to space - to allocate as much space as possible to content and minimize chrome as much as possible. It seems that other browsers are taking this approach to space also. From this point of view it seems to me that the bottom bar in content pane is unnecessary and takes precious space which can be used for displaying publication. Of course, bottom bar contains much used buttons, but instead of Bookmark, Previos/Next, Increase/ Decrease font buttons keybindings can be used or functionality of some of these buttons can be placed in browsers toolbar (Bookmark and Increase/decrease font). It seems to me that it would be great if in Preferences dialog it were an option enabling to hide/display bottom bar of the content pane.
johnnyS:

Quote:
The question about bottom is not so much about saving 35 pixels but more about intrusiveness of EPUBReader's interface. From my point of view EPUBReader should not force on user the ways of navigating through and customizing of the publication. Ways of navigating and customizing should result from choices of publication authors and readers. Since EPUB format is essentially HTML + CSS and possibly some scripting, in many ways navigation and customizing can be built-in inside publication. For example, nothing prevents to add Previous/Next links inside each page; or, with the help of some scripting, to add font chooser or font size chooser, or style switcher allowing to choose among completely different page styles. In such cases some or all bottom bar buttons would duplicate publication's functionality or even interfere with it. (EPUB specification does not incourage scripting, but also does not forbid it - it says user agents "should not" execute scripts inside publication; it does not say "must not").

That's main reason because I advocate the concept that botton bar buttons and all bottom bar should be optional (shown by default but having possibility to be hidden).
I agree with this line of reasoning. I seems to me that all our thinking about ebooks is too much influenced by the analogy of physical, linear book. Analogy of the website would serve us much better. And as in the websites there are no obligatory Previous/Next buttons (and some other) on the bottom of each page so in an ebook there is no need for such obligatory buttons on each page. As website authors are free to create navigation suitable for the site so ebook authors should be free to create navigation systems best suited for their publications.

I would like to press Johnny's suggestion to its limits: not only the reader should be able to fully customize the interface of EPUBReader in the sense that he should be able to open/close any available panes or remove/restore any buttons, but publication authors also could be able through some API to set default interface of the publication. E.g., if the publication author finds it useful he could set that the publication by default should be displayed with TOC closed/opened, with or without Previous/Next buttons, with or without font-size changer etc. I don't think that such API needed right now; I presented idea of it only to show that our current thinking about ebooks is quite limited and that Johnny is right saying that EPUBReader's interface should not pressuppose anything about what is needed or not needed for publications. In other words EPUBReader should give maximum freedom for creativity of ebook authors not only in the matters of content but also in the matters of interface.
Laisvunas is offline   Reply With Quote
Old 01-14-2010, 04:29 PM   #8
mrmikel
Book Twiddler
mrmikel ought to be getting tired of karma fortunes by now.mrmikel ought to be getting tired of karma fortunes by now.mrmikel ought to be getting tired of karma fortunes by now.mrmikel ought to be getting tired of karma fortunes by now.mrmikel ought to be getting tired of karma fortunes by now.mrmikel ought to be getting tired of karma fortunes by now.mrmikel ought to be getting tired of karma fortunes by now.mrmikel ought to be getting tired of karma fortunes by now.mrmikel ought to be getting tired of karma fortunes by now.mrmikel ought to be getting tired of karma fortunes by now.mrmikel ought to be getting tired of karma fortunes by now.
 
Posts: 2,028
Karma: 1424487
Join Date: Apr 2008
Location: Central Oregon Coast
Device: PRS-300
I disagree

In other words, read the book my way or else.

You must start at page one, must read the table of contents, etc.

You can not do what is convenient for you, but put up with learning yet another way of presenting content.

Michael, please continue along the lines you have been pursuing.

Nothing will kill ebooks faster than format and display splitting into 3000 ways to use the book all commanded by authors who developed their book on one device, making it unreadable on others.
mrmikel is offline   Reply With Quote
Old 01-15-2010, 02:30 AM   #9
Laisvunas
Enthusiast
Laisvunas began at the beginning.
 
Posts: 34
Karma: 10
Join Date: Nov 2009
Device: none
Quote:
Nothing will kill ebooks faster than format and display splitting into 3000 ways to use the book all commanded by authors who developed their book on one device, making it unreadable on others.
Ebooks will not be killed. But ePub format can. And nothing will kill ePub format faster as inflexibility of reading software/firmware and reliance of the publishers on the lowest common denominator of the existing software/firmware.

Despite growing acceptance the state of the support of ePub is appaling: except EPUBReader and Azardi no reader software have decent HTML support and except EPUBReader no reader software has scripting support. That means if you will publish something more sophisticated than text with paragraph and image tags it will necessarily be displayed incorrectly in most ePub reader software.
Laisvunas is offline   Reply With Quote
Old 01-15-2010, 10:39 AM   #10
DaleDe
Grand Sorcerer
DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.
 
DaleDe's Avatar
 
Posts: 9,616
Karma: 5071748
Join Date: Aug 2007
Location: Grass Valley, CA
Device: EB 1150, EZ Reader, Literati, iPad 2
Quote:
Originally Posted by Laisvunas View Post
Ebooks will not be killed. But ePub format can. And nothing will kill ePub format faster as inflexibility of reading software/firmware and reliance of the publishers on the lowest common denominator of the existing software/firmware.

Despite growing acceptance the state of the support of ePub is appaling: except EPUBReader and Azardi no reader software have decent HTML support and except EPUBReader no reader software has scripting support. That means if you will publish something more sophisticated than text with paragraph and image tags it will necessarily be displayed incorrectly in most ePub reader software.
While ADE (Adobe Digital Editions) has its faults it is much better than your dire message above. Calibre is also much better than you have indicated.

Dale
DaleDe is offline   Reply With Quote
Old 01-16-2010, 05:13 AM   #11
Laisvunas
Enthusiast
Laisvunas began at the beginning.
 
Posts: 34
Karma: 10
Join Date: Nov 2009
Device: none
Quote:
While ADE (Adobe Digital Editions) has its faults it is much better than your dire message above. Calibre is also much better than you have indicated.
Well. I agree about Calibre but not on Digital Editions. Digital Editions use for rendering HTML and CSS an engine which is neither Webkit nor Gecko nor Trident nor Presto; that means that you in principle cannot expect quality rendering of HTML and CSS.
Laisvunas is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
New version 1.2.9.0 available mikelv EPUBReader 7 07-19-2010 11:10 AM
New version 1.2.6 available mikelv EPUBReader 28 04-28-2010 01:00 AM
Version 1.2.3 Laisvunas EPUBReader 1 12-11-2009 06:38 AM
New version available mikelv EPUBReader 17 11-28-2009 01:24 PM
V2 Version 2 THJahar HanLin eBook 5 01-21-2007 05:04 PM


All times are GMT -4. The time now is 10:35 PM.


MobileRead.com is a privately owned, operated and funded community.