MobileRead Forums - View Single Post

davidfor · 12-28-2012, 07:35 PM

I don't know how I missed this yesterday.

This was briefly discussed a little while ago and I did some investigation. Someone with a trial subscription to a paper sent me the database from their device. It looks simple, but I didn't have enough test cases or the source paper to experiment properly.

When a book is processed into the devices database, rows are put into various tables. The "content" table holds a row for each book that describes it (location, type, title, author etc) plus a row for each chapter in it. The value of the ContentType column differentiates these rows. For most books, the book row has ContentType=6 and the chapter rows have ContentType=9. For the newspapers, the ContentType was 10 for all rows.

There were two other differences I saw. The files within the paper all had extension of "xml", which didn't seem to matter. The other difference was that they had multiple levels. All other epubs I have looked at have the container with files inside. The database rows for these had a reference back to the root. For the paper, the articles referred back to a sub-section row that referred back to section that referred back to the paper. There were at least three levels, I don't know if there were more.

As an experiment, I changed the ContentType to 10 for a book. When I disconnected, the book appeared in the Newspaper section and behaved as a newspaper. Or at least I assume it did as I had never read a newspaper on my Touch.

So, that sounds easy, set the ContentType to 10 and you have a newspaper. But, it isn't. The only way to get the book/newspaper into the devices database is to put it onto the device and let the device process it. It decides what type of book it has and what settings to use in the database to describe the book.

The next obvious thing is to create the rows when putting the book onto the device. Again easy, except that I don't know where some of the data comes from (mainly _NumPages). And, if I have a book on the device and in the database and replace it with a slightly changed version the device probably completely remove it. That last behaviour has change with firmware version but it means if I created the rows for a newspaper, it is likely to disappear when the device is disconnected.

After finding the above, I stopped and found other things to distract me

But, I have been doing some work on something and adding an option to "convert" a book that is already on the device to a newspaper would be easy. There is an issue with the driver, but that can be fixed later. And probably should be anyway.

I little experimentation is in order. I may send a PM to you later.

12-28-2012, 07:35 PM	#3
davidfor Grand Sorcerer Posts: 24,907 Karma: 47303748 Join Date: Jul 2011 Location: Sydney, Australia Device: Kobo:Touch,Glo, AuraH2O, GloHD,AuraONE, ClaraHD, Libra H2O; tolinoepos	I don't know how I missed this yesterday. This was briefly discussed a little while ago and I did some investigation. Someone with a trial subscription to a paper sent me the database from their device. It looks simple, but I didn't have enough test cases or the source paper to experiment properly. When a book is processed into the devices database, rows are put into various tables. The "content" table holds a row for each book that describes it (location, type, title, author etc) plus a row for each chapter in it. The value of the ContentType column differentiates these rows. For most books, the book row has ContentType=6 and the chapter rows have ContentType=9. For the newspapers, the ContentType was 10 for all rows. There were two other differences I saw. The files within the paper all had extension of "xml", which didn't seem to matter. The other difference was that they had multiple levels. All other epubs I have looked at have the container with files inside. The database rows for these had a reference back to the root. For the paper, the articles referred back to a sub-section row that referred back to section that referred back to the paper. There were at least three levels, I don't know if there were more. As an experiment, I changed the ContentType to 10 for a book. When I disconnected, the book appeared in the Newspaper section and behaved as a newspaper. Or at least I assume it did as I had never read a newspaper on my Touch. So, that sounds easy, set the ContentType to 10 and you have a newspaper. But, it isn't. The only way to get the book/newspaper into the devices database is to put it onto the device and let the device process it. It decides what type of book it has and what settings to use in the database to describe the book. The next obvious thing is to create the rows when putting the book onto the device. Again easy, except that I don't know where some of the data comes from (mainly _NumPages). And, if I have a book on the device and in the database and replace it with a slightly changed version the device probably completely remove it. That last behaviour has change with firmware version but it means if I created the rows for a newspaper, it is likely to disappear when the device is disconnected. After finding the above, I stopped and found other things to distract me But, I have been doing some work on something and adding an option to "convert" a book that is already on the device to a newspaper would be easy. There is an issue with the driver, but that can be fixed later. And probably should be anyway. I little experimentation is in order. I may send a PM to you later.