Hello,
I looked at the libc manual and the @deftype* formatting indeed looks
wrong. The function type is in upright @code, which looks good,
but types within the function call are in slanted roman, and
metasyntactic variables are in slanted typewriter. It seems very
strange. I am actually very surprised that nobody complained. Also,
it is somewhat strange that after the change in 2003, similar change was
not followed up on the argument.
Upright parenthese and brackets tend to look better, though. To me it
would be more logical to use typewriter upright parenthese and brackets,
but we could keep roman upright parenthese and brackets for backward
compatibility.
My current proposal would be
* @var is not in typewriter anymore, even if in code context (@code,
@example, @def* line). If people really want slanted typewriter,
they should use @code{@slanted{}} or to be sure not to be affected
by the current font style: @r{@code{@slanted{}}}
* @def* argument semantics is different for @deftype* and other @def*
@deftype* argument is code. Not slanted, but typewritter. @var should
be used which will lead to upper case in Info, unless something else is
used, like @Var{} in the groff manual, which uses @r{@slanted{...}}
(though it would be better in my opinion, to use @inline conditionnals
to use @var except for Info).
other @def* argument is code and metasyntactic variables in term of
semantics, slanted, but not upper cased in Info. Users can use
@var explicitely, in that case, in Info the the argument will be upper
cased.
* in @def* arguments, parentheses/brackets are upright in the default case.
For the font there are two possibilities (Gavin?)
- typewritter. More logical. Not backward compatible (though it is not
typewritter currently probably by chance, because of implementation
details)
- roman. Backward compatible but less logical.
The parentheses font should only matter for manuals such as groff
where parentheses/brackes as meta syntactic delimiter and as language
delimiters are distinguished.
--
Pat
