Bookshelf | Reports | Community | KDP Select

Home » Amazon KDP Support » Ask the Community » Formatting

Thread: LOOK INSIDE preview not the same as on Kindle Previewer


Reply to this Thread Reply to this Thread Search Forum Search Forum Back to Thread List Back to Thread List

Permlink Replies: 52 - Pages: 4 [ Previous | 1 2 3 4 | Next ] - Last Post: Dec 5, 2017 8:48 AM Last Post By: Salamander Mall... Threads: [ Previous | Next ]
booknookbiz

Posts: 4,210
Registered: 03/04/10
Re: LOOK INSIDE preview not the same as on Kindle Previewer
Posted: Feb 5, 2016 1:13 PM   in response to: Notjohn in response to: Notjohn
Click to report abuse...   Click to reply to this thread Reply
Notjohn wrote:

Hitch was warning us against unclosed html tags in our book des*cript*ion. Get your html validated, and you will have no problems.

Good luck! -- NJ


You're quite correct, I was.

BUT:

Here's the problem with your statement. While I concur, 100%, that people should validate their HTML/XHTML and CSS, absolutely, the problem here is that there is no such thing as a W3C validator for proper eBook HTML. In other words, as we all know, just because something passes at W3C, in HTML/CSS, doesn't mean that it's supported in an eBook. Or, for that matter, in the LI. My guys/gals and I have done some experiments, and we know that there are indeed certain things you can do, to affect the outcome at the LI, but none of those things relate, really, to "valid" HTML or not. It's about thinking a bit outside of the box, is all.

Let's not forget, speaking of validating, that media-queries, for example, will cause an ePUB to crash and burn at ePUBcheck. Nonetheless, they are perfectly valid HTML.

Here's another example: I can embed audio and video in a MOBI. Easy-peasy. I can put the absolutely correct tags, CSS, etc., in my MOBI. All of those things will pass validation at W3C. But...will they pass intake at the KDP? Will they work, in the LITB? H3lls, no.

That's my point. Yes, 100% valid HTML is good. Great, even. 100% valid CSS, ditto. But the set of valid HTML/CSS is far, far greater than the set of HTML/CSS that will work a) in a KindleBook, b) in a PRC/MOBI, c) in an ePUB, d) in the LookInside.

So we can't say, apodictically, that a valid set of HTML and CSS will always result in a perfect LI. We simply can't. There are too many outliers for that to be dead spot on. (I mean...what about image sprites? What about "position: fixed?" Or Absolute? Or Static?

Nay, nay...there are more things in CSS Heaven and Earth, Horatio, than are dreamt of in your Valid HTML philsophy. :-)

I'm enjoying the h3lls out of the discussion, however. But let's not get sidetracked into an argument. It's a worthwhile discussion to have, mind you.

Best regards, as always!

Hitch
We produce ebooks
Feefo Gold Trusted Merchant Accreditation 2016
See our real customer reviews here: http://bit.ly/1Jz4EKz
An INScribe Preferred Conversion Partner
http://www.booknook.biz/
Follow me on Twitter: @BookNookBiz
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur."
  • Red Adair
William Thompson

Posts: 1,146
Registered: 07/06/14
Re: LOOK INSIDE preview not the same as on Kindle Previewer
Posted: Feb 5, 2016 2:45 PM   in response to: booknookbiz in response to: booknookbiz
Click to report abuse...   Click to reply to this thread Reply
Hitch...So what you're perhaps saying is that you cannot absolutely say that all problems occurring in LITB are simply due to improper or poor HTML thus inferring that even with perfect HTML Validation that works in the sold ebook, you could also still get a poor LITB outcome. And in just a simple, reflowable e-book which is not Epub 3 or fixed layout, is it then safe to assume that any errors arising in LITB would mainly -- about say 95% of the time -- be caused by poor ebook HTML format or caused by an incorrectly formatted Author Central profile or a mixture of both?

And another short question for you if you wouldn't mind which is way off point. After finally passing epubcheck I've noticed that whenever I test my epub ebook on Kindle upload with the Kindle Preview at Step 6, the emulation on all Kindle devices passes with flying colours, whereas the emulation for iPhone and iPad always has errors that differ and are not consistent. Generally, for chapter headings on iPad I get left aligned chapter headings rather than centered as they should be. On the iPhone emulation I get bold, centered or left aligned chapter headings with a larger font size than I have set. I also still implement empty span style bracketing for all major centered headings due to an old Apple epub problem that Liz Castro reported on and solved ages ago. All my styling of major centered headings involves just one paragraph style with no additional span styles for that paragraph(except for the empty span style bracketing). Also, all the styles used in my chapter headings or main headings involve Heading 1 or Heading 1 inheritance. I myself suspect that Kindle's Apple device emulations somehow renders Heading 1 quite differently and oddly.

Is Kindle's emulation of Apple's iPhone and iPad on Kindle Preview at Step 6 completely accurate and to be trusted or should I just ignore it as inaccurate emulation by Kindle?
booknookbiz

Posts: 4,210
Registered: 03/04/10
Re: LOOK INSIDE preview not the same as on Kindle Previewer
Posted: Feb 5, 2016 5:14 PM   in response to: William Thompson in response to: William Thompson
Click to report abuse...   Click to reply to this thread Reply
William Thompson wrote:
Hitch...So what you're perhaps saying is that you cannot absolutely say that all problems occurring in LITB are simply due to improper or poor HTML thus inferring that even with perfect HTML Validation that works in the sold ebook, you could also still get a poor LITB outcome. And in just a simple, reflowable e-book which is not Epub 3 or fixed layout, is it then safe to assume that any errors arising in LITB would mainly -- about say 95% of the time -- be caused by poor ebook HTML format or caused by an incorrectly formatted Author Central profile or a mixture of both?

That's precisely what I'm saying. We don't (you, me, nj) have a viable control group. We don't have a data set that consists of "all books published as eBooks on Amazon." Without that data set, and/or without being able to effectively test the LITB, under given sets of conditions, without screwing up the book's sales...we're guessing, at BEST.

I tend to think that it goes a bit like this:
  • 70% are errata in the HTML. Folks who hit "enter, enter, enter" to create vertical whitespace, use tabs, etc. (nb: there's nothing "illegal", mind you, about using "enter, enter enter" as in, empty paragraphs, in HTML. that would PASS, at W3C. But it woudl not work in KindleBook, nor would it work in the LI. There's one example;
  • 20% are things perfectly allowable in HTML, but that don't work in LITB or the KindleBook itself. As I mentioned earlier, tables. Images or icons sized to specific % sizes. All of those--tables, images, icons--all work fine within Kindlebook, but not worth a hoot in the LI.
  • 10% mystery problems and the Author Central thing. By mystery problems, I'm actually including a subset of the first category. Say someone uploads a PDF--yes indeedy, the HTML will surely be crap, and thus, it won't render worth a hoot. Or, the Author Central thing, or other "mystery" issues.

That's what I think, give or take.


And another short question for you if you wouldn't mind which is way off point. After finally passing epubcheck I've noticed that whenever I test my epub ebook on Kindle upload with the Kindle Preview at Step 6, the emulation on all Kindle devices passes with flying colours, whereas the emulation for iPhone and iPad always has errors that differ and are not consistent. Generally, for chapter headings on iPad I get left aligned chapter headings rather than centered as they should be. On the iPhone emulation I get bold, centered or left aligned chapter headings with a larger font size than I have set. I also still implement empty span style bracketing for all major centered headings due to an old Apple epub problem that Liz Castro reported on and solved ages ago. All my styling of major centered headings involves just one paragraph style with no additional span styles for that paragraph(except for the empty span style bracketing). Also, all the styles used in my chapter headings or main headings involve Heading 1 or Heading 1 inheritance. I myself suspect that Kindle's Apple device emulations somehow renders Heading 1 quite differently and oddly.

Is Kindle's emulation of Apple's iPhone and iPad on Kindle Preview at Step 6 completely accurate and to be trusted or should I just ignore it as inaccurate emulation by Kindle?


If you don't mind, I'll come back in a bit and respond to that one, if I may? I don't mind giving you my thoughts, but I'm a bit fried right now. My hands need a break. ;-)

Hitch
We produce ebooks
See our real customer reviews here: http://bit.ly/1Jz4EKz
An INScribe Preferred Conversion Partner
http://www.booknook.biz/
Follow me on Twitter: @BookNookBiz
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur."
  • Red Adair
booknookbiz

Posts: 4,210
Registered: 03/04/10
Re: LOOK INSIDE preview not the same as on Kindle Previewer
Posted: Feb 6, 2016 2:03 AM   in response to: booknookbiz in response to: booknookbiz
Click to report abuse...   Click to reply to this thread Reply
William Thompson wrote:
(Con't. from the prior post...)

And another short question for you if you wouldn't mind which is way off point.


Sure, but be warned, you get what you pay for! ;-)

After finally passing epubcheck I've noticed that whenever I test my epub ebook on Kindle upload with the Kindle Preview at Step 6, the emulation on all Kindle devices passes with flying colours, whereas the emulation for iPhone and iPad always has errors that differ and are not consistent.

So, to be clear--this is the online emulation, of the Kindlebook, after you've converted it from the ePUB source, via the KDP. Right?

Generally, for chapter headings on iPad I get left aligned chapter headings rather than centered as they should be. On the iPhone emulation I get bold, centered or left aligned chapter headings with a larger font size than I have set. I also still implement empty span style bracketing for all major centered headings due to an old Apple epub problem that Liz Castro reported on and solved ages ago.

Yeah, our ePUBs still use that, as well. Not for Kindle as much as for 1st Gen iPads, which are still in wide circulation.

All my styling of major centered headings involves just one paragraph style with no additional span styles for that paragraph(except for the empty span style bracketing). Also, all the styles used in my chapter headings or main headings involve Heading 1 or Heading 1 inheritance. I myself suspect that Kindle's Apple device emulations somehow renders Heading 1 quite differently and oddly.

OK, for clarification--you mention styling of "just one paragraph style" when you are talking about centered headings, but then you go on to say that all your chapter heads are H1 or "h1 inheritance." When you say H1 inheritance, do you simply mean a named style that you can apply to multiple elements, e.g., ".first," or something like that? Or do you mean something like h1+p? I simply want to make sure that you and I are meaning the same things when using similar lingo. ;-)

Is Kindle's emulation of Apple's iPhone and iPad on Kindle Preview at Step 6 completely accurate and to be trusted or should I just ignore it as inaccurate emulation by Kindle?

You know, at this moment, I'd have to check it. For the longest while, the iPad/iPhone rendering was KF7. Period, end statement. Then it was a bastardized KF7/KF8 combo. (Text boxes were a gigantic pain, during that era!). However, since the advent of the AZK preview file, and the last KG/KP updates, the iOS displays have been pretty KF8, through and through, down to the font.

Have you built an AZK, with your MOBI or ePUB, and tested the file you get in that (the AZK), on an iDevice? Do you have an Apple device upon which to test? If you don't, do you have a friend who has one?

My recollection of the last time I checked, which was about ... 6 weeks ago, I think, the AZK preview, and how it looked on the real device, were different than what I saw on the iOS preview, online. But to be honest, your problem sounds like something else. Something in the code, maybe. Can you drop the html and the CSS in here? And any inherited classes, e.g., the H1 that's inherited?

Hitch
We produce eBooks
2016 GOLD Trusted Merchant!
www.Booknook.Biz
William Thompson

Posts: 1,146
Registered: 07/06/14
Re: LOOK INSIDE preview not the same as on Kindle Previewer
Posted: Feb 6, 2016 7:09 AM   in response to: booknookbiz in response to: booknookbiz
Click to report abuse...   Click to reply to this thread Reply
Hitch...Sure I can show my code. My chapter headers in the ebook are all formatted like this:

h1.ChapterHeader {
display: block;
color: #0a0a0a;
font-size:1em;
font-weight:normal;
font-style:normal;
margin: 0 0 0.8em 0em;
padding:0;
text-align:center
}

<h1 class="ChapterHeader"><span>Chapter X</span></h1>

And yes, what I'm talking about is the Kindle Preview at Step 7 where Kindle emulates your uploaded epub or mobi as Kindle AZK displays on iPhone and iPad. This is when these strange problems -- forced bold, left align(rather than centered) and greater font size -- occur and I really don't know why. I'm afraid I do not have or know anyone who has an iPhone or IPad and I'm not going to buy an iPad just to test my books(when I've already got a perfectly serviceable Android Tablet). Too expensive. I also live in the semi-provinces of the Philippines where they still think that pigeon post is a really big deal.

What's more, the Chapter Descriptors that I use directly below the chapter headers display perfectly. But the Chapter Descriptors do not use the h1 tag.

I must also mention that I use the following style for all main headers(only used in the front matter and back matter of the ebook) and all are formatted like this:

h1.MainHeader {
display: block;
color: #282828;
font-size:1.16em;
font-weight:bold;
font-style:normal;
margin: 0 0 2em 0em;
padding:0;
text-align:center
}

<h1 class="MainHeader"><span>Main Heading</span></h1>

As you can see both styles above are formatted in the exactly same way. Both the ChapterHeader and MainHeader para styles have the same problems. The common feature for both these styles seems to be the h1 tag. I'm a wee bit stumped here. Any ideas?
William Thompson

Posts: 1,146
Registered: 07/06/14
Re: LOOK INSIDE preview not the same as on Kindle Previewer
Posted: Feb 7, 2016 4:28 PM   in response to: booknookbiz in response to: booknookbiz
Click to report abuse...   Click to reply to this thread Reply
An UPDATE from my last post concerning problems with Kindle Preview display at Step 7 of Kindle upload.

Because of my suspicions with Heading 1 style, I converted all my h1 tags to p tags for all main headers and chapter headers in my epub, the iPad and iPhone display problems dosappeared and the emulated Kindle displays right across Kindle, Android and Apple were just fine.

To further confirm this, I converted a zipped Word doc HTML Filtered file to mobi via upload to Kindle(which converted and displayed OK across all emulated devices without problems) and then, after downloading the HTML, just unzipped it and had a look at the Kindle header formatting. I found that all the main header and chapter header formatting had all been converted from h1 tag formatting to p tags. Resulting in no more forced bold, outsize heading fonts or forced left centering on Apple device emulation.
booknookbiz

Posts: 4,210
Registered: 03/04/10
Re: LOOK INSIDE preview not the same as on Kindle Previewer
Posted: Feb 8, 2016 10:05 PM   in response to: William Thompson in response to: William Thompson
Click to report abuse...   Click to reply to this thread Reply
William Thompson wrote:
An UPDATE from my last post concerning problems with Kindle Preview display at Step 7 of Kindle upload.

Because of my suspicions with Heading 1 style, I converted all my h1 tags to p tags for all main headers and chapter headers in my epub, the iPad and iPhone display problems dosappeared and the emulated Kindle displays right across Kindle, Android and Apple were just fine.

To further confirm this, I converted a zipped Word doc HTML Filtered file to mobi via upload to Kindle(which converted and displayed OK across all emulated devices without problems) and then, after downloading the HTML, just unzipped it and had a look at the Kindle header formatting. I found that all the main header and chapter header formatting had all been converted from h1 tag formatting to p tags. Resulting in no more forced bold, outsize heading fonts or forced left centering on Apple device emulation.


That is simply bizarre. In any sense of eBookmaking, that's just wrong. That's not a criticism of you; it's just a statement. Headings, as you know, are structural. Using paragraphs in lieu of headings is, for either ePUB or MOBI, incorrect. I wonder why on earth the AZK/KFX/??? format is doing that/

Hmmm...investigations ahead, I can see that. Thanks for sharing.

Hitch
We produce eBooks
2016 GOLD Trusted Merchant--FEEFO
www.Booknook.Biz
William Thompson

Posts: 1,146
Registered: 07/06/14
Re: LOOK INSIDE preview not the same as on Kindle Previewer
Posted: Feb 9, 2016 2:41 AM   in response to: booknookbiz in response to: booknookbiz
Click to report abuse...   Click to reply to this thread Reply
Best thing you can perhaps do to actually confirm what I've found is to just upload any appropriately styled epub at Step 6 and then just download the HTML file that is generated at Step 7. The HTML file will show that all main headers have been stripped of the h1 tag and replaced with the p tag. And yes, that blew me away too.

I generate an epub and mobi from a marked-up text file using my own software. So I just switched the code search for all main headers from using Heading 1 (to generate the toc ) to p tags in my code. Then I created my toc just by searching for the title, main headers and chapter headers style names as normal without the need for h1 tags. It worked a treat -- I had no more weird formatting when I tested the converted epub file at Step 7. By getting rid of the h1 tags, which is only ever needed to generate the toc, all the weird h1 tag behaviour -- which also occurs sometimes in epub wrt font sizing and centering -- also disappears.
William Thompson

Posts: 1,146
Registered: 07/06/14
Re: LOOK INSIDE preview not the same as on Kindle Previewer
Posted: Feb 9, 2016 2:41 PM   in response to: booknookbiz in response to: booknookbiz
Click to report abuse...   Click to reply to this thread Reply
Even more interesting -- when I looked at the final Word HTML file before upload -- all the h1 tags had already been stripped out and replaced with p tags. This makes some sense because you have already created the TOC - so no further need for h1 tags. The only drawback to this is that your Word HTML will not be able to generate a Logical TOC on the Kindle e-reader on upload because the h1 tag reference is now gone (unlike epub -- which uses the h1 tag to generate both a doc TOC and a Logical TOC via the ncx and opf files).

I also converted the zipped Word HTML to AZW3 format using Calibre. And sure enough, when I viewed the AZW3 file in the editor, all the h1 tags had also been stripped out and replaced with p tags.

And, strangely, when I converted a different epub to AZW3 format that contained h1 tags + style classes for all headers I found that, after conversion to AZW3, all the h1 tags + classes were indeed all in the converted AZW3 file. Unfortunately you can't upload the AZW3 file to Kindle to see its effects or behaviour on preview emulation.
booknookbiz

Posts: 4,210
Registered: 03/04/10
Re: LOOK INSIDE preview not the same as on Kindle Previewer
Posted: Feb 9, 2016 8:15 PM   in response to: William Thompson in response to: William Thompson
Click to report abuse...   Click to reply to this thread Reply
William Thompson wrote:
Even more interesting -- when I looked at the final Word HTML file before upload -- all the h1 tags had already been stripped out and replaced with p tags. This makes some sense because you have already created the TOC - so no further need for h1 tags. The only drawback to this is that your Word HTML will not be able to generate a Logical TOC on the Kindle e-reader on upload because the h1 tag reference is now gone (unlike epub -- which uses the h1 tag to generate both a doc TOC and a Logical TOC via the ncx and opf files).

William, what do you mean? What Word HTML file? Are you saying that if you export your Word file to HTML, the h1 is stripped out? Because that's not correct, not at all. We export dozens of Word files each week around here, and the H1 most certainly aren't being stripped. What part of your post did I miss?


I also converted the zipped Word HTML to AZW3 format using Calibre. And sure enough, when I viewed the AZW3 file in the editor, all the h1 tags had also been stripped out and replaced with p tags.

And, strangely, when I converted a different epub to AZW3 format that contained h1 tags + style classes for all headers I found that, after conversion to AZW3, all the h1 tags + classes were indeed all in the converted AZW3 file. Unfortunately you can't upload the AZW3 file to Kindle to see its effects or behaviour on preview emulation.


Well, we don't upload Word files; we upload completed MOBI files. I can absolutely guarantee that the h1 tags aren't being yanked out.Can you clarify what you mean, in the first paragraph, about "when I looked at the final Word HTML file before upload -- all the h1 tags had already been stripped out a..."? You must have said something earlier, that I'm misunderstanding. Do you mean the HTML file that you're downloading from the KDP?

Hitch
William Thompson

Posts: 1,146
Registered: 07/06/14
Re: LOOK INSIDE preview not the same as on Kindle Previewer
Posted: Feb 9, 2016 10:15 PM   in response to: booknookbiz in response to: booknookbiz
Click to report abuse...   Click to reply to this thread Reply
Hitch...All you have to do is just obtain any ebook in Word doc format that has been formatted correctly with all main headers in standard Header 1 format. This Word doc should also contain a valid TOC.

Open this Word doc and then just Save this file as Web Page HTML Filtered.

Now open that Word HTML file using Notepad++ or whatever HTML editor you want to use and look at the main headers that were all created from the original Word doc using Header 1 style.

All h1 tags will be gone, replaced by p tags.

So when you upload your Web Page HTML Filtered file to Kindle for conversion, it already contains no h1 tags.
booknookbiz

Posts: 4,210
Registered: 03/04/10
Re: LOOK INSIDE preview not the same as on Kindle Previewer
Posted: Feb 9, 2016 11:48 PM   in response to: William Thompson in response to: William Thompson
Click to report abuse...   Click to reply to this thread Reply
William Thompson wrote:
Hitch...All you have to do is just obtain any ebook in Word doc format that has been formatted correctly with all main headers in standard Header 1 format. This Word doc should also contain a valid TOC.

Open this Word doc and then just Save this file as Web Page HTML Filtered.

Now open that Word HTML file using Notepad++ or whatever HTML editor you want to use and look at the main headers that were all created from the original Word doc using Header 1 style.

All h1 tags will be gone, replaced by p tags.

So when you upload your Web Page HTML Filtered file to Kindle for conversion, it already contains no h1 tags.


William:

I've been doing this since 2008, and I've NEVER seen that. Not once. When I export a Word file that has h1-class styles in it, they show up just as they ought, in the HTML. Don't mistake what I'm about to say, but are you SURE you used Headers? I've seen a bunch of templates out there that have "heading" styles, but those are paragraph classes. Did you style the h1's (or whatever heading class) yourself?

I promise you, what you're seeing is utterly abnormal. Would you like to send me one of your non-h1-exporting Word files? Do you know how to find my shop? If you go to my website, click the CONTACT item on the menubar, you can use the form. Send me a note, and I'll relay back to you my corporate Hightail link so you can send me some uploads. I don't mind taking a look, because something is wildly awry. I'm going to be out all day tomorrow, for personal reasons, but I'll be back on Thursday ful time.

Post updated to add: Just to ensure that I hadn't utterly gone round the bend, I just checked this by saving a file I've been working on (not an eBook, but a document I'm working on that has multiple headings at levels h1-h3) as "filtered HTML." I then opened it in my HTML/Text editor, which is NoteTab Pro (not Notpad). The h1 headings (and the styling I assigned thereto) are right there in the HTML file.

I strongly recommend, William, that you check the actual styling on the document you're testing, and make sure that somebody didn't style something CALLED "headers" using paragraph styles.I see that ALL the time in templates, whether it's from the BookDesigner or other places.

Back Thursday.
Hitch
2016 Gold Trusted Merchant
www.Booknook.Biz

Edited by: booknookbiz on Feb 9, 2016 11:51 PM: added results of a quick Word export.
William Thompson

Posts: 1,146
Registered: 07/06/14
Re: LOOK INSIDE preview not the same as on Kindle Previewer
Posted: Feb 10, 2016 12:11 AM   in response to: booknookbiz in response to: booknookbiz
Click to report abuse...   Click to reply to this thread Reply
Hitch...OK, I'll send you a prepared Word file as Web Page HTML filtered and an epub of the same ebook in an email to your shop at BookNook.com. This is an ebook file I've been helping to prepare for a guy for upload to Kindle soon. Neither the Word HTML file nor the epub version will have any h1 tags in them -- they both just use p tags for all headers. Both these files upload to Kindle without problems at Step 6.
booknookbiz

Posts: 4,210
Registered: 03/04/10
Re: LOOK INSIDE preview not the same as on Kindle Previewer
Posted: Feb 10, 2016 2:26 PM   in response to: William Thompson in response to: William Thompson
Click to report abuse...   Click to reply to this thread Reply
William Thompson wrote:
Hitch...OK, I'll send you a prepared Word file as Web Page HTML filtered and an epub of the same ebook in an email to your shop at BookNook.com. This is an ebook file I've been helping to prepare for a guy for upload to Kindle soon. Neither the Word HTML file nor the epub version will have any h1 tags in them -- they both just use p tags for all headers. Both these files upload to Kindle without problems at Step 6.

William:

Did you send the source Word file?

Hitch
William Thompson

Posts: 1,146
Registered: 07/06/14
Re: LOOK INSIDE preview not the same as on Kindle Previewer
Posted: Feb 11, 2016 7:07 PM   in response to: booknookbiz in response to: booknookbiz
Click to report abuse...   Click to reply to this thread Reply
I sent the epub version(without h1 tags) to your reply email address yesterday I think. This epub works and and previews OK in Kindle Preview.

There was also no point sending the HTML file since I was so totally wrong(as I say in the email) and you were right -- converting from Word to HTML does not change the header tags from h1 tags to p tags

Humble apologies to you for that goof.
Legend
Helpful Answer
Correct Answer

Point your RSS reader here for a feed of the latest messages in all forums