EBook

Do you know something we don’t?

Yes, how to do fat fingered typing!

You don’t notice the bugs until they bite.

I changed all of the magic numbers to defined constants (tidier), and for the lulz, reinstituted the previous code. Which now works fine.
Um.

Things like that really annoy me.

Oh, and I can’t use DDT (mine is 1.96) because it crashes with a data abort while doing the relocation stuff in between the initial entry breakpoint and the breakpoint when it gets to main().
It’s because DDT knows that I don’t like it.

Oh, and all the VDU text in DDT goes half-height afterwards. Absolutely repeatable. Because it knows I really don’t like that steaming pile of poop that is the interactive debugger…

Firstly thanks for yet another useful application.

Useful? Hmmm… I’m doing something wrong if people are calling my junk useful. :-)

and I get issues with errors like “File is either not EPUB or damaged”

Rename the file to something short and snappy. It seems that things get confused if the filename is too long, has commas, brackets, etc.
It’s not me – go to the command line and try *. SparkFS#<path>:$ (with the ‘:’ changed to ‘#’ in the path) and you’ll find it doesn’t work. If SparkFS can’t see it, I can’t see it.

“can’t read manifest/ too many manifests”.

I have bumped up the manifest array in order to be able to load We All Looked Up. It can now support 128 objects.

If you have any other EPUBs that don’t want to work, please send them to me (if not free and at your discretion) or give a link (if free) and I’ll see what I can do.

This is with SparkFS 1.45, RISC OS 5.35 (24th Aug 18) on an ARMX6.

Hmm, mine’s 1.44. Thanks for reminding me to update it.

Here’s a new version:

http://heyrick.ddns.net/files/ebook003b.zip

Here’s what’s new this time:

• Undid previous fix, as it now works the old way. Um…?
• Increased space for manifest/spine to 128 entries (was 64) so that “We All Looked Up” can be loaded.
• Replaced magic numbers with defined values.
• More tweaks to the parser to improve output (now recognises UTF-8 hard spaces as spaces).
• The green slider shows the current status of processing the input files.
  Now uses the hourglass to show the current status of each file as it is processed.
• Created a file icon for &AAE (EPUB) files, every bit as rubbish as the application icon, ‘cos I’m no artist…

Have fun!

Link fixed. Oops! :-)

Doug – thank you for the two epubs that you sent me. Unfortunately they are compressed in a version of Zip that SparkFS cannot handle.

A simple way of checking is to settype the files &DDC, and double-click. It will report that the central directory cannot be found. Using *ZipUseCentralDirectory 0 will change that to be that an unknown header was found.
The zip is either broken or some sort of non-standard format:

*unzip pg1342 -d pg1342new
Archive:  pg1342
warning [pg1342]:  1029 extra bytes at beginning or within zipfile
  (attempting to process anyway)
file #1:  bad zipfile offset (local header sig):  1029
  (attempting to re-compensate)
 extracting: pg1342new.mimetype      
error:  zipfile probably corrupt (segmentation violation)
*

The files, if you list the contents of the zip directory, have weird names: OEBPS/@public@vhost@g@gutenberg@html@files@1342@<a href="mailto:1342-h@1342-h-0.htm.html">1342-h@1342-h-0.htm.html</a>.
(and you’ll see Textile thought it was some sort of email address!)

Sorry, but neither SparkFS or GCCSDK Unzip want to touch this file.

Follow-up on the two books. Since you emailed them to me, I picked them up with my phone (and Samba’d them to RISC OS).

For pg25525, my file manager zip utility says invalid CEN header (bad signature), and for the other one it says expected CENSIC not found at entry 1 in central directory at end of zip file.
The standard Android file manager (Samsung incarnation) just said “Error” for both.
Both Lithium and E Reader Prestigio report an error trying to open them (set as .epub).

So, I think we can pretty much conclude that if neither RISC OS nor Android 8.something can open these, they’re either really non-standard, or actually broken.

Hi Rick,

Thanks for sorting the link.

As to the files then they were downloaded from Gutenberg, via your link further up, and one is Pride and Prejudice and the other Edgar Allan Poe so I can’t understand that?

If I change to &DDC I can see the files without any error but you are right they have weird names et but it is the EPUB link I have used both via RISC OS and on a PC.

On a PC opening up the epub download starts up a browswer and the file can be read.

This is really wierd as the other files, not Gutenberg ones, so are they changing things?

and one is Pride and Prejudice and the other Edgar Allan Poe so I can’t understand that?

I haven’t read Pride & Prejudice (sounds boring, but I listed it as it is “a classic”), and Poe I downloaded a few years ago.

so are they changing things?

I suspect it is likely the Google mentality. Here’s a fancy new zip format with baseline inferred hyperfractal compression, and screw everybody using traditional Zip software…

I’ve just fetched pg1342 from Gutenberg, and it’s a completely compliant ZIP that opens fine in SparkFS. Yes, the filenames are weird, but SparkFS remaps them and they work fine. Looks like a simple case of file corruption.

I concur with nemo. I’ve just fetched Alice in Wonderland, all of Poe, and Metamorphosis and they all work fine here (fetched with NetSurf).

The filenames are weird, and the formatting in the manifest is a bit different to everybody else, so…

http://heyrick.ddns.net/files/ebook003c.zip

It turns out that MuView is being naughty in allocating itself support for some filetypes that were not registered.
I tried to register type &AAE as EPUB, but Allocations got back to say that not only was that already allocated, but so were the other ones MuView wants to use.
EBook is now a registered application name (thanks Ben), and EPUB has been officially registered as type &A76.

Ok, tried that Alice in Wonderland via Netsurf download and get pg11/epub file.

Change to zip and opens Ok in SparkFS 1.45.

Change to &A76 use EBook 003c and get loads of errors.

Unable to find content SparFS#SCSI##SSD etc

Download via PC and transfer epub file and try again , same thing.

What the hell am I doing wrong?

What the hell am I doing wrong?

Clue in the Info window – somehow I managed to copy an old copy of !RunImage into the app before making to 003c archive.

It’s fixed now.

I guess you’re not the only one with fat fingers today. :-/

Brilliant, works now and thanks for the super work.

0.03c seems good for me!

I tried to register type &AAE

1. That’s not how allocations work
2. I have AAE as “OrUpgrd” whatever that is

That’s not how allocations work

I’m well aware of that. I was trying to see if the filetype used by MuView could be made official.

I have AAE as “OrUpgrd” whatever that is

Actually, every single one of the additional types used by MuView are already allocated. Good going, huh?

Well, there’s now an official EPUB type. The rest? That’s somebody else’s problem, I’m only interested in EPUB.

Gives an “abort on data transfer &0000807C” on VRPC + ROS402 on trying to run it.

Hmm, I wonder if that’s the same thing that screws up the debugger?

[edit, no, it isn’t]

EPUB has been officially registered as type &A76.

I’ve made myself useful and added it to the list. I haven’t put EBook in the Application column since it doesn’t technically “belong” to your app.

I’ve made myself useful and added it to the list.

Thanks.

I haven’t put EBook in the Application column since it doesn’t technically “belong” to your app.

Nowhere does the document imply the file has to “belong” to an application. It says Primary or example application that use files of this type. To that end, one could query type FF0 (what about ArcFax? PhotoDesk? etc), FD5, FC9, FB1, E1F, and one that really amuses me, DE2.

I’m not particularly fussed either way, I just think that the statement about what gets listed under “application” should be interpreted consistently. Either a lot more applications can be added to that list, or about half of them should be deleted. Me? I’m partial to adding NetSurf as an example of something that uses FAF. ;-)

abort on data transfer &0000807C” on VRPC + ROS402

That’s the zero init code that runs at the very beginning.

It seems RISC OS 4 isn’t smart enough to auto extend the Wimp slot, and it looks like I’m at the point where 96K is too small.

Edit !Run to increase the slot to 128K, it should now work for you.

It says Primary or example application that use files of this type.

Maybe I should actually read the text next time instead of just assuming what the column is for :)

I’m at the point where 96K is too small.

Or even 92K :)

It works quite nicely and I note the evolution of the font effects since the first release.

increase the slot to 128K, it should now work

Yes it does thanks.
On 1st epub I tried got a “Unable to load this book – the manifest contains too many entries” error.

Ditto 2nd + 3rd, but 4th worked fine!

There is a hardcoded limit of how many manifest entries can be handled – to save having to interpret the same data twice (once to enumerate, and once to actually process). Most of the books I’ve seen have “about twenty”(ish) entries in the manifest.

The limit was 64 entries, but I bumped it up to 128 because one book had ~67 entries.

What on earth has more than 128? Is that real or is it a parsing error?

What are the books that failed?

What are the books that failed?

One of ‘em was the new version of “Fingerprints of the Gods” by Graham Hancock:
Epub ISBN: 9781446410851 and the others were Hancock’s too.

Is there a problem with terminating italics?

I have AAE as “OrUpgrd” whatever that is

Wikipedia lists it as “Oregano upgrade”.