Plain text Unicode formatter

[avidseeker]

Would something like:

$ echo "This is some **Bold Text** and *Italic* and `code` ending with ~~strikethrough~~" \
    | pandoc -f markdown+strikeout -t plain+smarter
---
𝖳𝗁𝗂𝗌 𝗂𝗌 𝗌𝗈𝗆𝖾 𝗕𝗼𝗹𝗱 𝗧𝗲𝘅𝘁 𝖺𝗇𝖽 𝘐𝘵𝘢𝘭𝘪𝘤 𝖺𝗇𝖽 𝚌𝚘𝚍𝚎 ending with s̶t̶r̶i̶k̶e̶t̶h̶r̶o̶u̶g̶h̶ 

be worth considering to be added to Pandoc?

Related Code Gold Stack Exchange

[fiapps]

This appears to rely on the private use area of a particular font. That's fine for code golf, but I doubt it could be considered a standard document format. For things like this and #10027, I would say writing a custom reader or custom writer is your best bet.

Disclaimer: I have never contributed any code to this project, and don't speak for those who have.

[fiapps]

I was wrong about it relying on a private use area. It's using the standard Mathematical Alphanumeric Symbols block. Perhaps pandoc could add support for that to the plain output format. However, pandoc is not limited to English, and trying to support this for other languages becomes complicated. For non-Latin scripts, it just won't work. For Latin scripts that use diacritical marks, composed glyphs have to be decomposed so you can replace the base letter and then hope the font does the right thing with the combining diacritical marks.

So, once again I suggest you start with a custom writer. If you only plan to use it with English, you don't have to handle the difficult cases.

[alerque]

For Latin scripts that use diacritical marks, composed glyphs have to be decomposed so you can replace the base letter and then hope the font does the right thing with the combining diacritical marks.

This is not Pandoc's problem. The same could be said of much simpler use cases where Pandoc feeds content to a typesetter (e.g. Markdown→PDF via LaTeX or whatever) but the font doesn't support the language. It happens all the time. Many fonts not supporting Turkish characters is not a reason to block support for Turkish in Pandoc, neither is "you would have to hope the font does the right thing" an argument for not supporting correct semantic Unicode output with correctly used composed glyphs.

I'm not necessarily advocating for this particular feature (although it might be really useful for previewing documents in a terminal), just pointing out that this line of reasoning isn't a sound way to disqualify a feature. There are lots of things font designers don't even typically realize should would. Those features get added and bugs get fixed when there is content in the wild to use the features with and people request (purchase/sponsor) support for their needs.

[fiapps]

The ability of the feature to work now is relevant to demand for it. But my main point here is that pandoc features have to be robust in a way that custom writers don't have to be. If the custom writer is shared with others, then it is both creating content in the wild and its usage becomes a way to measure demand for an eventual pandoc feature.