I guess I just don't follow why--given that the ncx (or nav) was already declared "good"--there would be any reason for regenerating the ncx from the text the proposed plugin took from that good ncx and plugged into the epub's html (utilizing attributes of h tags or contents of html comments that were later regexed into same).
Why insert non-rendering attributes into the html that can really only be used to regenerate the ncx if the ncx has already been declared sufficient?
Is the whole point to make an already functional, textually satisfactory NCX/NAV regeneratable from the html?
I could understand a desire for a plugin that truly reverses the html to ncx/nav process: namely making the various chapter/section headings in the html match the ncx/nav. But what I THINK I'm hearing, is a desire for a plugin that makes it possible to regenerate an NCX/NAV that doesn't need regenerated by inserting non-rendering html (or easily regexable non-rendering html comments) into the epub's xhtml.
If done correctly, an ncx/nav generated from the attributes inserted into the html by the proposed plugin (from the original ncx/nav) would look and function exactly like the original ncx/nav, no?
Last edited by DiapDealer; 07-08-2020 at 11:22 AM.
|