I opted for a portable install, which was as simple as unzipping (and renaming)
I did a few simple test conversions and found that the
-ofor output) was key. Without it, the next file in line was taken to be a second input file, which did not exist; and as such, an error was thrown.
Starting with a
.txtfile (and converting to the same or
.docx), the text was preserved, but I lost returns (so, line spacing did not stay the same) with both of these one-liners.
.txt to .txt
pandoc.exe test_in.txt -o test_out.txt
pandoc.exe test_in.txt -o test_out.docx
The following conversions all start with a
.txtfile contains all sorts of gobbledygook. The
.htmlpreserves text, but the underlying code uses different encoding (such as <br /> in lieu of my preferred <br>) and looks different (my centered elements no longer are). While the
.odtfiles both kept my first element centered, but left justified everything else.
Thus, in all cases the text (but not the formatting) was preserved.
.html to .txt
pandoc.exe test_in.html -o test_out.txt
pandoc.exe -f html -t asciidoc test_in.html -o test_out.txt
pandoc.exe -f html -t asciidoctor test_in.html -o test_out.txt
.html to .docx
pandoc.exe test_in.html -o test_out.docx
pandoc.exe -f html -t docx test_in.html -o test_out.docx
.html to .odt
pandoc.exe -f html -t odt test_in.html -o test_out.odt
I did not observe any differences in output between the various syntaxes within file types. For instance, I list three ways to convert from
.txt. And for all three, the output was the same.
This is just a first foray into Pandoc, a
Hello World, if you will. There are lots of switches (and therefore, all sorts of options) that I have not begun to look at. But I think it will pay to convert a few small test projects prior to depending on Pandoc to convert anything major.
Still, the basic syntax could not be easier:
pandoc.ext input -0 output