The just released 3.1 software Preview Release for K3 includes an improved layout for subscriptions. Navigation is a lot better now. Better late than never...

As a welcome side effect, the layout improvement applies to calibre-generated Fetch News items as well!

The just released 3.1 software Preview Release for K3 includes an improved layout for subscriptions. Navigation is a lot better now. Better late than never...

As a welcome side effect, the layout improvement applies to calibre-generated Fetch News items as well!

Thanks for reporting this, I was hoping it would Just Work. :)

G

Thanks for reporting this, I was hoping it would Just Work.
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).
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.
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.
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.

So are we doing something different to the sub periodicals?

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.

I find the new format MUCH easier to scan and read. It works just fine with my K3 and calibre.

Frank

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?

Has anyone tried the behaviour with paid amazon subscriptions?

I've been looking into this and have found:

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:
<?xml version='1.0' encoding='utf-8'?>
<ncx xmlns="http://www.daisy.org/z3986/2005/ncx/" version="2005-1" xml:lang="en">
<head>
<meta content="6f4b85b8-9278-43e2-a6aa-a995e0ed3953" name="dtb:uid"/>
<meta content="1" name="dtb:depth"/>
<meta content="calibre (0.7.45)" name="dtb:generator"/>
<meta content="0" name="dtb:totalPageCount"/>
<meta content="0" name="dtb:maxPageNumber"/>
</head>
<docTitle>
<text>Instapaper</text>
</docTitle>
<navMap/>
</ncx>

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
<navPoint class="chapter" id="ff83e450-3d2b-42e9-a233-9a8f90f9fd82" playOrder="0">
<navLabel>
<text>Front Page</text>
</navLabel>
<content src="Daily_Caller.html#eed_0/index.html"/>
</navPoint>

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
C:\Users\Nick\Calibre Library>ebook-convert daily.mobi dailydir1
1% Converting input to HTML...
InputFormatPlugin: MOBI Input running
on C:\Users\Nick\Calibre Library\daily.mobi
Parsing all content...
Forcing Daily_Caller.html into XHTML namespace
Referenced file 'feed_6/index.html' not found
Referenced file 'feed_2/index.html' not found
Referenced file 'feed_4/index.html' not found
Referenced file 'feed_3/index.html' not found
Referenced file 'feed_5/index.html' not found
Referenced file 'feed_0/index.html' not found
Referenced file '%20http%3a//twitter.com/Chris_Moody%20' not found
Referenced file 'feed_1/index.html' not found
Referenced file 'feed_10/index.html' not found
Referenced file 'feed_9/index.html' not found
Referenced file 'feed_8/index.html' not found
Referenced file '../2011/02/10/trump-at-cpac-points-to-white-house-run/' not found
34% Running transforms on ebook...
Merging user specified metadata...
Detecting structure...
Flattening CSS and remapping font sizes...
Source base font size is 12.00000pt
Cleaning up manifest...
Trimming unused files from manifest...
Trimming 'images/00002.jpg' from manifest
Trimming 'images/00001.jpg' from manifest
Trimming 'images/00003.jpg' from manifest
Creating OEB Output...
67% Creating OEB Output
OEB output written to C:\Users\Nick\Calibre Library\dailydir1
Output saved to C:\Users\Nick\Calibre Library\dailydir1
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.

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.
I've done that--Foreign Policy is one section. Running it throug ebook-convert to get an HTML version shows it's the same as a multi-section periodical, except there's only one section. In summary, the Instapaper file and the Calibre-generated file are very different--Instapaper uses H1 tags and Calibre uses ID tags to delineate articles. You seem to be suggesting Kindle auto-generates TOCs in all cases. If so, then the issue must be H1 versus ID tags, no?

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.
That's true--and this is how the prior Kindle s/w did it. The one drawback to this is (unlike previous Kindle s/w versions) you have to start at the first section and then move to the section index you want with the right button on the 5-way. Previously, you could pick the section you wanted and go there directly by putting the cursor under the number that indicated the number of articles in the section and clicking it. Now, if you click on the section name in the Sections & Articles view you get the first article in that section, and if you click on "View Articles List" you get the article list for the first section.

I've done that--Foreign Policy is one section. Running it throug ebook-convert to get an HTML version shows it's the same as a multi-section periodical, except there's only one section. In summary, the Instapaper file and the Calibre-generated file are very different--Instapaper uses H1 tags and Calibre uses ID tags to delineate articles. You seem to be suggesting Kindle auto-generates TOCs in all cases. If so, then the issue must be H1 versus ID tags, no?

No the TOC is embedded in the MOBI file in binary form. As far as I know, the Kindle *never* auto generates a TOC.

No the TOC is embedded in the MOBI file in binary form. As far as I know, the Kindle *never* auto generates a TOC.

In that case, how can I examine the MOBI TOC to see what the differences are?

In that case, how can I examine the MOBI TOC to see what the differences are?

You use a hex editor. Why do you think we love the MOBI format so much :)

But try PMing GRiker, he might have some tips on getting you started, this part of the MOBI output code is his.

Has anyone tried the "back" button behavior with a paid amazon subscription yet?
If it has the new behaviour then its a Kindle issue, otherwise it must be the way that Calibre codes periodicals in mobi.

I tried it with a free trial Amazon subscription to The Independent, and it works as expected, i.e., selecting an article from the new contents page, then pressing Back from the article, returns to the position you were previously at in the contents list. So far it's only been Calibre-generated periodicals that dump me back at the top of the first section.

Same results here as olliebean's. The back button works OK with Amazon subscriptions but not with calibre-fetched news.

The articles list generated by selecting 'View Articles List' at the bottom of the screen also appears to be broken in calibre news (it was initially working on my Kindle but not any more). Screenshots here (http://www.mobileread.com/forums/showthread.php?t=122361).

Does anyone know if there is a bug for tracking this issue in the Calibre bug tracker: http://bugs.calibre-ebook.com/query ? I tried searching for it but wasn't able to come up with anything.

wanderr, check this out:
http://www.mobileread.com/forums/showthread.php?t=123231

Just to let those interested in this topic that nickredding and I have worked out some solutions to this problem. Check here (http://www.mobileread.com/forums/showthread.php?t=142909) for details.