GNU bug report logs - #3035
23.0.92; doc, terminology for graphics, display, terminal, etc.

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: <3035 <at> debbugs.gnu.org>
Subject: bug#3035: 23.0.92;	doc, terminology for graphics, display, terminal, etc.
Date: Sat, 18 Apr 2009 14:18:04 -0700

> > > I don't think it's a good idea to show bold in Info when 
> > > it comes out as slanted in print.  And making this change
> > > in the printed output as well would be unwise, IMO, as
> > > this is a very old and well-known convention of Texinfo.
> > 
> > I see. But you said the same thing about emphasis (_foo_). 
> > If both "some quotation" and _something emphasized_ appear
> > as slanted text in print, then how
> > does a reader distinguish these uses?
> 
> I think the reader cannot distinguish, indeed, by the typeface alone.
> But @emph is really very rarely used, unlike @dfn; and then, there's
> context.  So in practice the problem is not very big one, I think.  At
> least I myself never had problems.

OK.

IMO, using slant for a defined term in print is not too good, and having the
same appearance for defined terms and emphasized text (unrelated) is also not
too good. I'm a bit surprised, frankly, given the fine-grained print
representation of things like keys - by contrast, this seems rather coarse. But
if this is the long-established Texinfo convention, so be it.

Here are some possibilities for defined terms in Info - that is, terms that are
defined in place (whether or not they are also listed in a separate glossary). I
assume that both "..." and _..._ will continue to be slant in print. And I
assume emphasis in Info will continue to be shown using italics.

* italics
* bold
* underlining (not underscore wrappers)
* some other face (e.g. color)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.