Quote:
Originally Posted by slowsmile
@ DiapDealer...I'm afraid that I strongly object to allowing page-map checks in my plugin because it sets a bad precedent. To me there's no grey area. You either follow one standard like the IDPF standard or you don't.
|
Whatever. They're your plugins.
Quote:
Originally Posted by slowsmile
Here's an example of problems that would arise if you don't follow one standard. Say a Sigil user requests an automatic page-map build feature for Sigil and the developers respond that their request does not follow the IDPF standard and his feature request is refused. And then the user responds by saying that there is a already a Sigil plugin that supports and processes page-maps. How are you going to respond to that user?
|
I'm going to say, "so what?"
Quote:
Originally Posted by slowsmile
If the above precedent already allows a Sigil plugin to process page-maps then what possible justification do the Sigil developers have for refusing the user's new page-map build feature request?
|
You're being a little obtuse. There's clearly a difference between adding feature requests to Sigil's core and not expecting a plugin to break a working epub. Besides ... Sigil already makes non-spec-complaint concessions to remain compatible with other popular software and popular epub creation techniques. And we certainly try to accommodate the opening of non-compliant epubs without breaking internal links wherever possible. Sigil doesn't blindly dump/drop/break things that don't meet spec.
But I'm done here. If you're comfortable with your plugins breaking people's working epubs because they contained non-spec content, then have at it. I'm more of a "first do no harm" contributor, myself. *shrug*