With the raw latex explicitly identified/marked as such as recommended above the compilation takes minutes instead of hours. To add to my embarrassment over this difficulty I now remember that you told me not long ago to do this when pandoc goes postal. I guess I was too focused on the fact I was creating an EPUB not a latex/pdf document to remember this piece of advice. After adding hundreds such ```{=latex} tags the code does not look any cleaner but it definitly addresses the problem. As to the generation of a pdf off of the same source it takes quite a long time but nothing out of the ordinary.

Thank you for your patience

On Wednesday, October 28, 2020 at 8:04:44 PM UTC-4, John MacFarlane wrote:

As I mentioned, --trace is the way to get an internal snap shot
of parsing -- at least at the block level.  It sounds as if
that did tell you where the parser is getting stuck (it would
be AFTER the last traced block).

Putting raw tex blocks inside

```{=latex}
...
```

(the raw attribute syntax) will help the parser in tricky cases,
so you might try that.

"cjns...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <cjns...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> Sorry for the confusion.... copy-pasted the wrong pandoc command. The one I
> actutally used  for this particular run that "took seconds" was:
>
> pandoc -o epub/test.epub md/title.txt md/* --css=css/stylesheet.css
> --epub-embed-font=fonts/* --epub-cover-image=images/cover.png -f
> commonmark_x
>
> And yes I did see (same as the raw latex stuff) the content of the
> title.txt file verbatim in the output.
>
> So basically  in my use case this run of pandoc did little more than the
> cat command and format the output as an EPUB file.
>
> I have tons of script/regex-generated of both HTML and LaTeX code in this
> source so it has to be pandoc.markdown input.
>
> The odd thing is that I have been doing this for ages (even Vol. I of this
> same book which is similar) and never had  anything that took ages to
> compile.  
>
> Otherwise with nightly and  without the "-f commonmark" flag the situation
> is unchanged.
>
> Is there any way I could take a storage dump... backtrace... or something
> when I kill the hung job?
>
> Would some kind of filter that takes some kind of snapshot of the internal
> state of the process help?
>
> Thanks,
>
> CJ
>
> P.S. I apologize for the messy reports I have sent in lately but I'm having
> major problems with this particular google group. I had to switch to google
> chrome (a mess on linux. I normally use firefox) in order to be able to
> post. And the posts I tried to send from my mail client never made it to
> the group. I think I mentioned that this is not caused by my local setup
> since I used someone else's account/machine and it still didn't go through.
> Any chance someone might look into this at some point?
>
> On Tuesday, October 27, 2020 at 8:29:03 PM UTC-4 John MacFarlane wrote:
>
>> "cjns...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <cjns...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>
>> > With the nightly version (2.11.0.4)
>> >
>> > /tmp/pandoc -o epub/test.epub md/title.txt md2/ch*.md
>> > --css=css/stylesheet.css --epub-embed-font=fonts/*
>> > --epub-cover-image=images/cover.png
>> >
>> > the conversion took seconds.
>> >
>> > But pandoc complains that,
>> >
>> > [WARNING] This document format requires a nonempty <title> element.
>> > Defaulting to 'title' as the title.
>> > To specify a title, use 'title' in metadata or --metadata title="...".
>> >
>> > And the epubcheck report the following errors probably related to the
>> above
>> > warning:
>> >
>> > ERROR(RSC-005): epub/test.epub/EPUB/content.opf(9,14): Error while
>> parsing
>> > file: element "metadata" incomplete; missing required element "dc:title"
>> > ERROR(RSC-005): epub/test.epub/EPUB/nav.xhtml(11,134): Error while
>> parsing
>> > file: Anchors within nav elements must contain text
>> >
>> > Check finished with errors
>> > Messages: 0 fatal / 2 errors / 0 warnings / 0 info
>> >
>> > epubcheck completed
>> >
>> > The title.txt file contains:
>> >
>> > % URBAIN DUBOIS
>> > % La cuisine classique — Volume II
>>
>> Weird. This SHOULD work. Are you seeing anything
>> of this in the resulting epub? (I.e. did it get parsed,
>> but not as metadata? If so, maybe you need a blank line
>> at the end of title.txt.) (Also, I assume your input
>> format is pandoc markdown? commonmark_x doesn't include
>> an extension for this kind of title.)
>>
>> > When I take a look at the output everything looks good except that the
>> raw
>> > latex bits are now included verbatim as if they were part of the
>> text/data.
>>
>> They shouldn't be -- again, is pandoc markdown your input format?
>> Maybe a sample of how these occur in the markdown file?
>>
>>
>
> --
> 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-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/824220b2-6c2e-4c60-a935-e908f573a3d7n%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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/ecd86bee-8049-471a-a97b-a7be98e08c46o%40googlegroups.com.