One Markdown source, several finished documents
An article may need to appear on a website, become a PDF for a workshop, and go to someone who wants to edit it in Word.
That is a reasonable set of requests. It can also produce three competing versions of the same writing.
Before exporting, decide which file contains the current text. Keeping a Markdown source gives you a clear place to revise the words while producing outputs suited to each destination.
The conversion tool still matters. Markdown alone does not create every format or guarantee that every feature survives the conversion.
Separate the words from the presentation
A heading describes the role of a section. Its font, spacing, and page placement describe how that role is presented.
This source can stay modest:
# Workshop guide
## Before you arrive
Read the project brief and bring two questions.
## During the workshop
We will review one example together.A website can display it in a responsive page. A PDF workflow can place it within a fixed page size. A Word conversion can map it into document styles.
Those outputs need different checks, even when they begin with the same writing.
Identify content that genuinely differs
Some differences are about more than layout.
A printed guide may need an address written out because the reader cannot click “Directions.” A workshop handout may need space for notes. A web article may have an interactive element that a PDF cannot reproduce.
Decide where those differences belong. A short publication may use a shared source with a small, clearly labeled variant. A larger workflow may need a conversion process that includes or replaces specific content.
Do not force every destination into an identical document merely to keep the source count at one. Keep the common text coherent and make the differences intentional.
Put corrections back where they belong
Suppose someone finds a factual mistake in the PDF. Fixing the exported PDF alone leaves the source wrong. The next export can bring the error back.
Correct the Markdown source, then regenerate the outputs that need the correction.
If someone edits the Word copy, establish how those edits return to the source. You may need to review and incorporate them manually. Conversion in both directions does not guarantee a faithful round trip.
A small handoff note helps: “Please suggest wording changes; the Markdown file remains the publication source.” Adapt the instruction to the review process rather than assuming everyone knows which version wins.
Check the layout for each destination
A narrow web page and a printed page expose different problems.
The website may need a table to scroll or a wide image to scale. The PDF may need a heading kept with the following paragraph. A long code line may need wrapping, a smaller type size, or a different example.
Solve those issues in the relevant presentation settings when you can. Adding blank lines to force one PDF page into shape can create strange spacing in another output.
Keep content edits purposeful. If a paragraph is too long because it repeats itself, revise it. If it is good writing that simply lands at a page boundary, look at the layout first.
Keep the source and its assets together
The working document may depend on images, references, and other files. Include them in the project so the next revision has what it needs.
Name exports clearly enough to identify their purpose and date. Retain the editable source after delivery. When the title changes or another output is requested, you should be able to begin with the current writing.
One source can simplify the work. A clear review and export process is what keeps the outputs aligned.
Source
- Pandoc user guide: one documented example of converting Markdown into multiple output formats, with format-specific behavior.
Keep exploring
Read the Markdown portability for more examples.