* Verbatim text in headers @ 2020-08-05 14:00 Anton Shepelev 2020-08-06 20:17 ` Anton Shepelev 0 siblings, 1 reply; 15+ messages in thread From: Anton Shepelev @ 2020-08-05 14:00 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw Hello, all As distinct from other Markdown processors and other output formats, while rendering DOCX output with Pandoc, inline `verbatim` text in headers does not work so well, because it inherits not only the font, but also the font size from the `Verbatim Char' style. I do realise that it is the right thing to do for running text because most monospace fonts look better at a slightly decreased size (e.g. 12pt Times New Roman and 11pt Courier New), but I still should like to see nice typewriter text in headers: ## The `switch` keyword The only solution that I can now propose without introducing new settings and otherwise compicating the DOCX rendered, is smartly to infer the size for verbatim text for headers from the `Verbatim char' style based on the size of the main header font, using the proportion: verb_hdr = verb_base * hdr_size / base_size where verb_hdr is font size to use for verbatim text in the header, verb_base the base verbatim font size as specified in the `Verbatim char' style, hdr_size the main font size in the header as specified in the `Heading' style of the corresponding level, and base_size the base font size as specified in the `Body text' style. That way, Pandoc will preserve the ratio between the size of the "typewriter" font and of the font of the surrounding text. I use this approach in my GNU Troff macros, and it works well. -- Please, do not forward replies to the list to my e-mail. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers 2020-08-05 14:00 Verbatim text in headers Anton Shepelev @ 2020-08-06 20:17 ` Anton Shepelev [not found] ` <20200806231710.dd08c7f61a90ea23c708d507-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 15+ messages in thread From: Anton Shepelev @ 2020-08-06 20:17 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw I asked: > As distinct from other Markdown processors and > other output formats, while rendering DOCX output > with Pandoc, inline `verbatim` text in headers > does not work so well, because it inherits not on- > ly the font, but also the font size from the > `Verbatim Char' style. I do realise that it is the > right thing to do for running text because most > monospace fonts look better at a slightly de- > creased size (e.g. 12pt Times New Roman and 11pt > Courier New), but I still should like to see nice > typewriter text in headers: > > ## The `switch` keyword I wonder who nobody replied. What is your method of typsetting such headers: # The `switch` keyword # The `ref` and `out` keywords # The `far` and `near` modifiers # The `printf()` function Do you fix them in your Lua filters? Is it better to have this functionality in a Lua filters on in Pandoc itself? -- Please, do not forward replies to my e-mail. ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <20200806231710.dd08c7f61a90ea23c708d507-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: Verbatim text in headers [not found] ` <20200806231710.dd08c7f61a90ea23c708d507-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2020-08-06 20:38 ` Leonard Rosenthol 2020-08-06 20:57 ` Anton Shepelev 2020-08-07 9:09 ` BPJ 1 sibling, 1 reply; 15+ messages in thread From: Leonard Rosenthol @ 2020-08-06 20:38 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 2549 bytes --] Anton - interesting problem. I haven't run into this one myself, though I fully understand the situation. I would think that a separate character style, say "Verbatim Header" that is based on the Header style would be the best option - perhaps using the formula that you defined. Currently, I end up writing such things in Lua filters (as I am more comfortable in Lua and I don't have to wait for updates to pandoc) - but I think that if you agree with the suggestion above, we'd want that in pandoc including in the standard reference.docx. Leonard On Thu, Aug 6, 2020 at 4:17 PM Anton Shepelev <anton.txt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > I asked: > > > As distinct from other Markdown processors and > > other output formats, while rendering DOCX output > > with Pandoc, inline `verbatim` text in headers > > does not work so well, because it inherits not on- > > ly the font, but also the font size from the > > `Verbatim Char' style. I do realise that it is the > > right thing to do for running text because most > > monospace fonts look better at a slightly de- > > creased size (e.g. 12pt Times New Roman and 11pt > > Courier New), but I still should like to see nice > > typewriter text in headers: > > > > ## The `switch` keyword > > I wonder who nobody replied. What is your method of > typsetting such headers: > > # The `switch` keyword > # The `ref` and `out` keywords > # The `far` and `near` modifiers > # The `printf()` function > > Do you fix them in your Lua filters? Is it better > to have this functionality in a Lua filters on in > Pandoc itself? > > -- > Please, do not forward replies to my e-mail. > > -- > 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/20200806231710.dd08c7f61a90ea23c708d507%40gmail.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/CALu%3Dv3JVngmSBL23Lmckh89FT0ivtxnd2%2Bo%2B%3DUchr1ZF%2BVdGeg%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 3724 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers 2020-08-06 20:38 ` Leonard Rosenthol @ 2020-08-06 20:57 ` Anton Shepelev [not found] ` <20200806235733.6c944e913ef52f26b00c2f09-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 15+ messages in thread From: Anton Shepelev @ 2020-08-06 20:57 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw Leonard Rosenthol to Anton Shepelev: > > What is your method of typsetting such headers: > > > > # The `switch` keyword > > # The `ref` and `out` keywords > > # The `far` and `near` modifiers > > # The `printf()` function > > > > Do you fix them in your Lua filters? Is it bet- > > ter to have this functionality in a Lua filters > > on in Pandoc itself? > > I would think that a separate character style, say > "Verbatim Header" that is based on the Header > style would be the best option -- perhaps using > the formula that you defined. Do you propose that the reference document store as many "Verbatim Header" styles as there are "Header styles" -- one per each level? -- with a hard-coded font size precalcualted using the formula? In my opinion, that would be rather clumsy! Or do you mean that Pandoc should generate those styles on- the-fly? > Currently, I end up writing such things in Lua > filters (as I am more comfortable in Lua and I > don't have to wait for updates to pandoc) Are Lua filters so omnipotent? How do you debug them? > but I think that if you agree with the suggestion > above, we'd want that in pandoc including in the > standard reference.docx. It depends on whether your propose to hard-code nine levels of "Verbatim Header" styles. If you do, then I don't agree. Pandoc should be smarter than that or avoid the logic altogether and delegate it to Lua filters -- loth though am I to write them. -- Please, do not forward replies to my e-mail. ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <20200806235733.6c944e913ef52f26b00c2f09-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: Verbatim text in headers [not found] ` <20200806235733.6c944e913ef52f26b00c2f09-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2020-08-06 21:04 ` Dmitriy Krasilnikov 2020-08-06 21:17 ` Leonard Rosenthol 1 sibling, 0 replies; 15+ messages in thread From: Dmitriy Krasilnikov @ 2020-08-06 21:04 UTC (permalink / raw) To: Finn Mathisen [-- Attachment #1: Type: text/plain, Size: 2924 bytes --] If you dont want a char style you should replace the monospaced text with an xml code, wrapping the monospaced text. The xml can be parametrized with font sizes, but pandoc does not know and should not know anything about font sizes of your headings in reference docx file, its none of its concern. чт, 6 авг. 2020 г., 23:57 Anton Shepelev <anton.txt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: > Leonard Rosenthol to Anton Shepelev: > > > > What is your method of typsetting such headers: > > > > > > # The `switch` keyword > > > # The `ref` and `out` keywords > > > # The `far` and `near` modifiers > > > # The `printf()` function > > > > > > Do you fix them in your Lua filters? Is it bet- > > > ter to have this functionality in a Lua filters > > > on in Pandoc itself? > > > > I would think that a separate character style, say > > "Verbatim Header" that is based on the Header > > style would be the best option -- perhaps using > > the formula that you defined. > > Do you propose that the reference document store as > many "Verbatim Header" styles as there are "Header > styles" -- one per each level? -- with a hard-coded > font size precalcualted using the formula? In my > opinion, that would be rather clumsy! Or do you > mean that Pandoc should generate those styles on- > the-fly? > > > Currently, I end up writing such things in Lua > > filters (as I am more comfortable in Lua and I > > don't have to wait for updates to pandoc) > > Are Lua filters so omnipotent? How do you debug them? > > > but I think that if you agree with the suggestion > > above, we'd want that in pandoc including in the > > standard reference.docx. > > It depends on whether your propose to hard-code nine > levels of "Verbatim Header" styles. If you do, then > I don't agree. Pandoc should be smarter than that or > avoid the logic altogether and delegate it to Lua > filters -- loth though am I to write them. > > -- > Please, do not forward replies to my e-mail. > > -- > 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/20200806235733.6c944e913ef52f26b00c2f09%40gmail.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/CALZUCcD7E0jkOcUUwyQ6KW8%3DLk8%2Boj7oJpjxcHpcXkSO8hF70g%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 4041 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers [not found] ` <20200806235733.6c944e913ef52f26b00c2f09-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2020-08-06 21:04 ` Dmitriy Krasilnikov @ 2020-08-06 21:17 ` Leonard Rosenthol 2020-08-06 21:38 ` Anton Shepelev 1 sibling, 1 reply; 15+ messages in thread From: Leonard Rosenthol @ 2020-08-06 21:17 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 3569 bytes --] >Do you propose that the reference document store as many "Verbatim Header" styles as there are "Header styles" -- one per each level? -- with a hard-coded font size precalcualted using the formula? >Or do you mean that Pandoc should generate those styles on- the-fly? I would think they *must* be pre-calculated and live in the reference.docx, since the header styles themselves are stored there (and pandoc) has no information about how I have customized them. So if you tried to create them itself, it would well end up doing the wrong thing. >Are Lua filters so omnipotent? How do you debug them? > I don't know about "omnipotent", as there are definitely things you can't do with them...but they *could* do this particular use case. They could walk the header block, find any included spans with an attribute of verbatim (or whatever it is), and then add the new named-style for it. (OR if you wanted to be very low level, you could put "raw" openxml to just adjust the font size). On Thu, Aug 6, 2020 at 4:57 PM Anton Shepelev <anton.txt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > Leonard Rosenthol to Anton Shepelev: > > > > What is your method of typsetting such headers: > > > > > > # The `switch` keyword > > > # The `ref` and `out` keywords > > > # The `far` and `near` modifiers > > > # The `printf()` function > > > > > > Do you fix them in your Lua filters? Is it bet- > > > ter to have this functionality in a Lua filters > > > on in Pandoc itself? > > > > I would think that a separate character style, say > > "Verbatim Header" that is based on the Header > > style would be the best option -- perhaps using > > the formula that you defined. > > Do you propose that the reference document store as > many "Verbatim Header" styles as there are "Header > styles" -- one per each level? -- with a hard-coded > font size precalcualted using the formula? In my > opinion, that would be rather clumsy! Or do you > mean that Pandoc should generate those styles on- > the-fly? > > > Currently, I end up writing such things in Lua > > filters (as I am more comfortable in Lua and I > > don't have to wait for updates to pandoc) > > Are Lua filters so omnipotent? How do you debug them? > > > but I think that if you agree with the suggestion > > above, we'd want that in pandoc including in the > > standard reference.docx. > > It depends on whether your propose to hard-code nine > levels of "Verbatim Header" styles. If you do, then > I don't agree. Pandoc should be smarter than that or > avoid the logic altogether and delegate it to Lua > filters -- loth though am I to write them. > > -- > Please, do not forward replies to my e-mail. > > -- > 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/20200806235733.6c944e913ef52f26b00c2f09%40gmail.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/CALu%3Dv3JMMSPb6ezfA1tDjaZubJbT-ebbw7wmHBzScsEb2-t9xw%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 4956 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers 2020-08-06 21:17 ` Leonard Rosenthol @ 2020-08-06 21:38 ` Anton Shepelev 0 siblings, 0 replies; 15+ messages in thread From: Anton Shepelev @ 2020-08-06 21:38 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw Leonard Rosenthol to Anton Shepelev: > > Do you propose that the reference document store > > as many "Verbatim Header" styles as there are > > "Header styles" -- one per each level? -- with a > > hard-coded font size precalcualted using the > > formula? [...] Or do you mean that Pandoc should > > generate those styles on-the-fly? > > I would think they *must* be pre-calculated and > live in the reference.docx, since the header > styles themselves are stored there (and pandoc) > has no information about how I have customized > them. So if you tried to create them itself, it > would well end up doing the wrong thing. That means a lot of duplicate work. Cannot Pandoc, or rather its DOCX renderer, calculate and set the correct font size for any `verbatim` text in a head- er, depending of the font size of the corresponding Header style? In other words, does the DOCX render- er have access to the reference document? If it does not, then of course I have to agree you... On the other hand, why not let the renderer access the reference document? It would solve this and other problems, including the one I posted earlier about the indetnation of nested lists, which is cur- rently and deplorably hard-coded. Another example that comes to mind is the formatting of defintion lists in Word. A small left indent in the `Defintion' style gives them professional look, almost like man-pages. But things go bad if one in- serts a code block into a definition, because its left indent is used absolute, i.e. not added to the indent of the containing defintion. In my opinion, the ability to analyse the reference document will do more good than harm and will obvi- ate some of Word's flaws. Word is very "special" in that good WYSWYM systems need now such hackery. Of course, it may be contrary to the design philosophy of Pandoc, but I have to learn it better to under- stand why... -- Please, do not forward replies to my e-mail. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers [not found] ` <20200806231710.dd08c7f61a90ea23c708d507-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2020-08-06 20:38 ` Leonard Rosenthol @ 2020-08-07 9:09 ` BPJ [not found] ` <14a2d64c-3044-5d89-0412-fc06c7f40a7c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2020-08-08 12:18 ` Anton Shepelev 1 sibling, 2 replies; 15+ messages in thread From: BPJ @ 2020-08-07 9:09 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 3127 bytes --] Assuming you don't need the verbatim to be highlighted you could use a span with a custom style instead of a Code element, and define that custom style however you want (search for "custom-style" in the manual!): ``````markdown # The [switch]{custom-style=H1-verb} keyword `````` Since that custom style attribute is a lot to type I would probably use a combination of a class and a Lua filter, especially since the heading text in Markdown has to fit on a single physical line, and so that it doesn't break if I change the level of a heading: ``````markdown # The [switch]{.hv} keyword ## The [ref]{.hv} and [out]{.hv} keywords ### The [far]{.hv} and [near]{.hv} modifiers #### The [printf()]{.hv} function `````` and then in "header-verb.lua": ``````lua -- Template for custom style, where %d will be filled in with -- the heading's level number local style_template = 'Heading %d Verbatim' -- Filter generator for walking a header and fix spans local function mk_span_filter (level) style_name = style_template:format(level) return { Span = function (span) if not span.classes:includes('hv') then return nil end span.attributes['custom-style'] = style_name return span end } end function Header (head) local filter = mk_span_filter(head.level) return pandoc.walk_block(head, filter) end `````` Then in your reference DOCX define the "Heading 1 Verbatim" "Heading 2 Verbatim" etc. styles, presumably as inheriting from "Verbatim Char" as you wish and you are good to go. An irritation is that you apparently can't override bold/italic set in the paragraph style, at least in LibreOffice. Files attached. Tested with pandoc 2.9.2 and LibreOffice 6.0.7.3 On 2020-08-06 22:17, Anton Shepelev wrote: > I asked: > >> As distinct from other Markdown processors and >> other output formats, while rendering DOCX output >> with Pandoc, inline `verbatim` text in headers >> does not work so well, because it inherits not on- >> ly the font, but also the font size from the >> `Verbatim Char' style. I do realise that it is the >> right thing to do for running text because most >> monospace fonts look better at a slightly de- >> creased size (e.g. 12pt Times New Roman and 11pt >> Courier New), but I still should like to see nice >> typewriter text in headers: >> >> ## The `switch` keyword > > I wonder who nobody replied. What is your method of > typsetting such headers: > > # The `switch` keyword > # The `ref` and `out` keywords > # The `far` and `near` modifiers > # The `printf()` function > > Do you fix them in your Lua filters? Is it better > to have this functionality in a Lua filters on in > Pandoc itself? > -- 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/14a2d64c-3044-5d89-0412-fc06c7f40a7c%40gmail.com. [-- Attachment #2: heading-verb.lua --] [-- Type: text/x-lua, Size: 548 bytes --] -- Template for custom style, where %d will be filled in with the heading's level local style_template = 'Heading %d Verbatim' -- Filter generator for walking a header and fix spans local function mk_span_filter (level) style_name = style_template:format(level) return { Span = function (span) if not span.classes:includes('hv') then return nil end span.attributes['custom-style'] = style_name return span end } end function Header (head) local filter = mk_span_filter(head.level) return pandoc.walk_block(head, filter) end [-- Attachment #3: test.md --] [-- Type: text/markdown, Size: 154 bytes --] # The [switch]{.hv} keyword ## The [ref]{.hv} and [out]{.hv} keywords ### The [far]{.hv} and [near]{.hv} modifiers #### The [printf()]{.hv} function [-- Attachment #4: ref.docx --] [-- Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Size: 8298 bytes --] [-- Attachment #5: test.docx --] [-- Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Size: 10163 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <14a2d64c-3044-5d89-0412-fc06c7f40a7c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: Verbatim text in headers [not found] ` <14a2d64c-3044-5d89-0412-fc06c7f40a7c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2020-08-07 9:35 ` Benct Philip Jonsson [not found] ` <389fb88b-aadf-9cfc-3061-9c2dde74bccd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 15+ messages in thread From: Benct Philip Jonsson @ 2020-08-07 9:35 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 4680 bytes --] just after I hit "send" I realized that with just a bit more Lua trickery you can convert a Code element with or without a class into a Span element with a custom-style attribute. Updated filter and md file below and attached. Currently the class check is commented out in the filter to show that it is not strictly needed. Sorry for the lapse! ``````markdown # The `switch`{.hv} keyword ## The `ref`{.hv} and `out`{.hv} keywords ### The `far`{.hv} and `near`{.hv} modifiers #### The `printf()`{.hv} function `````` ``````lua -- Template for custom style, where %d will be filled in with -- the heading's level number local style_template = 'Heading %d Verbatim' -- Filter generator for walking a header and fix spans local function mk_code_filter (level) style_name = style_template:format(level) return { Code = function (code) -- if not code.classes:includes('hv') then return nil end local span = pandoc.Span{ pandoc.Str(code.text) } span.attributes['custom-style'] = style_name return span end } end function Header (head) local filter = mk_code_filter(head.level) return pandoc.walk_block(head, filter) end `````` On 2020-08-07 11:09, BPJ wrote: > Assuming you don't need the verbatim to be highlighted you could use a > span with a custom style instead of a Code element, and define that > custom style however you want (search for "custom-style" in the manual!): > > ``````markdown > # The [switch]{custom-style=H1-verb} keyword > `````` > > Since that custom style attribute is a lot to type I would probably use > a combination of a class and a Lua filter, especially since the heading > text in Markdown has to fit on a single physical line, and so that it > doesn't break if I change the level of a heading: > > ``````markdown > # The [switch]{.hv} keyword > > ## The [ref]{.hv} and [out]{.hv} keywords > > ### The [far]{.hv} and [near]{.hv} modifiers > > #### The [printf()]{.hv} function > `````` > > and then in "header-verb.lua": > > ``````lua > -- Template for custom style, where %d will be filled in with > -- the heading's level number > local style_template = 'Heading %d Verbatim' > > -- Filter generator for walking a header and fix spans > local function mk_span_filter (level) > style_name = style_template:format(level) > return { Span = function (span) > if not span.classes:includes('hv') then return nil end > span.attributes['custom-style'] = style_name > return span > end > } > end > > function Header (head) > local filter = mk_span_filter(head.level) > return pandoc.walk_block(head, filter) > end > `````` > > Then in your reference DOCX define the "Heading 1 Verbatim" "Heading 2 > Verbatim" etc. styles, presumably as inheriting from "Verbatim Char" as > you wish and you are good to go. > > An irritation is that you apparently can't override bold/italic set in > the paragraph style, at least in LibreOffice. > > Files attached. Tested with pandoc 2.9.2 and LibreOffice 6.0.7.3 > > > > On 2020-08-06 22:17, Anton Shepelev wrote: >> I asked: >> >>> As distinct from other Markdown processors and >>> other output formats, while rendering DOCX output >>> with Pandoc, inline `verbatim` text in headers >>> does not work so well, because it inherits not on- >>> ly the font, but also the font size from the >>> `Verbatim Char' style. I do realise that it is the >>> right thing to do for running text because most >>> monospace fonts look better at a slightly de- >>> creased size (e.g. 12pt Times New Roman and 11pt >>> Courier New), but I still should like to see nice >>> typewriter text in headers: >>> >>> ## The `switch` keyword >> >> I wonder who nobody replied. What is your method of >> typsetting such headers: >> >> # The `switch` keyword >> # The `ref` and `out` keywords >> # The `far` and `near` modifiers >> # The `printf()` function >> >> Do you fix them in your Lua filters? Is it better >> to have this functionality in a Lua filters on in >> Pandoc itself? >> -- 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/389fb88b-aadf-9cfc-3061-9c2dde74bccd%40gmail.com. [-- Attachment #2: test-2.md --] [-- Type: text/markdown, Size: 154 bytes --] # The `switch`{.hv} keyword ## The `ref`{.hv} and `out`{.hv} keywords ### The `far`{.hv} and `near`{.hv} modifiers #### The `printf()`{.hv} function [-- Attachment #3: test-2.docx --] [-- Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Size: 10163 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <389fb88b-aadf-9cfc-3061-9c2dde74bccd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: Verbatim text in headers [not found] ` <389fb88b-aadf-9cfc-3061-9c2dde74bccd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2020-08-07 9:38 ` Benct Philip Jonsson 0 siblings, 0 replies; 15+ messages in thread From: Benct Philip Jonsson @ 2020-08-07 9:38 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 4966 bytes --] Forgot to attach the new filter... On 2020-08-07 11:35, Benct Philip Jonsson wrote: > just after I hit "send" I realized that with just a bit more Lua > trickery you can convert a Code element with or without a class into a > Span element with a custom-style attribute. Updated filter and md file > below and attached. Currently the class check is commented out in the > filter to show that it is not strictly needed. Sorry for the lapse! > > ``````markdown > # The `switch`{.hv} keyword > > ## The `ref`{.hv} and `out`{.hv} keywords > > ### The `far`{.hv} and `near`{.hv} modifiers > > #### The `printf()`{.hv} function > `````` > > ``````lua > -- Template for custom style, where %d will be filled in with > -- the heading's level number > local style_template = 'Heading %d Verbatim' > > -- Filter generator for walking a header and fix spans > local function mk_code_filter (level) > style_name = style_template:format(level) > return { Code = function (code) > -- if not code.classes:includes('hv') then return nil end > local span = pandoc.Span{ pandoc.Str(code.text) } > span.attributes['custom-style'] = style_name > return span > end > } > end > > function Header (head) > local filter = mk_code_filter(head.level) > return pandoc.walk_block(head, filter) > end > `````` > > > > On 2020-08-07 11:09, BPJ wrote: >> Assuming you don't need the verbatim to be highlighted you could use a >> span with a custom style instead of a Code element, and define that >> custom style however you want (search for "custom-style" in the manual!): >> >> ``````markdown >> # The [switch]{custom-style=H1-verb} keyword >> `````` >> >> Since that custom style attribute is a lot to type I would probably >> use a combination of a class and a Lua filter, especially since the >> heading text in Markdown has to fit on a single physical line, and so >> that it doesn't break if I change the level of a heading: >> >> ``````markdown >> # The [switch]{.hv} keyword >> >> ## The [ref]{.hv} and [out]{.hv} keywords >> >> ### The [far]{.hv} and [near]{.hv} modifiers >> >> #### The [printf()]{.hv} function >> `````` >> >> and then in "header-verb.lua": >> >> ``````lua >> -- Template for custom style, where %d will be filled in with >> -- the heading's level number >> local style_template = 'Heading %d Verbatim' >> >> -- Filter generator for walking a header and fix spans >> local function mk_span_filter (level) >> style_name = style_template:format(level) >> return { Span = function (span) >> if not span.classes:includes('hv') then return nil end >> span.attributes['custom-style'] = style_name >> return span >> end >> } >> end >> >> function Header (head) >> local filter = mk_span_filter(head.level) >> return pandoc.walk_block(head, filter) >> end >> `````` >> >> Then in your reference DOCX define the "Heading 1 Verbatim" "Heading 2 >> Verbatim" etc. styles, presumably as inheriting from "Verbatim Char" >> as you wish and you are good to go. >> >> An irritation is that you apparently can't override bold/italic set in >> the paragraph style, at least in LibreOffice. >> >> Files attached. Tested with pandoc 2.9.2 and LibreOffice 6.0.7.3 >> >> >> >> On 2020-08-06 22:17, Anton Shepelev wrote: >>> I asked: >>> >>>> As distinct from other Markdown processors and >>>> other output formats, while rendering DOCX output >>>> with Pandoc, inline `verbatim` text in headers >>>> does not work so well, because it inherits not on- >>>> ly the font, but also the font size from the >>>> `Verbatim Char' style. I do realise that it is the >>>> right thing to do for running text because most >>>> monospace fonts look better at a slightly de- >>>> creased size (e.g. 12pt Times New Roman and 11pt >>>> Courier New), but I still should like to see nice >>>> typewriter text in headers: >>>> >>>> ## The `switch` keyword >>> >>> I wonder who nobody replied. What is your method of >>> typsetting such headers: >>> >>> # The `switch` keyword >>> # The `ref` and `out` keywords >>> # The `far` and `near` modifiers >>> # The `printf()` function >>> >>> Do you fix them in your Lua filters? Is it better >>> to have this functionality in a Lua filters on in >>> Pandoc itself? >>> > -- 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/b37cad64-6606-3200-aaf1-2afe6f393711%40gmail.com. [-- Attachment #2: heading-verb2span.lua --] [-- Type: text/x-lua, Size: 627 bytes --] -- Template for custom style, where %d will be filled in with -- the heading's level number local style_template = 'Heading %d Verbatim' -- Filter generator for walking a header and fix spans local function mk_code_filter (level) style_name = style_template:format(level) return { Code = function (code) -- if not code.classes:includes('hv') then return nil end local span = pandoc.Span{ pandoc.Str(code.text) } span.attributes['custom-style'] = style_name return span end } end function Header (head) local filter = mk_code_filter(head.level) return pandoc.walk_block(head, filter) end ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers 2020-08-07 9:09 ` BPJ [not found] ` <14a2d64c-3044-5d89-0412-fc06c7f40a7c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2020-08-08 12:18 ` Anton Shepelev [not found] ` <20200808151809.d2878d07de78b0b3f6606673-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 1 sibling, 1 reply; 15+ messages in thread From: Anton Shepelev @ 2020-08-08 12:18 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw Benct Philip Jonsson: > Assuming you don't need the verbatim to be high- > lighted-> No, I don't. I shall be happy if I can make my Word documents, which I am forced to produce at work, look professional on paper. And for paper, I accept only black on white. > -> you could use a span with a custom style in- > stead of a Code element, and define that custom > style however you want (search for "custom-style" > in the manual!): > > ``````markdown > # The [switch]{custom-style=H1-verb} keyword > `````` Thank you. It is the easiest (and clumsiest) solu- tion. It is also badly redundant in that the writer has manually to sepcify the correct heading level. Futhermore, it is fragile as any program with dupli- cate implicit dependencies: the writer must take care to change the style specification every time the heading level changes, which is a code smell. > Since that custom style attribute is a lot to type > I would probably use a combination of a class and > a Lua filter, especially since the heading text in > Markdown has to fit on a single physical line, and > so that it doesn't break if I change the level of > a heading: Hmmm, no way to split long headings over several lines? Does that mean I cannot have an 90-character heading and keep the source at 72 characters per line? Maybe Markdown should provide a facility to specify long on on several source lines based either on the prefix or on the indent, e.g.: ## This is a long long long long long long long long long long long long lonesome heading split into three lines using list-like syntax ## This is a long long long long long long long ## long long long long long lonesome heading ## split into three lines using list-like syntax Considering the niceties of indent processing in Markdown, the second version would be the more reli- able, if harder to set up in Vim... > ``````markdown > # The [switch]{.hv} keyword > > ## The [ref]{.hv} and [out]{.hv} keywords > > ### The [far]{.hv} and [near]{.hv} modifiers > > #### The [printf()]{.hv} function > `````` This is much better indeed, for the redundancy is gone: this syntax takes care of the heading level instead of having the writer worry about it. > and then in "header-verb.lua": > ``````lua > -- Template for custom style, where %d will be filled in with > -- the heading's level number > local style_template = 'Heading %d Verbatim' > > -- Filter generator for walking a header and fix spans > local function mk_span_filter (level) > style_name = style_template:format(level) > return { Span = function (span) > if not span.classes:includes('hv') then return nil end > span.attributes['custom-style'] = style_name > return span > end > } > end > > function Header (head) > local filter = mk_span_filter(head.level) > return pandoc.walk_block(head, filter) > end > `````` `mk_span_filter()' has misaligned curly braces, but I think I understand what it does: it constructs a processing funciton based the heading level. Was it a deliberate decision in the Pandoc Lua interface to rely on such functional trickery as closures instead of passing information in parameters? Of course, the additinal parameter would have to be untyped, what is a an untyped parameter in a dynamic lan- guage? In C, one has to pass void*, as in qsort_r(): http://man.he.net/man3/qsort . As far as I understand, it is simply impossible to pass additional data to a filter function in any other way than inside a closure. Oh, perhaps one could do it via a global variable, but that is not good either. Yet it would work an single-threaded environment. > Then in your reference DOCX define the "Heading 1 > Verbatim" "Heading 2 Verbatim" etc. styles, pre- > sumably as inheriting from "Verbatim Char" as you > wish and you are good to go. That would be redundant manual work, for a WYSWYM system should automatically infer the font size and style for a verbatim block depending on context. Can Lua filter do it? Can it read the font size from the heading style and automatically calculate the font size of the code block based on that? > An irritation is that you apparently can't over- > ride bold/italic set in the paragraph style, at > least in LibreOffice. In MS Word it is the same with your filter, but I can live with that. > Files attached. Tested with pandoc 2.9.2 and > LibreOffice 6.0.7.3 Thanks a lot, Benct! > just after I hit "send" I realized that with just > a bit more Lua trickery you can convert a Code el- > ement with or without a class into a Span element > with a custom-style attribute. It is a great impovement that makes Pandoc treat verbatime elements in headers in the true WYSWYM manner. > Updated filter and md file below and attached. > Currently the class check is commented out in the > filter to show that it is not strictly needed. > Sorry for the lapse! Come on! You have solved my problem in three ways, every next better than the previous :-) -- Please, do not forward replies to my e-mail. ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <20200808151809.d2878d07de78b0b3f6606673-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: Verbatim text in headers [not found] ` <20200808151809.d2878d07de78b0b3f6606673-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2020-08-08 15:33 ` BPJ 2020-08-08 17:16 ` John MacFarlane 1 sibling, 0 replies; 15+ messages in thread From: BPJ @ 2020-08-08 15:33 UTC (permalink / raw) To: pandoc-discuss [-- Attachment #1: Type: text/plain, Size: 2576 bytes --] > > Then in your reference DOCX define the "Heading 1 > > Verbatim" "Heading 2 Verbatim" etc. styles, pre- > > > sumably as inheriting from "Verbatim Char" as you > > wish and you are good to go. > > That would be redundant manual work, for a WYSWYM > system should automatically infer the font size and > style for a verbatim block depending on context. Can > Lua filter do it? Can it read the font size from the > heading style and automatically calculate the font > size of the code block based on that? There is no way to *define* a DOCX style in Markdown or Lua, but if you use a custom-style attribute for which there is no style defined in the reference document Pandoc creates a stub style inheriting from the default style without modifications. It is quite easy to create a stub Markdown file with only headings at as many levels you need with some code in them, then create a file using the filter and your existing reference doc. Open that file and modify each stub style to inherit from "Verbatim Char" and to have the font size you want, and from then on use that file as reference doc. It's *some* repetitive manual work but not very much. Sorry about the misindented curly brackets. Lua doesn't actually care about indentation, only about a balanced count of opening and closing brackets or balanced `end` keywords for each `function`/`then`/`do` keyword, so I didn't notice at first. A Lua filter is a table mapping element type names (plus some generics like Inline) to functions. My generator function takes the level of the heading, creates a custom-style name from it, then returns a filter with a closure which will take a Code element and "convert" it into a "normal" span with a custom-style attribute with the generated style name. By calling `pandoc.walk_block` within the Header handling function with the Header element and the generated filter as argument the filter is applied to Code elements within the Header element only. Note that the element passed to `pandoc.walk_block` or `pandoc.walk_inline` is not changed in-place; you have to use the return value of the function, which is a different object. -- 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/CADAJKhC8GAockGYu6sWNZ1_MhpxuVNy-3AUjeJzBPCtUZxDM_w%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 3450 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers [not found] ` <20200808151809.d2878d07de78b0b3f6606673-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2020-08-08 15:33 ` BPJ @ 2020-08-08 17:16 ` John MacFarlane [not found] ` <m2sgcxjbxo.fsf-pgq/RBwaQ+zq8tPRBa0AtqxOck334EZe@public.gmane.org> 1 sibling, 1 reply; 15+ messages in thread From: John MacFarlane @ 2020-08-08 17:16 UTC (permalink / raw) To: Anton Shepelev, pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw Anton Shepelev <anton.txt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes: > Hmmm, no way to split long headings over several > lines? Does that mean I cannot have an 90-character > heading and keep the source at 72 characters per > line? Maybe Markdown should provide a facility to > specify long on on several source lines based either > on the prefix or on the indent, e.g.: > > ## This is a long long long long long long long > long long long long long lonesome heading > split into three lines using list-like syntax Actually, commonmark allows multiline setext-style headings, like this: This is a long long long long long long long long long long long long lonesome heading split into three lines using list-like syntax --------------------------------------------- But not axt-style (##). ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <m2sgcxjbxo.fsf-pgq/RBwaQ+zq8tPRBa0AtqxOck334EZe@public.gmane.org>]
* Re: Verbatim text in headers [not found] ` <m2sgcxjbxo.fsf-pgq/RBwaQ+zq8tPRBa0AtqxOck334EZe@public.gmane.org> @ 2020-08-09 8:22 ` BPJ 2020-08-10 21:00 ` Anton Shepelev 0 siblings, 1 reply; 15+ messages in thread From: BPJ @ 2020-08-09 8:22 UTC (permalink / raw) To: pandoc-discuss [-- Attachment #1: Type: text/plain, Size: 2265 bytes --] The limitation doesn't seem necessary in either case. Either everything from the preceding blank line to the line of dashes is a setext heading, or everything between two blank lines which starts with one or more hashes is an atx heading. That said it's probably good style in a modern text in any language not to have very long headings, so IMO the limitation isn't a big problem. -- Better --help|less than helpless Den lör 8 aug. 2020 19:17John MacFarlane <jgm-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> skrev: > Anton Shepelev <anton.txt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes: > > > Hmmm, no way to split long headings over several > > lines? Does that mean I cannot have an 90-character > > heading and keep the source at 72 characters per > > line? Maybe Markdown should provide a facility to > > specify long on on several source lines based either > > on the prefix or on the indent, e.g.: > > > > ## This is a long long long long long long long > > long long long long long lonesome heading > > split into three lines using list-like syntax > > Actually, commonmark allows multiline setext-style > headings, like this: > > This is a long long long long long long long > long long long long long lonesome heading > split into three lines using list-like syntax > --------------------------------------------- > > But not axt-style (##). > > -- > 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/m2sgcxjbxo.fsf%40johnmacfarlane.net > . > -- 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/CADAJKhAZHP%2Bu7h5QUXpXXb2tmemVLDbeeGoFWYOd13EX8OhAYA%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 3410 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Verbatim text in headers 2020-08-09 8:22 ` BPJ @ 2020-08-10 21:00 ` Anton Shepelev 0 siblings, 0 replies; 15+ messages in thread From: Anton Shepelev @ 2020-08-10 21:00 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw John MacFarlane: > Actually, commonmark allows multiline setext-style > headings, like this: > > This is a long long long long long long long > long long long long long lonesome heading > split into three lines using list-like syntax > --------------------------------------------- > > But not axt-style (##). Thanks. I did not know it and thought both syntaxes equal in power. It is shame they are not, because I much prefer ATX style. PBJ: > The limitation doesn't seem necessary in either > case. Either everything from the preceding blank > line to the line of dashes is a setext heading, or > everything between two blank lines which starts > with one or more hashes is an atx heading. ATX headings do not need a blank line, to begin with, which is why I proposed another rule for mul- tiline ATX headings. > That said it's probably good style in a modern > text in any language not to have very long head- > ings, so IMO the limitation isn't a big problem. You are correct, and that applies to computer pro- grams too, but for reasons of generality all good WYSWYM systems and programming languages have provi- sions for breaking up of *any* text into shorter lines, for exceptions will occur. I can find myself in need of writing a 73-character heading any day now, and I don't what to dread that moment :-) -- Please, do not forward replies to my e-mail. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2020-08-10 21:00 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-08-05 14:00 Verbatim text in headers Anton Shepelev 2020-08-06 20:17 ` Anton Shepelev [not found] ` <20200806231710.dd08c7f61a90ea23c708d507-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2020-08-06 20:38 ` Leonard Rosenthol 2020-08-06 20:57 ` Anton Shepelev [not found] ` <20200806235733.6c944e913ef52f26b00c2f09-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2020-08-06 21:04 ` Dmitriy Krasilnikov 2020-08-06 21:17 ` Leonard Rosenthol 2020-08-06 21:38 ` Anton Shepelev 2020-08-07 9:09 ` BPJ [not found] ` <14a2d64c-3044-5d89-0412-fc06c7f40a7c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2020-08-07 9:35 ` Benct Philip Jonsson [not found] ` <389fb88b-aadf-9cfc-3061-9c2dde74bccd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2020-08-07 9:38 ` Benct Philip Jonsson 2020-08-08 12:18 ` Anton Shepelev [not found] ` <20200808151809.d2878d07de78b0b3f6606673-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2020-08-08 15:33 ` BPJ 2020-08-08 17:16 ` John MacFarlane [not found] ` <m2sgcxjbxo.fsf-pgq/RBwaQ+zq8tPRBa0AtqxOck334EZe@public.gmane.org> 2020-08-09 8:22 ` BPJ 2020-08-10 21:00 ` Anton Shepelev
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).