I'm not sure that it works as advertised for calibre output. Either that, or there are some bugs in the Kindle s/w. Following are excerpts from the Kindle release notes, and what happens with calibre-generated newspapers. (I don't have any Amazon subs to compare to).

Quote:

In the Sections & Articles view, you see the headlines of all the articles in each section. To see the Articles List of a particular section, navigate using the 5-way to View Articles List at the bottom of the screen.

This always takes you to the articles list for the first section. There isn't any way to go directly to the articles list for a specific section--you have to start at the first section and use the "right" click of the 5-way to move to successive sections.

Quote:

To navigate to a particular article within a section, use the 5-way controller to underline the section title and then press the 5-way to select. To dismiss this view and return to where you were last reading in the magazine or newspaper, select "Close Sections List" located at the bottom of the screen.

This doesn't make sense. If you underline the section and press the 5-way select you get the first article in the section. The is no "Close Sections List" and pressing the back button always takes you back to the sections and articles view, but always the first section--annoying if you were looking at the third article in the fourth section--now you have to click back to the fourth section to continue.

Quote:

Selecting the number to the right of the section title will take you to a list of articles found within that section.

Doesn't work--the section title and the number of articles are no longer separate and so you can't click on the number.

I'm doubtful that this faulty behavior has anything to do with calibre--more likely bugs in the Kindle s/w (it is after all, an early release). If anyone with knowledge of the MOBI format generated by calibre thinks otherwise, please chime in. Overall it's a minor improvement (the sections and titles display) but the behaviour of the back button is a real disappointment.

I'm doubtful that this faulty behavior has anything to do with calibre--more likely bugs in the Kindle s/w (it is after all, an early release). If anyone with knowledge of the MOBI format generated by calibre thinks otherwise, please chime in. Overall it's a minor improvement (the sections and titles display) but the behaviour of the back button is a real disappointment.

Yes, I'd come to rely on the Back button with the old layout - but I didn't find it very pleasant to do so. It always felt like a workaround to me, rather than a navigation feature Amazon had consciously took into account when designing the layout.

Back does now what it always has: it jumps to the page, but does not restore the cursor position. No matter how you navigate to a given page, the cursor will always be on the 'default' hyperlinked item (usually the first hyperlink on the page).

Your suggestion that it should restore the cursor position if you use 'Back' to get there is quite reasonable, and if put to a vote, I'd vote for it. But you'd have to convince Amazon it is a bug, and they'd probably argue they were just being 'consistent'. This is one of a number of subtle navigational issues they could be addressing, but they seem to have other priorities.

pressing the back button always takes you back to the sections and articles view, but always the first section--annoying if you were looking at the third article in the fourth section--now you have to click back to the fourth section to continue.

This is really annoying BUT doesnt seem to happen on my Amazon sub old copy of the NY Times.

Yes, I'd come to rely on the Back button with the old layout - but I didn't find it very pleasant to do so. It always felt like a workaround to me, rather than a navigation feature Amazon had consciously took into account when designing the layout.

Back does now what it always has: it jumps to the page, but does not restore the cursor position. No matter how you navigate to a given page, the cursor will always be on the 'default' hyperlinked item (usually the first hyperlink on the page).

Your suggestion that it should restore the cursor position if you use 'Back' to get there is quite reasonable, and if put to a vote, I'd vote for it. But you'd have to convince Amazon it is a bug, and they'd probably argue they were just being 'consistent'. This is one of a number of subtle navigational issues they could be addressing, but they seem to have other priorities.

The BACK button always did return to the previous cursor position (in the section list or article list), so what they have done with the new release is a departure from what they have done in previous releases. Also, if I access an article from the article list (versus the sections & articles preview) the back button returns me to the correct cursor position--in other words, that behaviour was retained.

Look at it this way: when I click the back button on my web browser I don't go back to the top of the previous page--I go to the place on the page from whence I came. The natural and expected behaviour of BACK is to go back to where you came from, not to the top of the page you came from. I've emailed Amazon on their feedback line and I'm hoping they will address this.

This is really annoying BUT doesnt seem to happen on my Amazon sub old copy of the NY Times.

So are we doing something different to the sub periodicals?

Interesting--are you sure? Kindle docs are, after all, merely HTML files. The BACK button is (or should be) equivalent to your web browser's back button. There's no link from your current page back to where you came from--it's up to the browser (Kindle) to remember that. I don't see how the structure of the NYT subscription file could affect that.

Interesting--are you sure? Kindle docs are, after all, merely HTML files. The BACK button is (or should be) equivalent to your web browser's back button. There's no link from your current page back to where you came from--it's up to the browser (Kindle) to remember that. I don't see how the structure of the NYT subscription file could affect that.

Similar to glanyrafon, I have an Instapaper feed generated by clicking the Kindle link on their website and BACK works correctly. I've generated the same content via the Instapaper.com recipe in Calibre and the BACK button does NOT work correctly. It also appears not to work when using the BBC News and Telegraph.co.uk Calibre recipes.

Similar to glanyrafon, I have an Instapaper feed generated by clicking the Kindle link on their website and BACK works correctly. I've generated the same content via the Instapaper.com recipe in Calibre and the BACK button does NOT work correctly. It also appears not to work when using the BBC News and Telegraph.co.uk Calibre recipes.

I've never used Instapaper, but I was under the impression it saves web pages for viewing, not entire web sites (such as the news feeds created by calibre). So, how can the operation of the back button with a web page saved by Instapaper be compared to the operation of the back button with a calibre news feed?

I've never used Instapaper, but I was under the impression it saves web pages for viewing, not entire web sites (such as the news feeds created by calibre). So, how can the operation of the back button with a web page saved by Instapaper be compared to the operation of the back button with a calibre news feed?

It does save pages (or links) for viewing later. In the same that Calibre assembles these into a mobi document via an RSS feed, there's a link on the Instapaper website that dynamically creates a mobi for you. So, I can flag pages to be 'read later' over the course of a day, then using the Kindle's browser trigger a mobi to be created and delivered via WiFi/3G when I'm going home on the train. The reason I used it as a test is that in theory you are using the same underlying content to generate what should be very similar mobis using two different methods. In this case the Instapaper generated ones seem to work correctly with the BACK button and the Calibre generated ones don't.

Yes, the new format might be miles better but the new behaviour of the "back" button is frustrating.
If you are scanning a few pages deep in a non-default section and hit the "back" button, the cursor returns to article 1 of the first (default) section and you have to start your scan all over again.

Like a previous poster I tried sending instapaper articles directly from the instapaper website (not calibre) and the "back" button remembered the location of the cursor (the same as the original behavior).

So is this new behaviour of the "back" button only related to Calibre periodicals?

1) Instapaper files (sent from Instapaper) have a single section with the captured pages appearing as articles within that section. The BACK button does indeed return from an article to the corresponding cursor position on the Sections & Articles view.

2) If I convert the Instapaper MOBI file to HTML using ebook-convert I find the generated toc.ncx file to be devoid of any table of contents info. Specifically, this is all I got for an Instapaper file with 6 articles:

I also noted that the HTML file uses H1 tages for the article titles, and I'm surmising that the Kindle is auto-generating the table of contents from the H1 tags. If I open the Instapaper MOBI file in Calibre or Mobipocket reader there is no table of contents.

I've looked at the output from Calibre, using ebook-convert to take it from MOBI to HTML. What I've found is Calibre doesn't use H1 to identify article titles--it generates a complete toc.ncx file which references articles using ID labels.

There is a strange error in the ebook conversion from MOBI to HTML for files with more than one feed (i.e. section). The references to section TOC's in toc.ncx end up looking like

Note the missing "f" in ="Daily_Caller.html#eed_0/index.html" it should be ="Daily_Caller.html#feed_0/index.html." During the conversion, ebook-convert spat out a bunch of file not found messages, as in

I'm not sure if this is representative of a fault in the MOBI file or in ebook-convert to HTML.

Any suggestions from MOBI experts would be appreciated. There is definately something wrong somewhere, and perhaps it is in Calibre after all, if only a mismatch between how the Kindle handles MOBI periodical files and how Calibre structures them.

MOBI files contain a compiled version of toc.ncx that ebook-convert will not convert. The toc.ncx generated by ebook-convert is from the embedded TOC in the MOBI file, which is just a flat list of normal HTML links. Presumably Instapaper doesn't generate the embedded HTML toc.

In any case that is irrelevant, as the embedded HTML toc is not used by the Kindle for periodicals. Try generating a calibre periodical for a news source with only one section to compare with the Instapaper one.

The Instapaper test that I was running had just one section and three articles in both the website and Calibre generated versions. BACK worked as expected in the website version but not in the Calibre generated one. I've been trying to find a way to extract and compare the two mobi's without interfering with the content. mobiunpack.py v0.23 is as close as I've got but this doesn't extract toc.ncx. Does anyone know of a tool to extract the ncx as-is? Apologies if that's an obvious question but I'm still pretty new to this.

Incidentally, much as I like the look of the new 'Sections and Articles' list, I've found that if you click on 'View Articles List' at the bottom, then you can page through and navigate off to individual articles quite happily from there and BACK does return you to the correct point. The layout isn't quite so pretty but it might make life easier depending on how you navigate round your periodicals.