I've altered the epub template to display more information. It works fine, except when I specify images that refer to a local file. e.g. <img src = "my_file.png">. The code is there in the epub, but the image file isn't.
Pandoc does not parse the template as HTML, so it misses the <img> element when collecting media elements for inclusion in the EPUB. A quick and simple work-around is to list the missing images in some unused metadata field. E.g.,
---
missing-images: |
---
Store the above in a file and pass it to pandoc via --metadata-file. This makes pandoc aware of the file, forcing its inclusion.
One could automate it by letting pandoc parse the template and extract the image information, e.g. with a pandoc Lua filter, but that's likely to be more trouble than it's worth.
Related
I am trying to customise the title page where the backend output is docbook. title, subtitle etc are all output correctly. But I cannot seem to get the title logo to output.
I have tried:
:title-logo-image: image:images/titleimage.png[]
The only way I can get this to kind-of work is to directly embed the image in the title text. But that is not ideal.
Is this possible when using docbook?
Since you convert AsciiDoc to DocBook I am assuming you are writing a book. The parameter title-logo-image you are using is not for asciidoctor (conversion to HTML and DocBook) but for asciidoctor-pdf (conversion to PDF), see https://docs.asciidoctor.org/pdf-converter/latest/title-page/#logo. If you are okay with PDF instead of DocBook you should try asciidoctor-pdf, it also allows you to customize your page it is pretty nice.
I am not sure what you expect though, is it a big picture on the first page? are you talking about the cover? If so you might want to create your own DocBook cover element and inject it in your DocBook file. This is possible in AsciiDoc by using a DocInfo file. You create a docinfo.dbk file where you write the <cover> element and the file content will then be injected in the <info> Element in the resulting DocBook file.
I am working on a template generator usecase which involves a tinyMCE editor with the option to export and import to/from Microsoft Word files.
I use SpireDoc to save html files as docx and restore docx back to html.
The problem is, as this is a template generator, I need to include some metadata along some of the html nodes. Say a user's name is inserted in the tinyMCE and the html code would look like this:
<span data-type="user-name" data-id="234">Some Name</span>
Once converted to docx, all the data- tags are stripped off. Is there a way I could tell SpireDoc to preserve those tags and to put them back in the html file when I convert docx back to html?
I know I could resort to ugly placeholders like ##USERNAME|ID## but I would prefer if I could keep my metadata tags because I also need to do that for images and the user will not be able to size/format the image if it was just a text placeholder.
Is there a way, either in YAML or within an R script/Rmd, to turn on the fenced_divs pandoc extension?
If possible, I would prefer being able to turn on fenced_divs without having to specify it inside each individual output format in the YAML block but rather once, globally.
The reason is that I want to have within-document links to items that are not headers using the same code for .docx and .html.
Thanks.
I'm converting docx files using pandoc 1.16.0.2 and everything works great except right after each image, the size attributes are showing as text in teh
{width="3.266949912510936in"
height="2.141852580927384in"}
So it shows the image fine in the md but also the size tag as plain text right behind/after/below each image. The command I'm using is:
pandoc --extract-media ./media2 -s word.docx markdown -o exm_word2.md
I've read the manual as best I can but don’t see any flags to use to control this. Also most searches are coming up where people want to have the attributes and control them.
Any suggestions to kill the size attributes or is my markdown app (MarkdownPad2 - v-2.5.x) reading this md wrong?
Use -w gfm as argument in the command line to omit the dimensional of Images.
You could write a filter to do this. You'll need to install panflute. Save this as remove_img_size.py:
import panflute as pf
def change_md_link(elem, doc):
if isinstance(elem, pf.Image):
elem.attributes.pop('width', None)
elem.attributes.pop('height', None)
return elem
if __name__ == "__main__":
pf.run_filter(change_md_link)
Then compile with
pandoc word.docx -F remove_img_size.py -o exm_word2.md
There are two ways to do this: either remove all image attributes with a Lua filter or choose an output format that doesn't support attributes on images.
Output format
The easiest (and most standard-compliant) method is to convert to commonmark. However, CommonMark allows raw HTML snippets, so pandoc tries to be helpful and creates an HTML <img> element for images with attributes. We can prevent that by disabling the raw_html format extension:
pandoc --to=commonmark-raw_html ...
If you intend to publish the document on GitHub, then GitHub Flavored Markdown (gfm) is a good choice.
pandoc --to=gfm-raw_html ...
For pandoc's Markdown, we have to also disable the link_attributes extension:
pandoc --to=markdown-raw_html-link_attributes ...
This last method is the only one that works with older (pre 2.0) pandoc version; all other suggestions here require newer versions.
Lua filter
The filter is straight-forward, it simply removes all attributes from all images
function Image (img)
img.attr = pandoc.Attr{}
return img
end
To apply the filter, we need to save the above into a file no-img-attr.lua and pass that file to pandoc with
pandoc --lua-filter=no-img-attr.lua ...
I want to have a template variable pre-processed in a markdown doc.
I tried converting the filename to file.html.md.eco but it just comes out as plain text - ie the markdown plugin doesn't seem to get applied.
The file just as html.md renders fine.
Is it needed to add the plugins to the docpad.coffee to make sure they're applied when using multiple passes?
the FAQ states how to use multiple processors
http://docpad.org/docs/faq
... Alternatively, we can get pretty inventive and do something like this: .html.md.eco which means process this with Eco, then Markdown and finally render it as HTML.