tech@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Guy Harris <guy@alum.mit.edu>
To: tech@mdocml.bsd.lv
Cc: jmc@openbsd.org
Subject: Re: mdoc(7): improve description of .Em and .Sy
Date: Wed, 13 Aug 2014 15:54:55 -0700	[thread overview]
Message-ID: <688F0B4B-25B9-4C50-8746-55AB04734189@alum.mit.edu> (raw)
In-Reply-To: <20140813212212.GG26534@iris.usta.de>


On Aug 13, 2014, at 2:22 PM, Ingo Schwarze <schwarze@usta.de> wrote:

> The central question is whether these macros should be considered
> as semantic or as physical markup.  While the historic documents
> may slightly, if inconsistently, favour the semantic standpoint,
> in our MACRO OVERVIEW i called them "physical", and i'd like to
> stick with that, for the following reason:  Even if we call them
> semantic, we have to define such a broad range of semantic
> meanings that translation into any other modern semantic markup
> language, in particular HTML, becomes impossible.  In particular,
> sometimes .Em would have to become <em>, sometimes <i>, .Sy
> sometimes <strong> and sometimes <b>, but there is no way to
> automatically decide which is the right one when finding one of
> these macros in a manual page, so we would have to fall back to
> physical markup anyway.  Calling the physical also reflects actual
> usage better and isn't completely inconsistent with historical
> documentation.

Well, there's physical, as in "display this in italic characters", and there's physical, as in "present this in some form that indicates emphasis"; the latter is "physical" in that it explicitly affects presentation but not "physical" in the sense that it explicitly *specifies* presentation (it could be read in an emphatic tone by a browser for vision-impaired users).

Unfortunately, mdoc, unlike HTML, never had "display this in italic characters", and somebody who had a reason to want the text displayed in italic characters for reasons *other* than emphasis had to fall back on .Em, so maybe retroactively redefining .Em to mean "display this in italic characters" is the least bad choice (adding .I to mdoc wouldn't help people who want to write man pages that will work with older versions of mandoc and with the mdoc macros).


--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

  reply	other threads:[~2014-08-13 22:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-13 21:22 Ingo Schwarze
2014-08-13 22:54 ` Guy Harris [this message]
2014-08-14 16:07   ` Ingo Schwarze
     [not found] ` <20140814065720.GB7407@harkle.home.gateway>
2014-08-14 15:13   ` Ingo Schwarze
     [not found]     ` <20140814201627.GD7407@harkle.home.gateway>
2014-08-14 22:05       ` Ingo Schwarze

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=688F0B4B-25B9-4C50-8746-55AB04734189@alum.mit.edu \
    --to=guy@alum.mit.edu \
    --cc=jmc@openbsd.org \
    --cc=tech@mdocml.bsd.lv \
    /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).