Markdown File Compatibility

[jksmollin]

It seems as though Affinity Publisher does not support importing markdown files for text import. Can this be a feature when the software is released out of beta?

 

Thank you =)

[Taqua]

This is a feature I would love. Markdown is terrific for writing quickly and easily and it would be great if Publisher directly imported them with all the tags getting translated to basic styles or something.

[fde101]

Yes, this would be a good feature.

[Ecifircas]

+1

[Tyson of the Northwest]

Same, I am already using pandoc to convert my markdown files to docx, epub, and pdf for digital publishing.  To be able to pull my markdown into a publisher file and have it auto apply my body, heading, bullet, numbered, emphasis, and strong styles to the text would be amazing.  Especially if it was able to generate and fill tables from markdown and insert the linked pictures.

[sabgaby]

+1. This would be amazing! If it supports Markdown I would be happy, but supporting Pandoc as well will be amazing!!!

[brainwipe]

My workflow for large documents will be to create in Markdown and then import/link the text into Publisher. Big +1 for this feature for me.

Just like others in this thread, I would love it to convert styles into body, heading, bullet, emphasis, strong, quote and tables. Linked pictures are less important for me because I tend to be just using the markdown for copy.

Thanks Affinity!

[Kristian]

+1, with AP updating automatically when the Markdown file is saved. Then I could edit Markdown in VS Code.

[PepGold]

Yeah, count me in!

[zkarj]

This would be a huge boost. Publisher is not a writing environment. As it stands, there does not seem to be a way to get even such simple stuff and emphasis into Publisher from an external source. Can't paste rich text, HTML, nor Markdown.

Markdown seems the obvious choice because it is intended for writing and it is surging in popularity. There will be some choices to be made over variants of Markdown but many software vendors have made their decisions and got on with it.

I'd settle for just headings, emphasis, lists, and links for starters.

[walt.farrell]

10 hours ago, zkarj said:

Can't paste rich text, HTML, nor Markdown.

Pasting rich text (or .docx), or importing via File > Place, should work. If you're having trouble with that, you might want to post a separate topic in the Questions section.

[zkarj]

10 hours ago, walt.farrell said:

Pasting rich text (or .docx), or importing via File > Place, should work. If you're having trouble with that, you might want to post a separate topic in the Questions section.

Goodness knows what I did before because I swear it didn't work when I tried it. But clearly it does now. Thanks.

[NoSi]

Import/Export of Markdown would be very useful because it does not transport any formatting information as RTF, doc(x), … does. It contains only hierarchical  information (plus some general format instructions like bold, italics,…). A plain HTML file (without styles, css) does this, too, but in compare to Markdown it is much more complicated.

In this case it is up to the user which editor she/he/it likes to use for huge text if editing within frames is not that comfortable.

If there would be an assignment to formating (example: "> > >" for three times comment indent could be a format for box, green) it could be a very stable method of text interchange – which would be helpful in multi-output scenarios (PDF, HTML, EPUB, …), too.

[zkarj]

11 hours ago, NoSi said:

plus some general format instructions like bold, italics

Strictly speaking, all of Markdown is "structural" although I would use the word semantic. Markdown (as per the original Gruber spec) does not offer italic and bold but rather emphasis and strong emphasis. The "block" and "span" features of Markdown should be directly applicable to Paragraph and Character styles respectively.

I believe when you start trying to address actual formatting (like colour choice, borders, backgrounds) then it gets very messy very quickly. Markdown writing environments are generally geared to semantic writing only, and so they should be. It's the modern equivalent of the old adage applied in the days when Word ruled the roost: write your content before you format it.

[NoSi]

9 hours ago, zkarj said:

it gets very messy very quickly.

I personally never ever have written a text formatted afterwards. I always come down from a structure (headlines) into detail. Because of that I never have the need of a single format in a single place of a document – I always define a format for a semantic/structural highlighting with multiple occurrences of a type of information. This ist perfectly supported by Markdown, that leaves it to the writer, how a "##" paragraph or *emphasis* and combinations of it will look like printed or on a web page: it depends on the format connected with it.

If »it gets very messy very quickly« this points to a unreflected content and/or structure of a text. I do not believe that this can be improved only by subsequential formatting.

Markdown offers a strict focus to structure instead of appearance. "Form follows function" is a very successful principle.

[zkarj]

I think we're saying the same thing @NoSi. Your mention of bold, italic, green colour, and boxes made me think you were advocating a markup to annotate these. We're passing each other on the terms we use to describe these things. I like the term "semantic markup," which I learned many years ago in the context of HTML, because it conveys that the markup reflects meaning and not presentation. Depending on what type of content is being created, I can see that some presentation decisions may be made that do not reflect meaning but design. For instance a creator might choose to set different background colours to a series of block quotes and these differences serve only to alter the design, not the fact that the quotes differ in some way.

[PaoloT]

On 4/23/2020 at 2:59 AM, zkarj said:

I'd settle for just headings, emphasis, lists, and links for starters.

Well, if it has to be implemented, it might as well be worth supporting the full MultiMarkdown syntax:

https://fletcher.github.io/MultiMarkdown-6/syntax/index.html

Paolo

 

[PaoloT]

After some more experiments, I would say that the most interesting Markdown variant for Publisher is Pandoc. This latter includes several useful things for printed and digital books.

Pandoc is also capable of being the interface from and to several other formats (as shown in their home page: "https://pandoc.org"). Do you want to import and export HTML5? Ditto, create a bridge with Pandoc via the Import and Export commands in Publisher. The same for bibliography data in BibTeX (that can be created with the wonderful BibDesk).

In the blogging and HTML5 era, Markdown is no longer a niche experiment. It is one of the most widespread ways to deliver text.

Paolo

 

[v_kyr]

1 hour ago, PaoloT said:

After some more experiments, I would say that the most interesting Markdown variant for Publisher is Pandoc.

The problem with markdown nowadays is that there are too many flavors ...

Quote

However, there are markup languages that are different. For example the very widely used markup language named Markdown has many flavors to choose from:

• the original writeup and implementation by John Gruber
• Markdown Extra
• MultiMarkdown
• GitHub Flavored Markdown
• CommonMark which tries to standardize the Markdown standard (again)

Pandoc lists six different Markdown flavors as output formats. This is an absolutely bad situation which foils the original idea behind lightweight markup languages. When some web service tells me that I can use "Markdown" for a text field, I have to dig deeper to find out which of those many different Markdown standards the web page is talking about. After this I will have to continue and look for a cheat-sheet of this dialect because nothing is more difficult to differentiate than multiple standards that are almost the same but not really the same. A usability hell. I get furious every time I have to enter this hell.

An additional notion is the lack of standardization of file extensions using Markdown syntax. I've seen .md, .mkdn, .markdown and even .txt (in Markdown).

... thus things like Org Mode could be a better suitable alternative (which works with Pandoc too) here.

[PaoloT]

20 hours ago, v_kyr said:

The problem with markdown nowadays is that there are too many flavors ...

That's the beauty of Pandoc: being sort of a Rosetta Stone for other flavors and formats. Having the ability to import/export it means being compatible with all the supported formats.

Then, it is per-se a variant very aware of books (while the original Markdown was conceived for blogging, and MultiMarkDown evolving from that).

Paolo

[v_kyr]

13 hours ago, PaoloT said:

That's the beauty of Pandoc: being sort of a Rosetta Stone for other flavors and formats. Having the ability to import/export it means being compatible with all the supported formats.

It's supporting the most common formats here (Markdown, Textile, Org Mode, Muse) in both directions parse in/convert to. - A few others it generates/converts only to (AsciiDoc, Markua).