I'm considering to use Bookdown to write an academic paper. This includes the data processing and analysis code, plus everything else.
I know how to use Bookdown to write books where each .Rmd document creates its own .html page and a book chapter in a LaTeX PDF. I can also see how to use bookdown to write a single .Rmd that becomes a multi-page website and an article-style PDF. At least, that is what I think I see in the bookdown documentation
But what I am trying to figure out is how to have multiple .Rmd files that become a single article-style PDF. I want to have more than one .Rmd to keep the runtime down and my work somewhat organized, but I am not writing a book. It seems as though bookdown is built to turn document breaks into chapters, and I want them to be turned into sections. Am I missing something obvious, or is this going to require a bit of hacking to make it work?
It seems your actual question is how to turn the top-level headers into sections instead of chapters. It depends on the documentclass field in index.Rmd. The default value of this field is article, which means you get sections instead of chapters. Top-level headers are converted to chapters only if the documentclass is for books (e.g., documentclass: book here: https://github.com/rstudio/bookdown-demo/blob/master/index.Rmd#L7).
Then, to render multiple Rmd files to a single PDF, use bookdown::render_book() instead of rmarkdown::render().
Related
I remember there was a time that when you type # in R markdown it will immediately transfer to the heading output. Also, when you type **bold** it will immediately show the text in bold. But now I can't find a way to do this.
Is it possible to show the markdown output in the .rmd document? Thanks!
This behaviour will depend on the text editor you use. Some Markdown editors have a "What You See Is What You Get" (or WYSIWYG) philosophy that will do exactly what you describe. You can find examples of WYSIWYG Markdown editors online, I personally have only tried Typora. But as far as I can tell, none of them seem to support Rmarkdown (perhaps someone has made an Rstudio add-in?).
On the other hand, in the early days of knitr, it used to support Lyx (I don't know if it still does), which is maybe closer to what you have in mind? See this post for an example: https://yihui.org/knitr/demo/lyx/
I'm planning to use R markdown for reporting health checkup data in company. What I concern about is that if html file produced by r markdown contain the raw data (such as patient name) and accesible via that file in anyway. If that is the case, is there any way to avoid that?
This is difficult to answer without an example of your data (which I realise will be hard to share, given your question).
Basically, there's nothing in the html-version of Rmarkdown that would necessarily embed the data if you don't ask it to. If all you're planning to do is to summarise and ignore (or anonymise) individual cases then Rmarkdown should work fine.
For more information, take a look at the useful help page for html pages using Rmarkdown.
I hope this helps you.
When converting from some format (say, HTML or Docx) to Markdown in Pandoc, is it possible to render all footnotes in the inline style ("this is the main text^[this is a footnote]") rather than as numbered references with a corresponding list at the end of the document? I want to work on my Markdown documents (converted from a Docx of my thesis) as master texts, but now if I add a new footnote it messes up the numbering.
Alternatively, is there another convenient way (i.e. not Pandoc) that this could be done? Cutting text in one part of a file and adding corresponding text in another part seems a bit beyond a simple regex.
Thanks in advance for any help.
EDIT: I've just hacked up an extremely simple Python script to do this, in case anyone else has the same issue.
Pandoc's Markdown syntax is quite flexible about footnotes:
The footnotes themselves need not be placed at the end of the document. They may appear anywhere except inside other block elements (lists, block quotes, tables, etc.).
Like:
Here is a footnote reference[^1] and some more text.
[^1]: Here is the footnote.
Here's the next paragraph.
However, the Markdown Writer (the module that generates markdown files, as opposed to reading them) currently simply places all of them at the end of the document. But this could be implemented behind a flag, similar to the --reference-links flag. Feel free to submit an issue or pull request!
Inline footnotes and references are quite nice for writing and editing markdown documents, but cumbersome for reading them.
I used ltrgoddard's inliner with success to process several files that I use with pandoc and latexmk to produce PDF. inliner works well for transforming end-style references to inline style references in an already-written document.
Cross references to other questions and clues for posterity:
Convert markdown links from inline to reference
Vim plugin for adding external links
Also see http://drbunsen.github.io/formd/
and https://instant-thinking.de/2014/02/20/markdown-footnotes-with-vim/ for more info re: formd, which should work for converting inline references end-style references, and vice-versa.
Note that formd works on URLs and ignores footnotes, so this may be seen as a similar project (with different goals) but not an alternative.
Are there any C/C++ libraries available that can be used in creating, loading and saving files in .odt-format?
Alternatively, where can I find tutorial-like information on implementing .odt(/ODF) specifications?
This site: OASIS OpenDocument Essentials seems to cover the problem, including howto-examples and shortcuts.It's quite nicely done and easy to follow.
Flexibility can be perceived as complexity. If you don't need the
flexibility, create a template ODT and just fill in the content as
needed. As mentioned, there exist XML parsers to actually handle IO.
ODT isn't a plaintext file, so some complexity/difficulty is expected.
– Ioan
From the link:
The Virtues of Cheating
As you begin to work with OpenDocument files, you may want to write a
program that constructs a document with some feature that isn’t
explained in this book—this is, after all, an “essentials” book. Just
start OpenOffice.org or KOffice, create a document that has the
feature you want, unpack the file, and look for the XML that
implements it. To get a better understanding of how things works,
change the XML, repack the document, and reload it. Once you know how
a feature works, don’t hesitate to copy and paste the XML from the
OpenDocument file into your program. In other words, cheat. It worked
for me when I was writing this book, and it can work for you too!
I'm trying to find out if there's a way to embed an editable text cell in a PDF generated in a Qt application. I'm currently using QPrinter to generate the PDF, but if there's another library that could do this, that would be fine. The environment is limited, though, to C or C++, so libraries like iText are out. In terms of form capabilities, this pdf,
http://examples.itextpdf.com/results/part2/chapter08/text_fields.pdf, is a good example with the exception that I don't need a password text field.
Thanks,
Frank
This may not be terribly helpful, but I'll throw it out there anyway.
wkhtmltopdf is based on QTWebkit.
One of its command line options is to convert HTML fields into PDF fields (off by default).
There's almost no pdf-related code within wkhtmltopdf. Certainly nothing dealing with fields. Something upstream is doing the PDF conversion for them.
So find out what that "something" is and you're golden.
EDIT: That or spend a lot of time writing JNI wrappers for iText. :/ Having done so myself, I can say it'd be much more interesting to write a JNI generator tailored to iText, but far more practical to write a Java app that uses iText and then make JNI calls from your C/C++ app to pass the data it'll need and retrieve any response.
The form field borders are a part of the page, not the field itself. Odd, but that's not the first time I've encountered it. Our own software, LiquidOffice, used to generate fields with backgrounds AcroForms couldn't support the same way (now we use an icon-only button).
Those Real PDF Fields have their visibility flags set to "visible but doesn't print" within the pDF. I doubt wkhtmltopdf will let you control that directly. Patch time.
BUT, you could make a second pass with some PDF manipulation library to go through and change the visibility settings on your fields. I'm partial to iText, but there are many other fish in that particular sea.