Verbatim text in headers

Verbatim text in headers

[Anton Shepelev]

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.

Re: Verbatim text in headers

[Anton Shepelev]

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.

Re: Verbatim text in headers

[Leonard Rosenthol]

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

Re: Verbatim text in headers

[Anton Shepelev]

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.

Re: Verbatim text in headers

[Dmitriy Krasilnikov]

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

Re: Verbatim text in headers

[Leonard Rosenthol]

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

Re: Verbatim text in headers

[Anton Shepelev]

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.

Re: Verbatim text in headers

[BPJ]

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

Re: Verbatim text in headers

[Benct Philip Jonsson]

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

Re: Verbatim text in headers

[Benct Philip Jonsson]

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

Re: Verbatim text in headers

[Anton Shepelev]

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.

Re: Verbatim text in headers

[BPJ]

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

Re: Verbatim text in headers

[John MacFarlane]

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

Re: Verbatim text in headers

[BPJ]

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

Re: Verbatim text in headers

[Anton Shepelev]

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.