public inbox archive for pandoc-discuss@googlegroups.com
 help / color / mirror / Atom feed
From: James Madgwick <madgemade-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: pandoc-discuss <pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
Subject: Re: Raw content not working in header-includes for ODT
Date: Wed, 30 Jun 2021 13:10:30 -0700 (PDT)	[thread overview]
Message-ID: <eed48a94-5f75-4583-97d0-5ad1a00af64bn@googlegroups.com> (raw)
In-Reply-To: <yh480kim1vrvwi.fsf-pgq/RBwaQ+zq8tPRBa0AtqxOck334EZe@public.gmane.org>


[-- Attachment #1.1: Type: text/plain, Size: 5121 bytes --]

Yes that makes complete sense. A defaults file would be a good alternative 
to using --metadata-file, although I'd like to have everything in one file 
which is why I was using the metadata file initially, but it doesn't look 
like there is a way to do this for ODT.

Considering how header-includes is interpreted (contents wrapped in 
\texttt{} and placed before \begin{document}), I don't think the 
header-includes should be processed at all when ODT is the input and 
Tex/PDF is the output. If any value whatsoever is given for 
header-includes, it is certain to result in invalid LaTex because the 
\texttt{} generated is placed before \begin{document} which will always be 
invalid LaTex.

As an improvement, it would be better if Pandoc refused to allow 
header-includes in a --metadata-file for this format (and potentially 
others which don't support raw_attribute). I can't see any use for the 
current behaviour. I've not looked at the code for Pandoc itself so this 
may well be an impractical suggestion.

On Wednesday, 30 June 2021 at 20:32:35 UTC+1 John MacFarlane wrote:

>
> Here's my guess about what's going on.
>
> Although the --metadata-file is always parsed as Markdown,
> the extensions that are enabled are taken from the input
> format.
>
> Since odt input doesn't include the raw_attribute extension
> by default (and doesn't even allow it), your content gets
> interpreted in a way you don't intend.
>
> I'm not sure what to suggest in the way of a workaround,
> other than using a defaults file.
>
> James Madgwick <madg...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
> > This seemed to be a bug, but after a taking a closer look it seems to 
> > something which is not supported, although I'm not sure why that is. So 
> I 
> > thought I'd post here to explain.
> >
> > When the source file is ODT, raw content (LaTex commands) in 
> > "header-includes" inside a YAML I'm passing in with '--metadata-file' is 
> > interpreted as plain text, causing invalid LaTex to be generated and 
> placed 
> > in the header. This is ultimately because "The extension raw_attribute 
> is 
> > not supported for odt".
> >
> > This is the YAML:
> >
> > title: Example Title
> > header-includes:
> > - |
> > ```{=latex}
> > \usepackage{tocloft}
> > \setlength{\cftsubsecnumwidth}{2.8em}
> > \setlength{\cftsubsubsecnumwidth}{3.6em}
> > ```
> >
> > When trying to create a PDF with "pandoc Untitled.odt --metadata-file 
> > test.yml -o test.pdf
> > " an error is given by pdftex. This is because the Tex added to the 
> header 
> > is not what I was expecting (based on previously using Pandoc with 
> markdown 
> > as input).
> >
> > This is the invalid (for pre-document) LaTex added to the header:
> >
> > \texttt{\{=latex\}\ \textbackslash{}usepackage\{tocloft\}\ 
> > \textbackslash{}setlength\{\textbackslash{}cftsubsecnumwidth\}\{2.8em\}\ 
> > 
> \textbackslash{}setlength\{\textbackslash{}cftsubsubsecnumwidth\}\{3.6em\}}
> >
> > The Manual says to use the raw_attribute extension to prevent the 
> > 'header-includes' being interpreted as markdown. This is enabled by 
> default 
> > for markdown input, so I thought maybe it is just not enabled for ODT. 
> > Trying "pandoc Untitled.odt --from odt+raw_attribute --metadata-file 
> > test.yml -o test.pdf" gives me the error "The extension raw_attribute is 
> > not supported for odt". At this point I knew I hadn't found a bug.
> >
> > The Manual doesn't say about which formats are supported as input files 
> > when trying to add raw content with 'header-includes' and in effect when 
> > using 'raw-attribute'. It might be useful if this was added to prevent 
> > anyone else trying to use 'header-includes' when the source file is an 
> ODT 
> > document.
> >
> > I was able to get the result I was originally looking for by placing the 
> > LaTex commands in a separate file and using the '--include-in-header' 
> > option. However, I'm not sure why ODT wouldn't support raw_attribute for 
> > just the YAML metadata. I suppose because it's not supported for the 
> input 
> > document (ODT) itself and so isn't available when parsing the YAML 
> either. 
> > I admit this is an unusual case, as normally '--metadata-file' wouldn't 
> be 
> > used with ODT input.
> >
> > Thanks,
> > James
> >
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "pandoc-discuss" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to pandoc-discus...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/pandoc-discuss/b76a0256-4a21-468f-a04e-d7e7b6676d56n%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/eed48a94-5f75-4583-97d0-5ad1a00af64bn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 6676 bytes --]

  parent reply	other threads:[~2021-06-30 20:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-30 18:38 James Madgwick
     [not found] ` <b76a0256-4a21-468f-a04e-d7e7b6676d56n-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2021-06-30 19:32   ` John MacFarlane
     [not found]     ` <yh480kim1vrvwi.fsf-pgq/RBwaQ+zq8tPRBa0AtqxOck334EZe@public.gmane.org>
2021-06-30 20:10       ` James Madgwick [this message]
     [not found]         ` <eed48a94-5f75-4583-97d0-5ad1a00af64bn-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2021-06-30 22:49           ` John MacFarlane

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eed48a94-5f75-4583-97d0-5ad1a00af64bn@googlegroups.com \
    --to=madgemade-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).