You can use the --chapters command-line option to make level-1 headers be treated as chapters. Pandoc will look at the template and do this automatically if you have documentclass{book}. Or, at least, it should -- perhaps some special feature of your setup is preventing this from working. But the most reliable method is to use --chapters explicitly. +++ Franz J Fortuny L de M [Sep 13 15 21:18 ]: > When doing Markdown to LaTeX (for PDF) transformation, we see that if > what is requested is the documentclass book, then the numeric index is > formed starting with Chapter 0 and ending with Chapter 0, as if ALL > sections were from chapter zero. > > This is because you are tranforming the new ONE-POUNT (#, or > > ) as section instead of chapter when the documentclass is book. > > If documentclass is article, then, fine: h1 h2 etc become sections; but > LaTeX demands that h1 becomes Chapter title when a book is generated > from a quite a long markdown text, with h1 (#) symbols considered > Chapter's titles. > > Please, review this; it works perfectly ok when generating an ePub > book, but it fails because the Pandoc transformation mechanis is not > considering the type of documentclass that is being generated in the > LaTeX for PDF machine. > > — > Reply to this email directly or [1]view it on GitHub. > >References > > 1. #2395 — Reply to this email directly or view it on GitHub <#2395 (comment)>.

On Mon, Sep 14, 2015 at 11:05 AM, John MacFarlane <notifications@github.com> wrote: Yes, the current code checks the template directly; it doesn't check the documentclass metadata field. (This code dates from before YAML metadata.) But we could change it to check this too. Ubuntu tends to have old versions of pandoc in the repository. You might consider using the deb package I provide instead, for an up-to-date version. +++ Franz J Fortuny L de M [Sep 14 15 07:43 ]: > Well, the documentclass is set to book in the yaml section of.the > markdown > file and it does honor all other parameters also explicitly mentioned, > such > as geometry margins and binding space, etc. And it generates a latex > with > sections and chapter zero. > Ok I will try the --chapters option. > Was this modified recently? I installed it from Ubuntu and it is the > latest they have at that source. I tried to update and apt reported > nothing > to change or add. > El 14/09/2015 00:41, "John MacFarlane" <notifications@github.com> > escribió: > > You can use the --chapters command-line option to make > > level-1 headers be treated as chapters. > > > > Pandoc will look at the template and do this automatically > > if you have documentclass{book}. Or, at least, it should -- > > perhaps some special feature of your setup is preventing > > this from working. But the most reliable method is to > > use --chapters explicitly. > > > > +++ Franz J Fortuny L de M [Sep 13 15 21:18 ]: > > > When doing Markdown to LaTeX (for PDF) transformation, we see that > if > > > what is requested is the documentclass book, then the numeric index > is > > > formed starting with Chapter 0 and ending with Chapter 0, as if ALL > > > sections were from chapter zero. > > > > > > This is because you are tranforming the new ONE-POUNT (#, or > > > > > > ) as section instead of chapter when the documentclass is book. > > > > > > If documentclass is article, then, fine: h1 h2 etc become sections; > but > > > LaTeX demands that h1 becomes Chapter title when a book is > generated > > > from a quite a long markdown text, with h1 (#) symbols considered > > > Chapter's titles. > > > > > > Please, review this; it works perfectly ok when generating an ePub > > > book, but it fails because the Pandoc transformation mechanis is > not > > > considering the type of documentclass that is being generated in > the > > > LaTeX for PDF machine. > > > > > > — > > > Reply to this email directly or [1]view it on GitHub. > > > > > >References > > > > > > 1. #2395 > > > > — > > Reply to this email directly or view it on GitHub > > <#2395 (comment)>. > > > > — > Reply to this email directly or [1]view it on GitHub. > >References > > 1. #2395 (comment) — Reply to this email directly or view it on GitHub <#2395 (comment)>.