bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc


From: Drew Adams
Subject: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc.
Date: Sun, 19 Apr 2009 12:33:48 -0700

> >> > 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.
> >>
> >> AFAIK, it's just common practice for definitions.  The 
> >> italics is used to emphasize the fact that this term is
> >> used with a specific meaning, which is being explained.
> >
> > Nope.  Not common practice.
> 
> You're simply wrong. Maybe in the texts you read it's not
> common practice. But in the texts I read it is.

Read more. Technical manuals, in particular, since that is the domain in
question.

Yes, some do adopt the same appearance (e.g. italics) for defined terms as for
emphasis (stress). You might argue that there are enough that do this that it
can be called _a_ common practice, but it is by no means _the_ common practice.

Making it clear that a defined term is a defined term (and not just a stressed
word) helps readability and understanding. If in some medium or context there is
no easy way to do that (limited set of fonts, colors, etc.), then a fallback
approach is to reuse some typography (e.g. italics) that also indicates
something else (e.g. emphasis).

If we had only italics available to font-lock, you might argue that it is great
that all font-lock keywords use italics. But we have more faces available, and
we use them to indicate different things. Why? Because it helps readability.

> > And that reasoning (defined term is important, so use
> > emphasis) is an invention.
> 
> Not at all.  A good example would be when you define what a /type/ is.
> Or what an /object/ is, in a programming book.  If you don't emphasize
> correctly, the reader may end up not noticing/understanding 
> exactly what term you're defining because that term already
> has meaning to the reader.

Red herring. Obviously, such terms need to be made to stand out (emphasized). I
stated that from the beginning.

That's precisely my point: They should stand out not only from the surrounding
text, but also from ordinary emphasis (stress). They should stand out
specifically _as defined terms_: if possible, they should have their own
typography.

This is about reusing emphasis (e.g. slant), as intended for stress, to serve
another purpose (definition terms). I did not propose to change this Texinfo
convention; I simply said that it's not ideal.

A common example of emphasis for stress is the `em' tag in HTML, which is
typically rendered using italics (whereas tag `strong' is typically rendered as
bold). Such emphasis is designed to indicate stress, but there is nothing
stopping someone from abusing it to fill double-duty for other purposes. That
doesn't mean that such abuse is a great idea.

Following your logic, in Emacs Info we should _not_ render definition terms and
emphasis (for stress) differently. That is, you would apparently argue to
collapse _xxx_ and "xxx" into a single appearance, since that "is common
practice". That would be unfortunate for Info, and it is not ideal for print
either.

In technical literature there are a number of other thingies that must also
stand out (parameters, syntax description terms, keywords, constants...) - from
both the surrounding text and from each other. Using the same appearance (e.g.
italics or slant) for several of them makes reading with understanding more
difficult. Different context can help disambiguate, but in the same context
confusion can result.

In any case, I already stated that I'm not proposing to change the Texinfo
convention ("so be it"). So your intervention is off the mark. Unless you do
indeed propose to remove the existing distinction in Info between defined terms
("...") and emphasized text (_..._). That would not be good. But you might
retort that it is common practice... I'll stop here.








reply via email to

[Prev in Thread] Current Thread [Next in Thread]