KFX Format - Page 37

badgoodDeb · 02-06-2017, 02:45 PM

Quote:

Originally Posted by Notjohn

And it's not only the internet. I happened across a book on Amazon this morning whose Product Details contained this line: Amazon Best Sellers Rank: #13,537,048 in Books

Wow. That is impressive, given that I started in September or October that year (my grad student daughter had dial-up access to the university computer, and I hijacked her account) and there was virtually nothing out there! CERN. ...

I work at CERN's little brother, Fermilab. We had the worlds biggest and fastest particle accelerator before CERN came along. We cooperate, actually, and have a remote CERN control room here, and also built a number of their component pieces.

cvkemp · 02-07-2017, 04:49 PM

Quote:

Originally Posted by badgoodDeb

I work at CERN's little brother, Fermilab. We had the worlds biggest and fastest particle accelerator before CERN came along. We cooperate, actually, and have a remote CERN control room here, and also built a number of their component pieces.

I worked on the SCSC project in Texas. And it still ticks me off that they shut us down.

badgoodDeb · 02-07-2017, 05:03 PM

Quote:

Originally Posted by cvkemp

I worked on the SCSC project in Texas. And it still ticks me off that they shut us down.

Amen! I always thought they should at least have turned the tunnel into a go-cart rink, or some such.

eggheadbooks1 · 03-01-2017, 06:57 PM

I read this whole thread with interest as I am now doing tests for KFX. I can report a few things:

1. There is absolutely NO evidence that KFX is erasing or in any way ignoring the NBSP. I used it to bind ellipses and em dashes to the preceding text. I also used it to bind a traditional three-point ellipsis, all to see if KFX would break any of them up or force an ellipsis or em dash to the start of the next line. No matter the display font size, I could not force any to break. I have attached two screen shots. In the first, I have circled where the text would have stayed on the previous line had the text not been attached to an ellipsis. In the second, the last letter, d, has been pulled to the next line precisely because of an NBSP.

I also used decimals ("1.5") and 4-digit numbers with a comma ("3,000") to see if KFX would split any at the period or comma; it didn't.

2. In my test file I:

embedded a font
tested for the Monospace font
used media queries for older mobi7 content
created lines of various color, style and width
created tables
used hanging paragraphs
added inline and stand-alone images, using both inline styling and CSS-controlled divisions
created colored text boxes
used selective colored text
used Emphasis and Strong with and without font-styling (i.e., emphasis without Italic)
created ordered and unordered lists, and mixed the two

All were done in HTML4 and CSS2 in an ePub2 in Sigil and converted in KFX. Everything displayed as intended. I cannot know if the Emphasis without Italic would read properly in TSS as of course the file cannot be tested outside previewer.

I then exported a mobi file from Previewer3 and sideloaded it into my older Kindle Fire. Everything displayed as expected.

jhowell · 03-01-2017, 09:12 PM

Some books use paragraphs containing only an nbsp character to provide extra vertical spacing, even though there are better ways to accomplish that. It was the case in the early days of KFX that these paragraphs would be dropped, causing the extra spacing to be lost.

I just did a test with the latest Kindle Previewer (version 3.8) and the following content:

Code:

<body>
<p>First paragraph</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>Last paragraph</p>
</body>

The KFX generated is equivalent to only the first and last paragraphs, with the second having a margin-top of 6.65em.

So it does still strip out paragraphs containing only nbsp while retaining the desired vertical spacing in a much cleaner fashion.

eggheadbooks1 · 03-01-2017, 11:56 PM

I had only referred to NBSPs as "anchors" for em dashes and ellipses, not used to create blank lines. But in any case, even if KFX turns NBSPs into something else, if the end result is the same, does it matter? As long as my em dashes and ellipses, decimals, et cetera, behave the same way in KFX, I'm happy.

From what I can tell from your excellent earlier sleuthing, the whole of the HTML is converted to a form of javascript, yes? So does it not stand to reason that the NBSPs are also converted to something else?

What was reported earlier by others is that KFX mangles one's text by erasing/ignoring the NBSP. I could find no evidence of that. That is merely what I wished to convey. I had panicked at first when I read those earlier posts as I use the NBSP with em dashes etc, as well as to ensure that my CIP data block is rendered as close as possible to that issued by my national literary agency. The idea of that getting mangled in KFX made me shudder. I was happy to see it was not the case.

AaronShep · 03-02-2017, 12:54 AM

eggheadbooks1, it's not clear how you generated or viewed your first tests, but your final test is invalid. The MOBI file generated by Previewer 3 is not in KFX, it's an intermediary step before the final conversion. Previewer 3 does not offer any file that you could load onto your Kindle Fire. (And an older Kindle Fire might not display KFX's Enhanced Typesetting anyway.) You have to view your test in Previewer 3 itself -- and frankly, even that doesn't always show you exactly what you'll get after KDP processing.

I haven't tested the nonbreaking space in Previewer 3 recently, but I not only saw proof that they were being ignored, I also confirmed it with the head of the Kindle engineering team responsible. He told me they did it to prevent authors from sticking together phrases that run off the edge of the screen. And despite my strident arguments, I could not convince them to change their minds.

OK, I just ran this HTML into Previewer 3, and it again shows the nonbreaking space being totally ignored. I'm not sure it will show up here properly, but it's a set of numbers 1 to 5 repreated numerous times, with nonbreaking spaces between the number of each set. In Previewer 3, you'll see that the number sets are broken anywhere at all, not at the end of each set as they should be. I also ran the same test using the Unicode character in place of the entity, with the same results. They're both treated as simple spaces, just as reported earlier.

<div>1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5</div>

You should forget about controlling em dashes. (I've started putting a space before and after, as in newspaper typography, so it won't look so bad.) And if you really need to show formatted text such as CIP, your best bet is probably a GIF.

Aaron

Hitch · 03-02-2017, 01:01 AM

Quote:

Originally Posted by AaronShep

eggheadbooks1, it's not clear how you generated or viewed your first tests, but your final test is invalid. The MOBI file generated by Previewer 3 is not in KFX, it's an intermediary step before the final conversion. Previewer 3 does not offer any file that you could load onto your Kindle Fire. (And an older Kindle Fire might not display KFX's Enhanced Typesetting anyway.) You have to view your test in Previewer 3 itself -- and frankly, even that doesn't always show you exactly what you'll get after KDP processing.

I haven't tested the nonbreaking space in Previewer 3 recently, but I not only saw proof that they were being ignored, I also confirmed it with the head of the Kindle engineering team responsible. He told me they did it to prevent authors from sticking together phrases that run off the edge of the screen. And despite my strident arguments, I could not convince them to change their minds.

OK, I just ran this HTML into Previewer 3, and it again shows the nonbreaking space being totally ignored. I'm not sure it will show up here properly, but it's a set of numbers 1 to 5 repreated numerous times, with nonbreaking spaces between the number of each set. In Previewer 3, you'll see that the number sets are broken anywhere at all, not at the end of each set as they should be. I also ran the same test using the Unicode character in place of the entity, with the same results. They're both treated as simple spaces, just as reported earlier.

<div>1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5</div>

You should forget about controlling em dashes. (I've started putting a space before and after, as in newspaper typography, so it won't look so bad.) And if you really need to show formatted text such as CIP, your best bet is probably a GIF.

Aaron

In the normal course of things, we don't have a lot of spare time to test things like this, but we recently have tested it a bit due to a client's requirements. Our tests--not that extensive, but still--indicate that the nbsps are being ignored/converted to a space.

Offered FWIW.

Hitch

jhowell · 03-02-2017, 10:36 AM

I did some more testing of this and it looks like eggheadbooks1 and AaronShep are both right in some cases.

I don't know all of the factors involved, but in my testing as long as there is an average of at least three regular spaces for every one non-breaking space then the nbsp's are retained. If there are too many nbsp's per regular space then they are replaced with regular spaces.

I have attached a sample EPUB that demonstrates nbsp's working in KFX. After opening it in Kindle Previewer 3.8 you can change the font and font size and you will see that it never breaks between 4's and 1's, where I have placed nbsp characters.

I have also attached a screenshot from the Previewer and a partial hex dump of the equivalent KFX file with the utf-8 nbsp characters highlighted.

eggheadbooks1 · 03-02-2017, 02:37 PM

Aaron, it says in my post that I exported a mobi file from Previewer3 for sideloading and testing on my Fire; the tests in Previewer itself were put into screenshots. I do know that Previewer is never the last word on anything, but maybe part of the problem is that you are converting from HTML and not ePub. You have already discovered one issue with the line breaks; perhaps there is something else in your HTML that is causing further issues?

Jhowel and Hitch: thanks for the additional tests. As a publisher, as long as the extra spaces are respected by the ereaders, I'm good with that: the display is the same in the end. I remember way back, when one had no choice but to use the NBSP if you wanted multiple spaces: older systems would assume that was an error and erase the additional spaces. Argh!

I cannot see Amazon or anyone else waging war against multiple spaces. That would kill the ability to publish as ebooks alternate genres such as poetry. For example you might want to write:

the space (     ) between us

Take out the spaces and you just ruined the text. (Which, somewhat telling, is what happened when I first typed in the extra spaces and checked Preview Post. Spaces gone!)

Hitch · 03-02-2017, 03:18 PM

Quote:

Originally Posted by jhowell

I did some more testing of this and it looks like eggheadbooks1 and AaronShep are both right in some cases.

I don't know all of the factors involved, but in my testing as long as there is an average of at least three regular spaces for every one non-breaking space then the nbsp's are retained. If there are too many nbsp's per regular space then they are replaced with regular spaces.

I have attached a sample EPUB that demonstrates nbsp's working in KFX. After opening it in Kindle Previewer 3.8 you can change the font and font size and you will see that it never breaks between 4's and 1's, where I have placed nbsp characters.

I have also attached a screenshot from the Previewer and and a partial hex dump of the equivalent KFX file with the utf-8 nbsp characters highlighted.

Thank you, jhowell.

I confess, I'm sitting here debating on how the hades we'd ever figure out if a book had a ratio of 3:1, but...(*&^%$#@!, I guess at least we know that that's near to what it probably is, in their internal coding. For the love of.....

grrrrrrrrrrrrrrrrrrrrrrrrrrrrr

(And have we, EVER, used nbsp's, specifically, as egghead noted, for visual poetry? You betcha you pants we have. Bl**dy H*ell.)

Hitch

eggheadbooks1 · 03-02-2017, 04:41 PM

JHowell -- may I ask a favour? I am curious now as to what happens to azw3 files created by Previewer3. Are they identical to those previously built with Previewer2? Specifically, what happens to these multiple NBSPs? Are you able to check?

jhowell · 03-02-2017, 05:13 PM

Quote:

Originally Posted by eggheadbooks1

JHowell -- may I ask a favour? I am curious now as to what happens to azw3 files created by Previewer3. Are they identical to those previously built with Previewer2? Specifically, what happens to these multiple NBSPs? Are you able to check?

I did an additional test by adding multiple nbsp characters between groups of numbers so that there were more nbsp characters than regular spaces. As expected, conversion of this file to KFX replaced all of the nbsp's with regular spaces.

I then used kindleunpack to examine the MOBI file created by Previewer 3.8 and saw that it does still contain the nbsp characters, matching the original EPUB. This is not surprising since Kindle Previewer 3 uses kindlegen 2.9 to create the MOBI.

Files are attached.

eggheadbooks1 · 03-02-2017, 06:14 PM

JHowell: Interesting, thank you.

BTW, there was talk earlier in the thread about the new format's obfuscation being a new form of DRM. But while KFX files cannot yet be converted into ePubs or azw3 files, is there anything that prevents the illegitimate sharing of KFX files once initially purchased from Amazon (assuming DRM is not applied)? I cannot remember what if anything was said about this...

jhowell · 03-02-2017, 06:44 PM

Quote:

Originally Posted by eggheadbooks1

...is there anything that prevents the illegitimate sharing of KFX files once initially purchased from Amazon (assuming DRM is not applied)?

Much of the workings of KFX DRM are still unknown. Software that defeats the DRM used by Amazon's other formats has been available for years, but there is currently no known way of defeating KFX DRM. And so far all e-books delivered by Amazon in KFX format have been encrypted by DRM.

Through testing it has been found that there are at least two "flavors" of KFX DRM:

1. Books that are marked on their web page as "Simultaneous Device Usage: Unlimited" are DRM-free in MOBI or KF8 format. The KFX equivalent of these books is still encrypted by DRM, but they have been found to function when copied to another Kindle device of the same type. So this DRM protects the content from examination and conversion but not from being copied.

2. Books that are not marked "Unlimited" are locked to the original device using DRM in all Kindle e-book formats, including KFX.

03-01-2017, 06:57 PM	#544
eggheadbooks1 Read, don't parrot. Posts: 224 Karma: 110242 Join Date: Apr 2011 Device: Kindle Fire, Kobo Touch, Aldiko for Android	I read this whole thread with interest as I am now doing tests for KFX. I can report a few things: 1. There is absolutely NO evidence that KFX is erasing or in any way ignoring the NBSP. I used it to bind ellipses and em dashes to the preceding text. I also used it to bind a traditional three-point ellipsis, all to see if KFX would break any of them up or force an ellipsis or em dash to the start of the next line. No matter the display font size, I could not force any to break. I have attached two screen shots. In the first, I have circled where the text would have stayed on the previous line had the text not been attached to an ellipsis. In the second, the last letter, d, has been pulled to the next line precisely because of an NBSP. I also used decimals ("1.5") and 4-digit numbers with a comma ("3,000") to see if KFX would split any at the period or comma; it didn't. 2. In my test file I: embedded a font tested for the Monospace font used media queries for older mobi7 content created lines of various color, style and width created tables used hanging paragraphs added inline and stand-alone images, using both inline styling and CSS-controlled divisions created colored text boxes used selective colored text used Emphasis and Strong with and without font-styling (i.e., emphasis without Italic) created ordered and unordered lists, and mixed the two All were done in HTML4 and CSS2 in an ePub2 in Sigil and converted in KFX. Everything displayed as intended. I cannot know if the Emphasis without Italic would read properly in TSS as of course the file cannot be tested outside previewer. I then exported a mobi file from Previewer3 and sideloaded it into my older Kindle Fire. Everything displayed as expected. Attached Thumbnails

03-01-2017, 09:12 PM	#545
jhowell Grand Sorcerer Posts: 7,076 Karma: 91577715 Join Date: Nov 2011 Location: Charlottesville, VA Device: Kindles	Some books use paragraphs containing only an nbsp character to provide extra vertical spacing, even though there are better ways to accomplish that. It was the case in the early days of KFX that these paragraphs would be dropped, causing the extra spacing to be lost. I just did a test with the latest Kindle Previewer (version 3.8) and the following content: Code: <body> <p>First paragraph</p> <p> </p> <p> </p> <p> </p> <p> </p> <p>Last paragraph</p> </body> The KFX generated is equivalent to only the first and last paragraphs, with the second having a margin-top of 6.65em. So it does still strip out paragraphs containing only nbsp while retaining the desired vertical spacing in a much cleaner fashion.

03-02-2017, 12:54 AM	#547
AaronShep Connoisseur Posts: 56 Karma: 3274 Join Date: Dec 2011 Device: iPad	eggheadbooks1, it's not clear how you generated or viewed your first tests, but your final test is invalid. The MOBI file generated by Previewer 3 is not in KFX, it's an intermediary step before the final conversion. Previewer 3 does not offer any file that you could load onto your Kindle Fire. (And an older Kindle Fire might not display KFX's Enhanced Typesetting anyway.) You have to view your test in Previewer 3 itself -- and frankly, even that doesn't always show you exactly what you'll get after KDP processing. I haven't tested the nonbreaking space in Previewer 3 recently, but I not only saw proof that they were being ignored, I also confirmed it with the head of the Kindle engineering team responsible. He told me they did it to prevent authors from sticking together phrases that run off the edge of the screen. And despite my strident arguments, I could not convince them to change their minds. OK, I just ran this HTML into Previewer 3, and it again shows the nonbreaking space being totally ignored. I'm not sure it will show up here properly, but it's a set of numbers 1 to 5 repreated numerous times, with nonbreaking spaces between the number of each set. In Previewer 3, you'll see that the number sets are broken anywhere at all, not at the end of each set as they should be. I also ran the same test using the Unicode character in place of the entity, with the same results. They're both treated as simple spaces, just as reported earlier. <div>1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5</div> You should forget about controlling em dashes. (I've started putting a space before and after, as in newspaper typography, so it won't look so bad.) And if you really need to show formatted text such as CIP, your best bet is probably a GIF. Aaron Last edited by AaronShep; 03-02-2017 at 12:57 AM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Using Kindle format vs ePub format is like using a compiler vs winzip?	Julius Caesar	Workshop	1	09-01-2013 07:34 PM
iPhone Convert epub format to kindle for iPhone format. Is it possible?	thecyberphotog	Apple Devices	16	03-14-2013 01:04 AM
No 'epub' format shown in Plugboards Format dropdown list	kakkalla	Library Management	3	06-16-2012 04:23 AM
Ebook in PRC format will not convert to any other format	Katelyn	Calibre	0	10-01-2010 07:02 PM
Master Format for multi-format eBook Generation?	cerement	Workshop	43	04-01-2009 12:00 PM

03-01-2017, 11:56 PM	#546
eggheadbooks1 Read, don't parrot. Posts: 224 Karma: 110242 Join Date: Apr 2011 Device: Kindle Fire, Kobo Touch, Aldiko for Android	I had only referred to NBSPs as "anchors" for em dashes and ellipses, not used to create blank lines. But in any case, even if KFX turns NBSPs into something else, if the end result is the same, does it matter? As long as my em dashes and ellipses, decimals, et cetera, behave the same way in KFX, I'm happy. From what I can tell from your excellent earlier sleuthing, the whole of the HTML is converted to a form of javascript, yes? So does it not stand to reason that the NBSPs are also converted to something else? What was reported earlier by others is that KFX mangles one's text by erasing/ignoring the NBSP. I could find no evidence of that. That is merely what I wished to convey. I had panicked at first when I read those earlier posts as I use the NBSP with em dashes etc, as well as to ensure that my CIP data block is rendered as close as possible to that issued by my national literary agency. The idea of that getting mangled in KFX made me shudder. I was happy to see it was not the case.

03-02-2017, 02:37 PM	#550
eggheadbooks1 Read, don't parrot. Posts: 224 Karma: 110242 Join Date: Apr 2011 Device: Kindle Fire, Kobo Touch, Aldiko for Android	Aaron, it says in my post that I exported a mobi file from Previewer3 for sideloading and testing on my Fire; the tests in Previewer itself were put into screenshots. I do know that Previewer is never the last word on anything, but maybe part of the problem is that you are converting from HTML and not ePub. You have already discovered one issue with the line breaks; perhaps there is something else in your HTML that is causing further issues? Jhowel and Hitch: thanks for the additional tests. As a publisher, as long as the extra spaces are respected by the ereaders, I'm good with that: the display is the same in the end. I remember way back, when one had no choice but to use the NBSP if you wanted multiple spaces: older systems would assume that was an error and erase the additional spaces. Argh! I cannot see Amazon or anyone else waging war against multiple spaces. That would kill the ability to publish as ebooks alternate genres such as poetry. For example you might want to write: the space (     ) between us Take out the spaces and you just ruined the text. (Which, somewhat telling, is what happened when I first typed in the extra spaces and checked Preview Post. Spaces gone!)

03-02-2017, 04:41 PM	#552
eggheadbooks1 Read, don't parrot. Posts: 224 Karma: 110242 Join Date: Apr 2011 Device: Kindle Fire, Kobo Touch, Aldiko for Android	JHowell -- may I ask a favour? I am curious now as to what happens to azw3 files created by Previewer3. Are they identical to those previously built with Previewer2? Specifically, what happens to these multiple NBSPs? Are you able to check?

03-02-2017, 06:14 PM	#554
eggheadbooks1 Read, don't parrot. Posts: 224 Karma: 110242 Join Date: Apr 2011 Device: Kindle Fire, Kobo Touch, Aldiko for Android	JHowell: Interesting, thank you. BTW, there was talk earlier in the thread about the new format's obfuscation being a new form of DRM. But while KFX files cannot yet be converted into ePubs or azw3 files, is there anything that prevents the illegitimate sharing of KFX files once initially purchased from Amazon (assuming DRM is not applied)? I cannot remember what if anything was said about this...