I’m using Drafts as a way of checking how a Markdown processor should behave. (This is so I can keep my md2pptx Markdown → Powerpoint code as close to Markdown-compliant as possible.)
I wanted to add some entity references in a code block. In particular using the hexadecimal form to get numbers in circles. (The idea - for a real presentation I’m working with a friend on - is a code block is above a table on a slide and the circled numbers are used to relate rows of explanations in the table to items in the code.)
I had assumed that triple backtick, <pre>, and <code> would not convert entity references to actual Unicode characters.
But, testing with Drafts, all three do. For example % converts into a percent sign in all three cases.
So, I just want to check: Should I be seeing this behaviour in Drafts? And it’s it therefore safe to assume it’s standard Markdown behaviour?
I don’t think I’ve asked for details of which Markdown processors are being used.
One thing I haven’t tested yet is code blocks done by tab indentation. (To be honest that’s not how I would prefer to create code blocks - as I use mdpre to embed files of content instead.)
Just to comment a little more on the “circled number” use case:
There isn’t a nice eg &circle2; entity reference for “2 in a circle” in HTML. But you can use eg &#AA11; and it will convert to the corresponding Unicode character.
In mdpre I can create my own symbols and can already do one of two things in mdpre:
- Convert to the corresponding Unicode character(s).
- Convert to entity reference(s) and have the Markdown processor do the conversion to Unicode.
I used plurals in brackets above because, of course, a symbol can expand to whatever you like; It’s just string substitution.
I would assume Drafts will handle either Unicode characters or (hex) entity references.
I add this comment in the hope others might use a wider range of characters in their drafts.
The correct encoding for encircle 2 in HTML is ② (② - see ref).
This is what I get when using standard HTML entities in and out of a code block, which seems correct:
I think your entity is just not being recognized by the Markdown parser as a valid entity and is getting ignored as such.
Note: I get this behavior with either MultiMarkdown or GitHub parsers.
1 Like
Thank you! The parser is, of course, my own code.
But you’ve confirmed I ought to teach my parser to handle these. So this is very useful to me.
