Once the basic syntax feels familiar, the next problems usually involve the document around it: a table becomes too wide, an image disappears after a move, or a long draft becomes difficult to resume. Work with a copy of a real draft so the checks in this lesson have something useful to reveal.
Make a longer draft easy to enter
Read only the headings first. They should describe the route through the document without requiring every paragraph. If two sections answer the same question, merge them. If one section contains several unrelated topics, split it at the point where the reader's question changes.
Keep research notes close to the paragraph they support while drafting, then remove private reminders before delivery. A temporary “Open questions” section can help you continue writing without pretending an uncertain point is settled. Revisit that section during the final review.
For a long editing session, choose one pass at a time. First repair the structure, then check the evidence and examples, then revise the wording. Switching between those tasks after every sentence makes it harder to notice omissions. At the end of the session, leave yourself a short note about the next unfinished section in a separate working note if it must not enter the final document.
Use the application's displayed shortcuts for frequent actions such as saving and finding text. Keyboard labels differ between operating systems, and older shortcut articles may describe earlier builds. Learn the few actions you repeat rather than relying on an old list of combinations.
Keep tables small enough to read
A table is useful for comparing short facts across the same categories. It works less well when each cell needs several sentences. Put the explanation in ordinary prose and let the table hold the comparison.
| Output | Review before sharing |
| --- | --- |
| HTML | Links and reading order |
| PDF | Page breaks and wide tables |
| DOCX | Headings and table layout |The separator row beneath the headers is part of the syntax. Make sure each row contains the intended number of cells. A literal vertical bar inside a cell may need escaping because it can otherwise be treated as a column boundary. Read the rendered table after changing its structure.
Check the widest row and the last column. A table that fits in a desktop preview may wrap badly on a fixed-width PDF page. Shorten column headings, move long explanations below the table, or divide the comparison into smaller tables. Inspect the generated file after each change that affects layout.
Keep images beside the source
An image can work on your computer and disappear for someone else because its path points outside the folder you sent. An absolute path describes a location on one machine. A relative path describes a location from the document's own folder, which is usually more useful when the whole project needs to travel.
project-notes/
field-report.md
assets/
field-site.pngWith that folder arrangement, the Markdown image can use the following path. The text in brackets should describe what the reader needs from the image.
Move the complete folder when sharing the source. Moving only the Markdown file breaks the relationship with its assets. Choose filenames you can keep stable and check capitalization, especially when a folder moves between operating systems.
After a move, open the Markdown file from its new location and inspect the images again. Export behavior varies by format; an image visible in the editor is not proof that it is embedded in an output file. If a converted result contains a caption instead, compare that result with what the recipient actually needs.
Leave a source you can resume tomorrow
Save the source in a folder you already back up. Keep a reviewed copy before experimenting with substantial changes to an important draft. Local files give you control over where the document lives, but the existence of a file is not a backup policy.
If another application changes the source while you are editing, review the external-change notice before choosing how to continue. Do not assume the version currently visible is the newest one on disk. Preserve your unsaved text while deciding which changes to keep.
Separate the editable source from delivery copies. A folder can contain the Markdown draft, its assets, and a clearly named export without making all of them competing originals. When feedback arrives, return to the source and generate another reviewed output.
Review structure before polishing appearance
Begin with the title and heading order, then read the preview in sequence. Look for a paragraph under the wrong section, an accidentally joined list, or a code fence that continues past the intended example. These errors affect meaning even if the font and spacing look attractive.
Open important links instead of checking only their labels. Inspect image descriptions and paths. For code or mathematical notation, compare the rendered output with the source so an unclosed delimiter does not pass unnoticed. The advanced guide covers those forms in more detail.
A useful review uses the document's difficult cases. Find the widest table, the longest code line, and the section with an image beside an explanation. If the draft contains Chinese or mixed-language text, inspect that text in the export too. A correct opening page does not establish that every later page is readable.
Convert a copy for the next reader
Choose the output for the next task. HTML is convenient for a browser-readable copy. PDF has fixed pages and needs page-boundary checks. DOCX is useful when the recipient will continue in a word processor. Use the conversion guide for supported formats and current limits.
For PDF, inspect a heading near the bottom of a page and any table that crosses a page boundary. Check page numbers and characters that might be missing. For HTML, follow links and inspect the reading order. For any output, open the generated file rather than relying on the successful-conversion message alone.
If the next step is a blog, finish the source review before preparing a publishing job. Each destination still needs its own formatting and permission checks. The publishing workflow explains the distinction between a prepared article, a remote draft, and a public post.
Before ending, reopen the saved source, check that its assets are still beside it, and make sure the recipient can tell which file to use. These checks also give you a practical starting point when a reported export problem needs to be reproduced.