Quote:
Originally Posted by DiapDealer
Whatever.
I remain unconvinced that you're giving it valid data.
I remain unconvinced that two navPoints (with or without duplicate PlayOrders) pointing to the exact same url is valid.
I remain unconvinced that duplicate PlayOrders are valid (regardless of what various validation engines might not bark about).
I believe all you're doing is fooling the IDPF validator into giving your ncx a clean bill of health by duplicating the playorders.
I don't think Sigil needs to take responsibility for helping to slip an unorthodox ncx past Apple's and Kobo's validator.
|
Not to get in the midst of this, Peter, but: Diap's right, it's not "valid data." You're creating duplicate play-order entries, as different NCX values, but differing nav-points. The correct way to do this would be as previously discussed--with actual, different navpoints, identified via ID or # or whatever. You are "tricking" it, Peter, because you're manually manipulating it into accepting a playlist with duplicate entries, or, rather, essentially repetitive entries being recycled.
Personally--for what it's worth--I'd rather have Sigil error-checking for dupe playlist entries. That, as an error, is more likely, than the need to have multiple items on the NCX all pointing at the same place, in order to shoehorn the reader into starting at the top of the chapter. Most of us--making books--would just create the correct items. What you're doing is taking a shortcut, by not creating the id's, but then creating a boatload more work for yourself by manually renumbering the Play orders. {shrug}.
Just my $.02. The NCX spec for ePUB2 clearly doesn't anticipate duplicate playlist items/orders--that's why a duped entry creates an "error." If the ePUB3 spec for the new TOC/NCX/whatever-it's-called-I-can't-remember-now allows dupe entries, then this discussion is moot, as Sigil will be updated to reflect that, presumably.
Hitch