Hmm, that could be the case if you used a mixture of Markdown headings and styled headings, where the styled headings have been set up with
Format ▸ Paragraph ▸ HTML Header Level. Those would convert to the respective number of hashes with the RTF conversion option enabled.
You can do that without that setting though:
- Edit your compile format.
- In the Styles pane, select or create a “Heading 3” style.
- In the Prefix field, type in
### (with a space after).
Give that a test with the RTF conversion option disabled, and see if you get a full ToC and a lack of hashes to clean out with Sigil. You might need to create various other heading level styles as well.
It’s your call of course, but it sounds to me like you are battling with a beast that has multiple different types of content, and with settings that are essentially all-or-nothing. You’re going to be stuck doing manual labour to clean things up without a lot of workarounds being applied.
So I guess overall the moral of the story is to stick with one method or another unless you plan for a more hybrid approach from the start.
At any rate, now that I know what settings you are using, the way to get a list of lines in a paragraph with this conversion setting enabled:
- Select the entire multi-line block in the editor.
- Use the
Format ▸ Preserve Formatting command.
- Back in Compile, General Options tab, tick the Treat “Preserve Formatting” as raw markup checkbox.
Consider that tool in other areas where you may have raw markup that you’re having to clean up in one form or another.
As for the rest, I think I miscommunicated a bit there, as I certainly did not mean to imply that italics = emphasis and nobody should ever use italics except for emphasis. Rather the whole point of the solution I gave was to allow for italic formatting in cases where it is appropriate and semantic to do so—without using the emphasis markup to force it, but I’ll follow up in the other thread.
The legal world still hasn’t figured out what to do with the loss of page numbers, this is probably the reason why ePub’s have not overtaken pdf’s: you just can’t cite to an ePub like you can to a pdf.
Yeah, that’s an interesting problem indeed. Amazon actually came up with a really good solution for it, using its “Location” metadata. I forget the precise details of it, but one can extract a location from any sentence (roughly), and share that location in a citation or to another reader. They could use the Kindle’s Go To function to jump straight to the reference, no matter their font settings or otherwise (naturally they would need to be using the same edition, but that has always been a natural limitation with paper page numbers as well).
Of course the problem is Amazon’s insatiable greed. With their implementing this solution into a proprietary format nobody else in the world can use, it is only useful to other Kindle users. No doubt they probably patented it and every imaginable variation as well, so nobody else can easily apply the technique to a standard and open format.
Footnotes are troublesome in the ePub world: some readers convert them to end notes, and while clicking on them is supposed to be easy, it is often difficult to navigate back to where you left off in the text.
I’ve never encountered a modern reader that doesn’t have a “back” button or shortcut/gesture somewhere, but yeah, for maximum compatibility you do need to insert a hyperlink that goes back to the footnote marker directly, as Pandoc and Scrivener do.