From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.text.pandoc/28732 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: James Madgwick Newsgroups: gmane.text.pandoc Subject: Re: Raw content not working in header-includes for ODT Date: Wed, 30 Jun 2021 13:10:30 -0700 (PDT) Message-ID: References: Reply-To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_120_1920815070.1625083830817" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3346"; mail-complaints-to="usenet@ciao.gmane.io" To: pandoc-discuss Original-X-From: pandoc-discuss+bncBDJIZ4FBYQKBBN476ODAMGQEPQSXPTA-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Wed Jun 30 22:10:34 2021 Return-path: Envelope-to: gtp-pandoc-discuss@m.gmane-mx.org Original-Received: from mail-oo1-f56.google.com ([209.85.161.56]) by ciao.gmane.io with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lygXZ-0000ZH-VA for gtp-pandoc-discuss@m.gmane-mx.org; Wed, 30 Jun 2021 22:10:34 +0200 Original-Received: by mail-oo1-f56.google.com with SMTP id c25-20020a4ad7990000b029020e67cc1879sf2048142oou.18 for ; Wed, 30 Jun 2021 13:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20161025; h=sender:date:from:to:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=N73UwW6jGdJ0Vvh5F8l6Foxsx8w73rcRmsHktTfqAAg=; b=IQSD8XXbHC2afg6Il4/50aYYh/NYxEaaHk8iw5OuRAX0bZeyWOSFRlWEEJICtoendg 9EXbYU4jTbRfEHq8Z2/ugwfYT1XEF80gVDRtP8r/KhjvTVNDjuU2oqylXkZvRKgj7sRy rsVWuDeHTOJNyHTz7Xg+R7WIjIyX4QhFPSfy9JbHGu5Ge+LvbuHzHt6nEIaIp4rjKWkO +CLITRdrgVi8VmUUiQVLSEdjEhOpHEboTcbOiom3qcqDZhpGXFtpmJX7jtumx9nHVvox S/MguUDMu4Gzkpilm/Q8N3P9TuSWeKUSarQZQQLBxF6ajfFCsJGaGyFNXen41bjZFSAh NQIw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=N73UwW6jGdJ0Vvh5F8l6Foxsx8w73rcRmsHktTfqAAg=; b=DRfudix73KWPI/uKODfkHa1M3zr6sU6srtz3FWCvIP01aI/i7W1EeS78YmvkXfy69h GifIAPYcBeD67iYtQyJl4C+7SdObG827esjfu3XIQNLL5W0C5kWTZxaeTyN0DCDtSv43 8hAloRnxaXIIFGjXgyR7OaOKiI++zxOFrItzfc5rivML/laSJKi7JE7WDQkN5n0FIz8Q NuII3TyyiNxNJ2s1G2VedpGhi1Y0XZYh4Oufw9sqemZgjlZ9IoVd0kLwhMU8yeIdGYBU 1bz9aS6/sNdodoODX8EzK5TWR44E1HZadBx3jiHSJdDMyvHkLKiKpnrygC4OuXNqAOPd 7LQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=sender:x-gm-message-state:date:from:to:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=N73UwW6jGdJ0Vvh5F8l6Foxsx8w73rcRmsHktTfqAAg=; b=f+jYXfhV4IWGs+pewssEhcf5GeLE6sGkGsq9uWF4L9rDNGewLVwF/G6iajGb1WEaL8 I16ypI9FLyE42choxYv2uIlUwoJsBmXQslLdkUoikYBl2j6zzYRnC6OueV9gGar8V1B7 278MHV7TAK63hZH8Rh9TJraTROh0zQ6zN8pHuiC1G5bsPmnwC8I0w85FLfAthZMd8fv5 YEtZSIseQWcftYrgpO0csaO52Pd2wczrC0+TI1zU6ZyNwRlsvaqpiAbZMfo3wf3znQXi m2DdTAnMAxAfHf9N1HHUA2gIkOeRBwxKPqYMFriQUkrjVbfGw2esm3nq1ZTZ/HYo3WhE U8cw== Original-Sender: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org X-Gm-Message-State: AOAM532lPV4CMBZ69yo5sBeRAJ1xiJqhyitYskSfaem1+LVbT3UZE9mc 17xP++cnRRD6yioG0+dM4KY= X-Google-Smtp-Source: ABdhPJx0iFGSYGljC80V/TsdhOB1TMsrrrPcDcJTye2F21KR5I3rpW08Y9ErWF1dOzK0yXTahBxAaQ== X-Received: by 2002:a05:6830:90b:: with SMTP id v11mr10460599ott.3.1625083832934; Wed, 30 Jun 2021 13:10:32 -0700 (PDT) X-BeenThere: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Original-Received: by 2002:aca:cf0e:: with SMTP id f14ls1233135oig.5.gmail; Wed, 30 Jun 2021 13:10:31 -0700 (PDT) X-Received: by 2002:aca:578a:: with SMTP id l132mr4534519oib.138.1625083831339; Wed, 30 Jun 2021 13:10:31 -0700 (PDT) In-Reply-To: X-Original-Sender: madgemade-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Precedence: list Mailing-list: list pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org; contact pandoc-discuss+owners-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org List-ID: X-Google-Group-Id: 1007024079513 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , Xref: news.gmane.io gmane.text.pandoc:28732 Archived-At: ------=_Part_120_1920815070.1625083830817 Content-Type: multipart/alternative; boundary="----=_Part_121_568065922.1625083830818" ------=_Part_121_568065922.1625083830818 Content-Type: text/plain; charset="UTF-8" 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 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. ------=_Part_121_568065922.1625083830818 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes that makes complete sense. A defaults file would be a good alterna= tive 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 l= ook like there is a way to do this for ODT.

Co= nsidering how header-includes is interpreted (contents wrapped in \texttt{}= and placed before \begin{document}), I don't think the header-includes sho= uld 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{d= ocument} 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 s= upport 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 w= rote:

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...@g= mail.com> writes:

> This seemed to be a bug, but after a taking a closer look it seems= to=20
> something which is not supported, although I'm not sure why th= at is. So I=20
> thought I'd post here to explain.
>
> When the source file is ODT, raw content (LaTex commands) in=20
> "header-includes" inside a YAML I'm passing in with = '--metadata-file' is=20
> interpreted as plain text, causing invalid LaTex to be generated a= nd placed=20
> in the header. This is ultimately because "The extension raw_= attribute is=20
> not supported for odt".
>
> This is the YAML:
>
> title: Example Title
> header-includes:
> - |
> ```{=3Dlatex}
> \usepackage{tocloft}
> \setlength{\cftsubsecnumwidth}{2.8em}
> \setlength{\cftsubsubsecnumwidth}{3.6em}
> ```
>
> When trying to create a PDF with "pandoc Untitled.odt --metad= ata-file=20
> test.yml -o test.pdf
> " an error is given by pdftex. This is because the Tex added = to the header=20
> is not what I was expecting (based on previously using Pandoc with= markdown=20
> as input).
>
> This is the invalid (for pre-document) LaTex added to the header:
>
> \texttt{\{=3Dlatex\}\ \textbackslash{}usepackage\{tocloft\}\=20
> \textbackslash{}setlength\{\textbackslash{}cftsubsecnumwidth\}\{2.= 8em\}\=20
> \textbackslash{}setlength\{\textbackslash{}cftsubsubsecnumwidth\}\= {3.6em\}}
>
> The Manual says to use the raw_attribute extension to prevent the= =20
> 'header-includes' being interpreted as markdown. This is e= nabled by default=20
> for markdown input, so I thought maybe it is just not enabled for = ODT.=20
> Trying "pandoc Untitled.odt --from odt+raw_attribute --metada= ta-file=20
> test.yml -o test.pdf" gives me the error "The extension = raw_attribute is=20
> not supported for odt". At this point I knew I hadn't fou= nd a bug.
>
> The Manual doesn't say about which formats are supported as in= put files=20
> when trying to add raw content with 'header-includes' and = in effect when=20
> using 'raw-attribute'. It might be useful if this was adde= d to prevent=20
> anyone else trying to use 'header-includes' when the sourc= e file is an ODT=20
> document.
>
> I was able to get the result I was originally looking for by placi= ng the=20
> LaTex commands in a separate file and using the '--include-in-= header'=20
> option. However, I'm not sure why ODT wouldn't support raw= _attribute for=20
> just the YAML metadata. I suppose because it's not supported f= or the input=20
> document (ODT) itself and so isn't available when parsing the = YAML either.=20
> I admit this is an unusual case, as normally '--metadata-file&= #39; wouldn't be=20
> used with ODT input.
>
> Thanks,
> James
>
> --=20
> 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..= .@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/b= 76a0256-4a21-468f-a04e-d7e7b6676d56n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to pand= oc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@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.
------=_Part_121_568065922.1625083830818-- ------=_Part_120_1920815070.1625083830817--