Affinity Publisher - Markdown Support

[Gebnar]

I assume Affinity Publisher, like PagePlus X9, will have some sort of "text import" tool. I'd like to humbly request that this tool include an option to import Markdown texts.

 

I do all of my pre-publishing writing in Markdown. It would be fantastic if I could simply import the .md files themselves and have Affinity Publisher convert the text into appropriate styles, build tables, etc. This would be a huge efficiency boost to my workflow.

 

I'm already waiting to buy Affinity Publisher the day it's released. But this small addition would be the perfect icing on the cake!

[Medical Officer Bones]

+1

 

Markdown support would be awesome, I agree.

[KipV]

I have never heard of a feature like that. Can other programs do that like InDesign?

[Gebnar]

I have never heard of a feature like that. Can other programs do that like InDesign?

 

PagePlus X9 already has the "import text" feature that works for a variety of document types (including .odt and .docx), Markdown files are comparatively simple, so an importer of this nature shouldn't be an overwhelming request.

 

As for InDesign, I don't know if it supports markdown, but it also has test import capabilities. In fact, in InDesign, the intended workflow seems to be for the designer to link external files, and have authors edit the external file directly, rather than messing with the design. I assume that this kind of functionality is a small part of why PagePlus is being deprecated in favor of Affinity Publisher.

[MikeW]

ID & QXP support tagged text, a more powerful version of markdown.

 

The default in ID is not to link text files. It supports linked Word and Excel files, but it isn't very reliable over the long haul. (The old Ventura Publisher on the other hand...) InDesign does have a collaborative work flow, but uses InCopy. QXP has a different method.

[Gebnar]

ID & QXP support tagged text, a more powerful version of markdown.

 

I did a quick google of tagged text. It *is* a more powerful version of markdown, but it looks far less elegant for authoring. I love markdown primarily for the way it directs my authoring workflow. My ideal workflow would be to link externally editable markdown files into Affinity Publisher text frames, and have the contents automatically styled using Publisher's built-in styling tools. Obviously there are some limitations to this, but they wouldn't be a hindrance for my needs. Any issues I come across could easily be worked around using the plethora of tools I anticipate Publisher offering.

 

Essentially, if a plugin could be added to PagePlus X9 that allowed me to link .md files and automatically style the imported text - this would greatly enhance my workflow. Everything else I need to do can already be done with X9's tools (barring it's limitations/issues with exporting/publishing - but I expect these are some of the major reasons for the new Affinity packages).

[MikeW]

But one cannot include style names and definitions in markdown, can they?

 

If not, that is one reason why I would prefer tagged text...as well as everything else it offers. And I would prefer the more simplified tagged text language that Em Software uses. I use their plug-ins already with ID & QXP.

[Gebnar]

Markdown includes no styling at all - that's the point. Markdown syntax tags text based on it's intended usage. Originally it was intended to be exported to simple HTML tags that could then be styled with CSS - offering a more "true" separation of content and presentation than basic HTML/CSS.

 

I like markdown *because* when I'm writing I don't concern myself with the styles. I only concern myself with the intent of the text. I put a few hashtags in front of a line = it's a header. I don't have time to care about what it looks like right now. If I'm not doing the final layout, I may not ever care. All I care about is creating the content, and marking the sections for their intended usage.

 

When I'm working on design I don't want text that's already formatted - I just want the content. If someone else wrote it, I really don't want him/her deciding on a font or color. Indicating that something is to be a header, or a bullet list, is enough. Then I can get to work laying out the document and creating a cohesive aesthetic that effectively presents the content.

 

Hence - I like markdown. It does exactly what I need it to, without getting in the way. It's what I use now, with PagePlus X9 - even though there's no importer (i just work around it).

[MikeW]

But then one needs to run through a APub document applying styles. As far as semi-aautomation is concerned, writing in a word processor and importing it--assuming APub will have a clean text import and the ability to map styles--is faster.

 

Tagged text is just that, no formatting. Even when I get a word document destined for laying out in ID or QXP, I run a macro I created that tags the text and exports it out as plain text. The file, when improted, is 100% styled using the paragraph and character styles in the receiving application. That is what layout automation is all about: less manual applying of styles.

 

I just laid out a 400+ page book last week. Importing the tagged text and having the styles applied throughout got me to 99% finished. In less than a minute. It's x number of hours worth of work that importing tagged text saves. Which means I can lay out that many more books in a week, month, year. And that affects whether I take a 3 week vacation or a 3 day weekend holiday.

 

All this may be moot. We don't know what the first X number of iterations of APub will bring. I would doubt the first X releazses would have such a feature. I would be pleasantly surprised if it was included.

 

But I'll vote for something far smarter than markdown. This isn't a hobby for me.

[Gebnar]

This isn't a hobby for me either.

 

If we end up getting some kind of tagged text, i'll work with it. I can make a macro to convert markdown into tagged text..

 

However, the end goal is the same: import plain text, and have APub automatically apply appropriate character and paragraph styles. The only content that doesn't fit into this schema are special pages that aren't part of the normal content flow anyway.

 

If we get a Tagged Text importer, the work of creating a markdown importer will be 99% done anyway. I don't see why we can't have both. I definitely don't see anything wrong with politely requesting an implementation that fits my current workflow.

[MikeW]

I apologize if my responses was seen as raining on your parade. Like you, I'll take whatever Serif offers. Heck, while I'll buy it when it is available, it may be some years before I use it for publications beyond simple stuff.

 

If Serif chooses to provide markdown as an import option, as long as styles can be associated with the incoming stream based upon markdown syntax, that's what I would work with if their DOCX support isn't up to snuff and/or one cannot strip the weird crap in such files and apply clean styles via mapping. markdown would be far preferable in lieu of a clean DOCX import.

[jamratt]

What many of you seem to want in markdown is what InCopy provides in the InDesign family. Or, importing .doc / .docx files and applying similarly named styles, assume one has created styles in InDesign already, and assuming the Word content doesn't turn into vomit on import.

 

Personally, markdown for a Publishing seems like it should just be an import option versus a heavy function of the Publisher environment. Therefore functioning much like InCopy. You could either import the .markdown file or link to it.

 

But for the sake of the vast majority graphic designers please have Character, Paragraph and Object Styles too. That way, those of us who haven't chosen to learn markdown still can apply to any text.

 

Also, InDesign does not support markdown formatting or import. Though some scripts and plugins have been attempted I believe. As InDesign is largely an XML language I wouldn't think it would be too far-fetched to look at the ICML files from InCopy and see if the languages can handoff or convert similarly. So .markdown could be the InCopy of Publisher.

 

All that said, Dear Serif... when a Publisher Beta already? Some soft promises were made of "early next year" at the end of 2015. I'm Publisher away from dropping my Adobe CC subscription.

[Hildy]

I use markdown for basically everything! It's ideal for technical and academic writing. Keeping everything plain text, and human readable, ensures compatibility and portability. The ability to maintain a single source for content, which can easily be exported to any format, is ideal. Divorcing style from content allows for the application of the most appropriate styling in each finished product.

 

InDesign doesn't support importing markdown directly. I currently work around that by using Pandoc. to convert markdown to ICML (InCopy) and then using Place in an InDesign file. It isn't as painless as I'd like, but it works and I have to keep Pandoc around anyway as it's ideal for easily converting markdown to HTML, ePub, Word, and a variety of other formats.

 

I'd kill for APub to handle the import directly. The *ideal situation* would be a Place option, so the APub document will update automatically when the markdown file is edited. Otherwise, I'll need APub to support the import of a file type I can export to via Pandoc to preserve my current workflow.

[tomn]

+1 for Markdown

[Alfred]

InDesign doesn't support importing markdown directly. I currently work around that by using Pandoc.

 

I don't use InDesign but I do use Markdown. Pandoc looks very useful, so thanks for that. :)

[Seweryn]

Hi,

+1 for Markdown.
 

Especially in context of preparing notes in Obsidian and then extracting them to Affinity Publisher.
Would be good to avoid quite error prone "copy-paste" process.

Regards,
Seweryn.

[MikeTO]

2 hours ago, Seweryn said:

+1 for Markdown.

Especially in context of preparing notes in Obsidian and then extracting them to Affinity Publisher.
Would be good to avoid quite error prone "copy-paste" process.

You may wish to comment on the v2 Markdown thread as this v1 thread is from seven years ago and won't have the developers' attention.