Add Markdown file support

[PaoloT]

2 hours ago, MikeW said:

I was, had been, trying to convey that really isn't going to happen no matter the MD format/extension...hence asking Paolo if html5 export would suffice.

I want something different.

- HTML5, an output format, is an accurate graphic description of a web page. It has a high amount of equivalents in how a printed page can be described. Printed and web pages can be exchanged with nearly-one-by-one matching. Publisher would therefore be able at the same time to be used to create printed pages and web pages, with a description that can match nearly exactly. It can at the same time be used to assemble web pages into a linear publication to be printed. This can happen when ePub will happen, being both HTML code.

- Markdown, an authoring tool, is capable of describing the structure of a document and the relative size and role of the individual elements. It can generate code that, when imported into Publisher with an associate template, could give visual shape to the page and project. The level of detail in the page description can't be the same as HTML5, but is high enough to produce a simple publication, still requiring a certain amount of adjustments. At the same time, it can be the end point of a conversion from a Publisher page, even if with the simplification and limitations of a raw page description.

A sophisticate magazine design wouldn't translate with Markdown. HTML5 can do it.

At the same time, a narrative book or an essay, with their simpler page layout, could be transferred even via Markdown.

I see Markdown as a replacement of the Word file format, not an interchange format for page layout. While Word is still the official reference format for narrative to be put in page, Markdown is the de facto reference format for any current real narrative, made of blogs, articles on the web, WordPress pages. We live in a time when long writing is no longer required even to university students. There is a strong need to give shape to the short, fragmentary writing that is the current narrative.

Paolo

 

[v_kyr]

35 minutes ago, PaoloT said:

... I see Markdown as a replacement of the Word file format, not an interchange format for page layout. While Word is still the official reference format for narrative to be put in page, Markdown is the de facto reference format for any current real narrative, made of blogs, articles on the web, WordPress pages. ...

Description parts do remind me to an article about how certain it-magazin articles are created ...

• Wie entsteht ein c’t-Artikel?  (DE)
• How is a c't article created?  (EN google trans)

... but only some small parts of the MD above.

However, all in all I doubt APub will incorporate some template driven MD support here, as they already have problems to get their linking flawlessly working without ending up corrupting files here.

[PaoloT]

6 hours ago, v_kyr said:

Description parts do remind me to an article about how certain it-magazin articles are created

That looks like a typical workflow. It also overlaps how magazine were created in the past, even if with a different approach to publishing and distribution, that also impacts on the organization of the editorial staff.

Yep, it looks like Publisher would be at home in this type of context!

Paolo

 

[Frank Jonen]

13 hours ago, v_kyr said:

Who wants this?

Pretty much every publishing house is looking for ways to reduce overhead. The first who makes a good enough effort in this space, wins.

[v_kyr]

7 hours ago, Frank Jonen said:

Pretty much every publishing house is looking for ways to reduce overhead. The first who makes a good enough effort in this space, wins.

Who want's this was asked/meant for APub markdown export!

[Bryan Rieger]

While I’m not a fan of markdown I find myself using it more and more these days. It occupies a sweet spot in where it’s more than plain text, not as complicated as Tex, and not @!#@! Word. It can be shared with anyone (no special software/version required), incorporated in version control, easily diffed, and converted to and rendered as many different formats. Also, in contrast to a few years back where markdown was firmly a developer centric format, I’m finding it appearing in more and more non-developer contexts (chat, forums, writing apps, etc).

While I can convert markdown to a Word docx file to import into Publisher, I’d much rather cut out the middle step and import the markdown directly—especially if I can maintain the link to and update from the original document.

While Word is still integral to many in publishing, I am running into many others moving towards using markdown at the centre of their workflows.

[v_kyr]

13 minutes ago, Bryan Rieger said:

While I’m not a fan of markdown I find myself using it more and more these days. It occupies a sweet spot in where it’s more than plain text, not as complicated as Tex, and not @!#@! Word. It can be shared with anyone (no special software/version required), incorporated in version control, easily diffed, and converted to and rendered as many different formats.

I for my part being used to it in my IT domain, as I either way have to deal with it on a daily base in development projects. Be it via Jira, Git, GitHub, ..., or writing common readme, about, manual, error-overview and changelog files ... etc. - Word or ODF usage is (at least for me) more customer project specific, so when certain projects do use and rely on these file formats with predefined template files, which have to be used then for certain tasks.

[ben_zen]

On 10/13/2023 at 3:29 AM, An Ex-Affinity User said:

While I can convert markdown to a Word docx file to import into Publisher, I’d much rather cut out the middle step and import the markdown directly—especially if I can maintain the link to and update from the original document.

This is my goal-state. Being able to reference a root document (or documents, I'm really not picky) and take that to editors, if they're savvy work with them in Git/other VCS, and have Publisher pull directly from my source-of-truth documents. This would also mean that I could build print versions in Publisher, and have the same source material export to ePub.

[andrewsimper]

+1 for linked Markdown file support

[lpm]

On 11/24/2022 at 4:04 AM, Frank Jonen said:

This should've been in the previous release but here it is again. Markdown import so we don't have to convert to legacy formats or use crude copy & paste for each article.

Solution: Link Markdown files to text frames like the data merge preview.

That way the documents can be worked on by writers/editors and kept up-to-date via the Resource Manager.

Hello, fellow creatives and Affinity Publisher enthusiasts,

As we navigate through the myriad of tools and formats in our digital workflows, one feature request seems to recur within this forum with noticeable frequency: the integration of markdown (md) import capabilities into Affinity Publisher 2.

Many of us have adopted various workarounds to bridge this gap, such as utilizing the Ulysses app to export md files to docx format—a solution I have personally relied on. However, with the ever-evolving landscape of digital tools, adaptability becomes a challenge. My recent transition to JetBrains Writerside, for drafting and online work, illustrates this perfectly. Writerside’s export limitations to pdf, coupled with Affinity Publisher’s less-than-ideal handling of multi-page text pdfs, underscore a significant workflow disruption. This scenario often leaves us resorting to the cumbersome process of cutting and pasting markdown text directly into Publisher. While this workaround suffices for transferring plain text, it falls short when dealing with md’s more complex features, such as code blocks or tables.

The essence of our workflows today is increasingly intertwined with markdown due to its simplicity, versatility, and widespread adoption. It is curious, then, that a tool as sophisticated as Affinity Publisher does not yet support markdown in a manner akin to its handling of txt, docx, and rtf file formats. This oversight not only hampers efficiency but also limits the creative potential of those who prefer or are required to work in markdown.

Incorporating markdown import functionality into Affinity Publisher 2 would significantly streamline the workflow for a vast array of users, eliminating cumbersome workarounds and fostering a more seamless integration of ideas and content. Such an enhancement would not only acknowledge the evolving needs of the digital publishing community but also affirm Affinity’s commitment to user-centric innovation.

Let’s discuss how this feature could reshape our workflows and potentially elevate the utility and versatility of Affinity Publisher. Your thoughts, experiences, and any additional workaround insights are warmly welcomed and highly appreciated as we collectively advocate for a markdown-friendly future in Affinity Publisher.

Thank you for considering this feature request and for your ongoing contributions to making Affinity Publisher a tool that truly meets the needs of its user base.

[Seweryn]

+1

I am working with text using Obsidian, would be good, if after preparing text I can set all properly and publish using my Affinity publisher.

[areelillmind]

On 2/24/2023 at 10:34 AM, Lee D said:

You can see from this Help article the export formats we support and the available settings for each one. It has been requested so it may be an option considered for a future update.

I think it should be a priority.

On 9/24/2023 at 7:44 PM, Old Bruce said:

Note: I am not a Markdown user.

Can we not use the (plain text) text file from Markdown (that is if there is one) and then run a regular expression find and replace in Publisher to assign Paragraph Styles?

It would help if I could see a Markdown (plain text) text file.

There is a guide to doing exactly this here: https://allaboutchris.org/blog/2023/using-markdown-styles-with-affinity-publisher-2/ but it's a bit hacky aand misses some formatting, not too bad for a short document, but for a book or even a Zine it seems like too much. hassle and risk of error.

Since most of the people here are writers and designers not developers it would be be great for this to be implemented properly within the software.