You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While writing and maintaining text files, it usually easier to read (especially skimming), diffs are simplier, and long sentences are easy to spot etc.
Moreover, it is easier to navigate by keyboard while reviewing ;)
Thanks for your guidance, @dennisguse . I would definitely be in favor of doing this.
I do not think this would change the presentation of the word document.
Having worked on the Markdown document towards the generation of docx, here are some pain points:
using pandoc, the inline code style is lost in the conversion from md to docx. A work around is to use pandoc to convert md to html, then to open the html file in MS word. That way styles are preserved.
Annex A is full of tables, and paragraphs in table cells have to be on a single line, with tags to handle line breaks. This is quite hard to read. If we stay with Markdown, we may want to use a different layout.
I have created a CMake config to generate the HTML file automatically using Pandoc. It may need further work but it could be a good start point.
This wouldn't change the "rendered" layout - latex/pandoc ignore single line breaks while treating 2+ line breaks as new paragraph.
About Pandoc: would you submit a pull request?
Sounds like a nice feature to integrate.
About tables (in Markdown): depending on the actual content, it might be easier to use enumerated lists if possible.
This, in fact, would also change the HTML layout.
However, I would prefer cleaner Markdown files as long as there is need to automate the HTML rendering (e.g., using it for a web page and therefore requiring frequently updates).
If necessary, the "annual" updates of the recommendation could be done manually (not nice, but doesn't happen often enough).
While writing and maintaining text files, it usually easier to read (especially skimming), diffs are simplier, and long sentences are easy to spot etc.
Moreover, it is easier to navigate by keyboard while reviewing ;)
And there are some more arguments: https://asciidoctor.org/docs/asciidoc-recommended-practices/#one-sentence-per-line
Could we change this after the STL2018 release?
The text was updated successfully, but these errors were encountered: