public inbox archive for pandoc-discuss@googlegroups.com
 help / color / mirror / Atom feed
* Raw content not working in header-includes for ODT
@ 2021-06-30 18:38 James Madgwick
       [not found] ` <b76a0256-4a21-468f-a04e-d7e7b6676d56n-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
  0 siblings, 1 reply; 4+ messages in thread
From: James Madgwick @ 2021-06-30 18:38 UTC (permalink / raw)
  To: pandoc-discuss


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


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-discuss+unsubscribe-/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.

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Raw content not working in header-includes for ODT
       [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>
  0 siblings, 1 reply; 4+ messages in thread
From: John MacFarlane @ 2021-06-30 19:32 UTC (permalink / raw)
  To: James Madgwick, pandoc-discuss


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 <madgemade-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-discuss+unsubscribe-/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.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Raw content not working in header-includes for ODT
       [not found]     ` <yh480kim1vrvwi.fsf-pgq/RBwaQ+zq8tPRBa0AtqxOck334EZe@public.gmane.org>
@ 2021-06-30 20:10       ` James Madgwick
       [not found]         ` <eed48a94-5f75-4583-97d0-5ad1a00af64bn-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
  0 siblings, 1 reply; 4+ messages in thread
From: James Madgwick @ 2021-06-30 20:10 UTC (permalink / raw)
  To: pandoc-discuss


[-- 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 --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Raw content not working in header-includes for ODT
       [not found]         ` <eed48a94-5f75-4583-97d0-5ad1a00af64bn-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
@ 2021-06-30 22:49           ` John MacFarlane
  0 siblings, 0 replies; 4+ messages in thread
From: John MacFarlane @ 2021-06-30 22:49 UTC (permalink / raw)
  To: James Madgwick, pandoc-discuss

James Madgwick <madgemade-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> 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.

You can include metadata in a defaults file (under metadata:),
but only plain string content is possible there.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-06-30 22:49 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-30 18:38 Raw content not working in header-includes for ODT 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
     [not found]         ` <eed48a94-5f75-4583-97d0-5ad1a00af64bn-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2021-06-30 22:49           ` John MacFarlane

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).