Kobo Firmware 3.5.0

[arspr]

Originally Posted by davidfor

I missed that. So, what is happening is that the ToC for the duplicated target is excluded from the ToC list and then the tick appears next to the entry that is one further down than it should.

Does selecting the entries after the missing one take you to the correct place?

It looks like a kepub. Is it sideloaded? If so, what happens with the epub?

Yes, ToC works correctly when jumping (look at 3 & 4).

As I posted it happens in ACCESS. I haven't tested in RMSDK. I'll do ASAP but I'm going on holidays and I'm not going to have access to Calibre for a while. Nevertheless it's a quite easy test. Just edit any of your books and temporally "break" its ToC in that way.

[pgaunt]

Originally Posted by JSWolf

Off means do not fix widows and orphans so they are not widows and orphans. Turn the feature off. 2 is on, 0 is off.

1 is 'off'. Zero or less is meaningless.

[sadowski]

I don't know whether this is new, but now that the long paragraph thing is under control, I noticed the following:

In RMSDK, with hyphenation on and alignment set to "text-alignment:justify", there is no hyphenation in the 1st line of a paragraph but instead the words are ugly spaced out if needed. All other lines are nicely hyphenated if needed.

Even more puzzling: This happens only if the 1st line is indented (e.g., "text-indent:1em"). If it is zero, even 1st lines are properly hyphenated.

Anyone else noticed? Known work-arounds?

Jens

[GeoffR]

Originally Posted by sadowski

In RMSDK, with hyphenation on and alignment set to "text-alignment:justify", there is no hyphenation in the 1st line of a paragraph but instead the words are ugly spaced out if needed. All other lines are nicely hyphenated if needed.

I don't know if this is related, but in firmware 3.4.1 and 3.5.0 there seem to be no hyphenation dictionaries included in the firmware archive.

[JSWolf]

Originally Posted by pgaunt

1 is 'off'. Zero or less is meaningless.

How is it meaningless when it WORKS?

[davidfor]

Originally Posted by JSWolf

How is it meaningless when it WORKS?

But, what does it mean? Or how does 0 differ from 1? Beyond saying "Off", you haven't actually said what the difference is. Or what "Off" means.

[JSWolf]

Originally Posted by davidfor

But, what does it mean? Or how does 0 differ from 1? Beyond saying "Off", you haven't actually said what the difference is. Or what "Off" means.

If 0 and 1 both work the same, then I see no harm using either value.

[davidfor]

Originally Posted by JSWolf

If 0 and 1 both work the same, then I see no harm using either value.

My question was to you. You seem to be insisting that there is a difference. So, I want to know what YOU think the difference is.

As to why we should not use 0 if it is the same as 1. Easy, the standards say the minimum value is 1. Therefore, any ePub ereader that treats 0 as something other than an error is out of spec. It appears that the RMSDK has been treating 0 the same as 1. In some version, this will probably be fixed. If we start make sure we use the correct value in the books now, that won't cause a problem in the future.

[arspr]

Originally Posted by JSWolf

If 0 and 1 both work the same, then I see no harm using either value.

Oh guys this is getting more and more similar to the Groundhog Day film with each new post.

You can do whatever you want whenever you want however you want.

People are just saying that 1 is the correct value. 0 maybe works but there is no guarantee it will always work at time in any reader.

But I repeat, of course, do whatever you want with your ebooks. They are yours if you hadn't noticed...

[arspr]

Originally Posted by GeoffR

I don't know if this is related, but in firmware 3.4.1 and 3.5.0 there seem to be no hyphenation dictionaries included in the firmware archive.

Hmmmm, if there are no hyphenation dicts, how can the feature work in any way? Are you sure about that absence?

Nevertheless I cannot help with this issue as I really HATE hyphenation and I either turn it off or keep it tturned off as a rule, and I'm not willing tto spend time in an useless feature (for me obviously)

[forster01]

In previous firmwares font-variant: smallcaps is not recognized. Is that fixed with 3.5.0?

[Jellby]

Nope.

[arspr]

Buuut, it has always worked in kepubs (ACCESS).

[DNSB]

Originally Posted by JSWolf

If 0 and 1 both work the same, then I see no harm using either value.

The harm can come in the future when your standards compliant ereader sees the value of 0 for widows or orphans and ignores it.

The CSS Level 3 Fragmentation module states the following (which I've quoted once before):

Only positive integers are allowed as values of ‘orphans’ and ‘widows’. Negative values and zero are invalid and must cause the declaration to be ignored.

Please note the section that I have bolded. And yes, testing with a ePub3/CSS 3 compliant application, setting widows and orphans to 0 gave the same effect as no widows and orphans declarations, i.e. the default of 2 was applied.

Regards,
David

[tshering]

Originally Posted by arspr

Hmmmm, if there are no hyphenation dicts, how can the feature work in any way? Are you sure about that absence?

Even if they are not included in recent upgrade files, they will be available on the devices from previous update files or from the reset firmware (some older models, however will miss some hyphenation dictitionaries in their reset firmware). Of course, I don't know whether those files are omitted on purpose, and the data for hyphenation is stored some other place. GeoffR might just imply that something in the hyphenation handling has changed.