Freda - ebook reader program for Windows Mobile
 

[UPDATE: See https://www.mobileread.com/forums/sho....php?p=1003453 in this thread for an updated version of the program]
I've written a program for reading eBooks on Windows Mobile devices. It can read txt, html and (DRM-free) ePub files. Screenshots attached.

The program is called 'Freda' - short for 'free reader', since it is free software (both in the sense of 'free beer', as I am not charging for it, and in the sense of 'free speech', as I am licensing my code under the GPL).

It's in on general release now, so please download it and let me have any feeback.

The program uses three third-party libraries, DotNetZipLib, OpenNetCF and the Majestic-12 HTMLParser library; all are licensed on terms permitting their redistribution for commercial and non-commercial purposes. More information is here

Happy reading!

Very nice. I would love to try it... but alas the only thing my cell phone does is make and receive phone calls. Yea, lame I know.

Thanks for all your great work.

BOb

I also have the Touch Pro2. Over the weekend I am trying out several of the new 6.5 ROMs with Sense 2.5 and will check out your program after settling on the most functional and stable version.

Does the program not support hard page breaks, centred text, full justification, etc? I'm sure that Dickens screen shot, in particular, should have all of these!

Harry, are you just looking for perfection or demanding it? :rofl:

You are probably right but I suspect Dickens will survive the lack. Of course, like pilotbob, my cell phone only is useful for making and receiving telephone calls (and rarely that as I rarely ever turn it on), so I'm sure the lack of dickensian perfection won't bother either my cell phone or me.

Neither. Just trying to ascertain what ePub formatting capabilities the program supports, because I have a Windows Mobile Smartphone myself, and would love to have a decent ePub viewer for it. Basic formatting, though, such as support for centred text, I'd personally consider to be on the verge of "essential".

[note: all these points are addressed in release 1.0: see page 6 of this thread]
Yes it supports centred text alignment, as well as left, right and fully justified. It follows the directives in the ePub document itself. If there's a demand for it, I could add a feature whereby the user could over-ride (i.e. "justify paragraph text even if the ePub says not to"). Those with a strong view, please message me, and I will consider it.

In terms of full page breaks, it will insert a full page break at the start of a chapter (this being the normal way that the ePub format signals a page break).
As it stands, the program renders the <br> tag as a centred "=O=" followed by a line break. I did that because I reckoned that by and large it was better than adding loads of page breaks (some ePub books make pretty heavy use of <br> breaks). But if there is a lot of demand for rendering them as page breaks, it's an easy option to add. Anyone with a strong view either way, please message me.
[see below for correction - I mistook hr and br]
Cheers,

Jim

What defines a chapter?

Page-breaks are generally handled by the CSS (page-break-before).


Edit:

So, I got curios and it looks nice and is fast!

But, I noticed two things.

1. I got two Freda icons in my program files...
2. It completely ignores my CSS.

I do like to know when a chapter starts, so I added a space above my chapter (margin-top or padding-top, I'd have to check). I also added a space between my chapter number and chapter name and a space between my chapter name and the actual text (see below).

I get this as follows:

The CSS is rather important to me, as I added some extra's in there to make the epub readable (like margins and full justification, which it completely ignores). It also completely ignores my center justification.

Add those, and you've a really nice, light, ereader application for epubs!

In the epub format, I treat each separate file in the archive as a separate chapter.

[note: all these points are addressed in release 1.0: see page 6 of this thread]

As for the CSS definition of page break, I've seen it mentioned in the latest version of the OPF standard, but I haven't seen it used in many actual ePub documents 'in the wild'. The whole question of CSS format definition is something I will be taking a look at anyway as I further develop the program - and if anyone can point me at an ebook-provider who is already making heavy use of CSS, I will look at it all the more urgently ;-)

Cheers,

Jim

That sounds excellent. I'll definitely have a play with it and give you my feedback. Thank you very much for making this available!


I don't follow your logic there. A <br> is a simple line break, is it not? If I have in my ePub source: "A<br>B<br>C" then I'd expect to see just:

A
B
C

on the screen.

Harry,
Sorry my bad - I meant <hr> not <br>.
I render <br> as a line break.
Apologies for the confusion!
Jim

Thanks - that makes sense now. This is sounding better and better; I'll definitely give it a thorough test.

Don't know any, but I have my ebook sources so that I can make both mobipocket and epub books from the same source. But the fact that nothing of my CSS gets carried through, is what is a major dealbreaker for me. I do use an "external" CSS (aka, not style inbedded in my source HTML).

Hi,

Do you have to install it on main memory of your device, tried it on my storage card and would not open...

Jay

[note: CSS stylesheets are implemented in release 1.0: see page 6 of this thread]
Hi Sweatpea,

Thanks for the feedback. Right now, the program basically ignores formatting provided via CSS styles - so if you want to specify alignment etc, you need to use the regular XHTML tags (align ... and so forth).

I am working on CSS formatting and very much open to ideas, so do share (preferably by sending me sample ePub documents with notes re how you'd hope to see them rendered).

Given that my target platform is the windows phone form factor, I am always going to want to simplify the formatting - for example I might not leave a wide top/bottom margin even if the formatting says to, simply because I don't have that much screen real-estate available, and I'd want to err in the direction of fitting a decent amount of text onto the screen, even if it meant that I wasn't strictly faithful to the author's formatting intentions.

That's going to be a matter of judgment though, and I'm keen to hear the opinions of my target market - so do give me your thoughts.

Thanks,

Jim