From: Anton Shepelev <anton.txt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Subject: Verbatim text in headers
Date: Wed, 5 Aug 2020 17:00:53 +0300 [thread overview]
Message-ID: <20200805170053.048fb8de00100ff64b866bd6@gmail.com> (raw)
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.
next reply other threads:[~2020-08-05 14:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-05 14:00 Anton Shepelev [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200805170053.048fb8de00100ff64b866bd6@gmail.com \
--to=anton.txt-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).