ePub reader for WinCE devices

[Marseille]

Originally Posted by Steve Jordan

Any PC should be able to be set up to open a particular file type with a particular application (Windows PCs set those up automatically, but you can change them). No reason you couldn't do the same with Zulu, as far as I know.

Typically, you need something extra to do that on WinMo (registry editor, or some tweaking program like sktools) as it's not an option in regular old file explorer. However, AFAIK, Resco does allow one to easily manipulate file associations.

[ondabeach]

Originally Posted by Jack Tingle

One of these days, I want an ePub reader that I can fire up File Explorer*, double tap an ePub file, it opens and I can read it. I actively don't want a library, a bookshelf, or an ePub editor. I don't particularly care about support of other file formats, either. Both Freda and ADE seem to think they need to manage things for me. I don't.

Will Zulu just open a file and let me read it? And not do anything else? I've never tried it, since your original website makes my eyes bleed if I look at it too long.

Regards,
Jack Tingle

*I actually use Resco, but it and the native app work the same way.

Hi Jack,

What you are talking about is called command line functionality which I added to ZR just last week. It hasn't been released yet as I am in the middle of a major update so that ZR can resize itself to fit wvga format (800 x 480 pixels) screens such as on the JE series readers.

Keep an eye on this forum or the download page on the site in about a week or so and you will then be able to open an ePub with ZR by double tapping in File Explorer, native or Resco. You will also be able to open an ePub from the command line using the syntax "Program Files\ZuluReader.exe yourbook.ePub".

If you don't want ZR to manage your library or extract cover images for the bookshelf then all you need to do is NOT put your ePubs in the "My Documents\ZuluLibrary" folder as ZR only "catalogues" ePubs found there (or the folder you specify in options).

JoinTech actually asked me to add that as they will be including ZR on the devices ex-factory and starting it just that way from their JTOS eBook UI. Most people opt to boot straight to WinCE and run ZR from an Icon, but it's the choice of the individual user and I'm happy to accommodate everyone's wishes if at all possible.

If you can bear with me until the update comes out then I will be keen for some more user input on ways to improve the program further.

Cheers and thanks for the input,

Steve.

[ondabeach]

Originally Posted by rfog

I've tested ZuluReader in my JE200 and it has a lot of problems.

• Main page is bigger than JE screen
• Some windows does not takes taskbar height and paints below taskbar
• Library does not support folders. If you select a folder, it does not shows books if books are into subfolders
• Fonts aren't antialiased
• Cannot adjust first line indent, no paragraph separation and interline
• Screen update is very slow. It takes about a minute to draw with a 10pt font and it paints line for line at very slow speed. This is the most important problem

Hi rfog, if you check out the the first post you'll see that the main focus of this thread is screen size and speed. I developed ZR with a HTC Touch Diamond as test device and it has vga (640 x 480) res and has pretty snappy performance.

I am actually rewriting the decode and render engines entirely to address the performance issue from two fronts. This is neccessary because the JE's are built for battery life as opposed to performance.

Once these two critical issues have been addressed then I will be actively seeking ideas and suggestions on other ways to improve ZR such as the formatting options you mentioned.

Cheers,

Steve.

[rfog]

Originally Posted by ondabeach

Hi rfog, if you check out the the first post you'll see that the main focus of this thread is screen size and speed. I developed ZR with a HTC Touch Diamond as test device and it has vga (640 x 480) res and has pretty snappy performance.

I am actually rewriting the decode and render engines entirely to address the performance issue from two fronts. This is neccessary because the JE's are built for battery life as opposed to performance.

Once these two critical issues have been addressed then I will be actively seeking ideas and suggestions on other ways to improve ZR such as the formatting options you mentioned.

Cheers,

Steve.

Steve, ZE is a promising program. :-)

To solve rendering speed problems most common techniques are double buffering (you can direct enable by reflection in .NET -at least in PC, I do not know if it works in CE) and background screen composing: you compose in background the next screens and brings to front via blt copy and double buffering.

The other things are less important. Other future improvement could be columns support.

I will stay tunned to test all your improvements. :-)

[Jack Tingle]

Originally Posted by ondabeach

What you are talking about is called command line functionality which I added to ZR just last week. It hasn't been released yet as I am in the middle of a major update so that ZR can resize itself to fit wvga format (800 x 480 pixels) screens such as on the JE series readers.

Keep an eye on this forum or the download page on the site in about a week or so and you will then be able to open an ePub with ZR by double tapping in File Explorer, native or Resco. You will also be able to open an ePub from the command line using the syntax "Program Files\ZuluReader.exe yourbook.ePub".

Very good. I'll be looking for it, thank you.

By the way, I looked at your website. It no longer makes my eyes bleed. Good choice.

Regards,
Jack Tingle

[ondabeach]

Originally Posted by rfog

Steve, ZE is a promising program. :-)

To solve rendering speed problems most common techniques are double buffering (you can direct enable by reflection in .NET -at least in PC, I do not know if it works in CE) and background screen composing: you compose in background the next screens and brings to front via blt copy and double buffering.

The other things are less important. Other future improvement could be columns support.

I will stay tunned to test all your improvements. :-)

Hi rfog,

Yes, rendering off screen is step one for sure. I have that happening now but it hasn't made anywhere near enough of an improvement yet. I will look into blt copying and double buffering in .net CF tomorrow. Most of the commonly used .net classes etc are available in compact framework, so hopefully those graphics methods will be supported as well.

The code module that decodes an ePub's content files into 'objects' (words and pictures etc) to be rendered is already quite fast even with the battery friendly processor of the JE's. Also, due to the architecture of this module, adding support for container type elements such as tables etc is only a formality as each object to be rendered can itself contain other objects with no limit on the depth of nesting. Each object has many properties, width, height, x & y render coordinates, font and image attributes and so on.

Then I create a graphics object to render onto like this:

pageBmp = New Bitmap(MaxWidth, MaxHeight)
Dim e As Graphics = Graphics.FromImage(pageBmp)

Next I use the e.graphics.drawstring and e.graphics.drawimage methods to render the objects to the 'off-screen' image according to their properties.

In .net on PC everything happens at a blistering pace, so much so in fact that I will be a able to add wysiwyg editing at a later date. The limited grunt in handheld devices however means that I'm going to have to use every trick in the book to speed the rendering module up as much as possible.

I'm hoping that wrapping the rendering module into a dll will improve the performace, that and converting it from VB into C, might have to shell out $100 and buy a code converter for that though.

Feel free to send any code snippets you think might help

Cheers,

steve.

[ondabeach]

Originally Posted by Jack Tingle

Very good. I'll be looking for it, thank you.

By the way, I looked at your website. It no longer makes my eyes bleed. Good choice.

Regards,
Jack Tingle

Thanks Jack, yes it was rather gaudy wasn't it. I think I was in the wrong line when they were handing out the graphics design genes

[Jim Chapman]

Originally Posted by ondabeach

Feel free to send any code snippets you think might help

Hi Steve,

Take a look at the off-screen bitmap manipulation in Freda (you can find the source code by following the link in the manual http://www.turnip.demon.co.uk/jim/fr...nual/index.htm). The important class to look at is BitmapCache - and the way that the GetBitmapForPage method uses it. What's going on is that if a bitmap is needed for a given page number (plus 'render' attributes like font face/size and page geometry) then that bitmap is drawn using drawstring/drawimage, *unless it's already been drawn and cached* ... in which case the bitmap is copied from the cache. There may be some ideas you can reuse there. Anyhow, I'm in the middle of re-writing all this code to remove various bits of ad-hoccery and improve the general level of abstraction - so the next version might be more re-usable.
One word of warning: I have found out the hard way that in .NetCF (depending on which Bitmap constructor signature you use) you will get either:
Device Independent Bitmap: you can create a large number of these, but they render very slowly; or:
Device Dependent Bitmap: these render acceptably fast, but creating more than ten of these will exhaust the resources in your GDI DLL (you'll get an OOM exception).
I found that 'ten' limit by trial and error - and it varies from phone to phone (and ROM to ROM).

Happy Hacking!

Jim

[ondabeach]

Hi Jim,

Thanks for info, I am rendering off screen with drawstring and drawimage already, the problem is in my html parsing code which I am rewriting now to speed things up.

Cheers,

Steve.

[ondabeach]

Hi all,

I have just put a new update for ZuluReader on the site. All screens now display correctly on the JE's 480x800 screen. Also, there is a new button which gives direct access to the backlight control when reading.

I will now focus on speeding up page turning for these and other slow devices.

Cheers,

Steve.