*roff, ASCII & netnews

[Ivan Shmakov]

>>>>> Anton Shepelev <anto...@gmail.com> writes:
>>>>> Ivan Shmakov:

[Cross-posting to news:comp.text, for there isn't a separate
newsgroup for *roff.]

>>> I have never seen an HTML e‐mail that wouldn’t have become better
>>> by rewriting it in plain text.

>> What’s

BTW, there I had the proper APOSTROPHE (U+0027) character, but
it was changed somehow to RIGHT SINGLE QUOTATION MARK (U+2019),
which is a change in the meaning.

Do I understand it correctly that the formatter's configuration
you use doesn't distinguish between these two?

>> wrong with, e. g., news:86haxbp...@gray.siamics.net or
>> news:86r4wac...@gray.siamics.net?

[…]

>> Would LaTeX code be a preferable form of presentation, I guess we’d
>> see a lot of scientific journals switching to it from the
>> now‐ubiquitous

Also, there HYPHEN-MINUS (U+002D) was replaced by
HYPHEN (U+2019), so I guess that the formatter doesn't
distinguish these two, either. (Note that while in this
particular case this change doesn't affect the meaning, such a
change done for, e. g., a code fragment, would be destructive.)

>> mathematic notation.

[…]

> ‐‐

There, the signature delimiter was changed from the customary
“-- ”, or (U+002D, U+002D, U+0020), to “‐‐” (or U+2010, U+2010),
which, I believe, most of the newsreaders currently in use won't
recognize as such a delimiter.

“-- ” is an element of “news markup language”, after all.
Changing it “‐‐” has roughly the same effect as changing <pre />
to 〈pre /〉 in HTML.

> () ascii ribbon campaign ‐ against html e‐mail
> /\ www.asciiribbon.org ‐ against proprietary attachments

(Ironically, neither U+2010 nor U+2019 is ASCII.)

--
FSF associate member #7257

[Anton Shepelev]

Ivan Shmakov:

> BTW, there I had the proper APOSTROPHE (U+0027)
> character, but it was changed somehow to RIGHT
> SINGLE QUOTATION MARK (U+2019), which is a change
> in the meaning.
>
> Do I understand it correctly that the formatter's
> configuration you use doesn't distinguish between
> these two?

It distinguishes the two symbols, but behaves ac-
cording to groff_char(7), mapping the ASCII apostro-
phe to the right single quote symbol. This can be
changed by commenting the relevant line in
unicode.tmac file in groff's tmac directory:

change: .char ' \[cq]
to: .\".char ' \[cq]

--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

[Anton Shepelev]

Ivan Shmakov:

> BTW, there I had the proper APOSTROPHE (U+0027)
> character, but it was changed somehow to RIGHT
> SINGLE QUOTATION MARK (U+2019), which is a change
> in the meaning.
>
> Do I understand it correctly that the formatter's
> configuration you use doesn't distinguish between
> these two?

Looks like the real true apostrophe is the same
glyph as the right single quotation mark:

http://en.wikipedia.org/wiki/Apostrophe

> Also, there HYPHEN-MINUS (U+002D) was replaced by
> HYPHEN (U+2019), so I guess that the formatter
> doesn't distinguish these two, either. (Note that
> while in this particular case this change doesn't
> affect the meaning, such a change done for, e. g.,
> a code fragment, would be destructive.)

The HYPHEN-MINUS character is used to denote, well,
the minus and number intervals, because its width is
equal to that of a digit glyph, while the shorter
HYPHEN is used in running text, as in "self-evi-
dent", but I am writing in ASCII right now, so
you'll see no difference in my post.

In groff, when preparing output for the utf8 device,
the minus is accessed as either \(mi in ASCII
sources or by using this symbol direcly in Unicode
sources; and I didn't take it into account when
switching from ASCII to Unicode.

Anton

[Ivan Shmakov]

>>>>> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>>>>> Ivan Shmakov:

>> BTW, there I had the proper APOSTROPHE (U+0027) character, but it
>> was changed somehow to RIGHT SINGLE QUOTATION MARK (U+2019), which
>> is a change in the meaning.

>> Do I understand it correctly that the formatter's configuration you
>> use doesn't distinguish between these two?

> Looks like the real true apostrophe is the same glyph as the right
> single quotation mark:

> http://en.wikipedia.org/wiki/Apostrophe

Indeed, thanks.

Still, such a change is /not/ safe when done automatically,
especially when quoting code fragments, etc.

--cut: http://unicode.org/Public/UNIDATA/NamesList.txt --
0027 APOSTROPHE
= apostrophe-quote (1.0)
= APL quote
* neutral (vertical) glyph with mixed usage
* 2019 is preferred for apostrophe
* preferred characters in English for paired quotation marks are 2018 & 2019
--cut: http://unicode.org/Public/UNIDATA/NamesList.txt --

>> Also, there HYPHEN-MINUS (U+002D) was replaced by HYPHEN (U+2019),
>> so I guess that the formatter doesn't distinguish these two, either.
>> (Note that while in this particular case this change doesn't affect
>> the meaning, such a change done for, e. g., a code fragment, would
>> be destructive.)

> The HYPHEN-MINUS character is used to denote, well, the minus and
> number intervals, because its width is equal to that of a digit
> glyph, while the shorter HYPHEN

I wonder, how these consideration may apply to the text intended
to be rendered in a monospace font?

> is used in running text, as in "self-evident", but I am writing in

> ASCII right now, so you'll see no difference in my post.

I understand it differently. Namely, HYPHEN-MINUS is used as a
substitute for either HYPHEN or a MINUS SIGN (in math), but
/not/ for an EN DASH, which is typically used for numeric
intervals.

Also, HYPHEN-MINUS is commonly used in programming languages to
mean subtraction, negation, comment (SQL), or otherwise, so it
is /not/ safe to automatically replace it with a HYPHEN (or
MINUS SIGN), either.

--cut: http://unicode.org/Public/UNIDATA/NamesList.txt --
002D HYPHEN-MINUS
= hyphen or minus sign
* used for either hyphen or minus sign
x (hyphen - 2010)
x (non-breaking hyphen - 2011)
x (figure dash - 2012)
x (en dash - 2013)
x (minus sign - 2212)
x (roman uncia sign - 10191)
--cut: http://unicode.org/Public/UNIDATA/NamesList.txt --

> In groff, when preparing output for the utf8 device, the minus is
> accessed as either \(mi in ASCII sources or by using this symbol
> direcly in Unicode sources; and I didn't take it into account when
> switching from ASCII to Unicode.

> --

AIUI, the convention is to use “-- ” (i. e., with a trailing
blank), /not/ “--” (though Gnus seem to accept it either way.)

[Anton Shepelev]

Ivan Shmakov:

> > Looks like the real true apostrophe is the same
> > glyph as the right single quotation mark:
> >
> > http://en.wikipedia.org/wiki/Apostrophe
>
> Indeed, thanks.
>

> Still, such a change is /not/ safe when done auto-

> matically, especially when quoting code fragments,
> etc.
>
> --cut: http://unicode.org/Public/UNIDATA/NamesList.txt --
> 0027 APOSTROPHE
> = apostrophe-quote (1.0)
> = APL quote
> * neutral (vertical) glyph with mixed usage
> * 2019 is preferred for apostrophe
> * preferred characters in English for paired quotation marks are 2018 & 2019
> --cut: http://unicode.org/Public/UNIDATA/NamesList.txt --

Yes, that's why you can have a verbatim ASCII-based
environment for code and a normal one for text.

> > > Also, there HYPHEN-MINUS (U+002D) was replaced

> > > by HYPHEN (U+2019), so I guess that the for-

> > > matter doesn't distinguish these two, either.
> > > (Note that while in this particular case this
> > > change doesn't affect the meaning, such a

> > > change done for, e.g., a code fragment, would

> > > be destructive.)
> >
> > The HYPHEN-MINUS character is used to denote,
> > well, the minus and number intervals, because
> > its width is equal to that of a digit glyph,
> > while the shorter HYPHEN
>
> I wonder, how these consideration may apply to the
> text intended to be rendered in a monospace font?

No matter what the font is, the glyphs can be dif-
ferent. Furhtermore, groff is a universal typeset-
ting engine and it has a general mechanism to manage
characters and their representations, which is inde-
pendent of the output device.

> > is used in running text, as in "self-evident",
> > but I am writing in ASCII right now, so you'll
> > see no difference in my post.
>
> I understand it differently. Namely, HYPHEN-MINUS
> is used as a substitute for either HYPHEN or a
> MINUS SIGN (in math), but /not/ for an EN DASH,
> which is typically used for numeric intervals.
>
> Also, HYPHEN-MINUS is commonly used in programming
> languages to mean subtraction, negation, comment

> (SQL), or otherwise, so it is /not/ safe to auto-

> matically replace it with a HYPHEN (or
> MINUS SIGN), either.
>
> --cut: http://unicode.org/Public/UNIDATA/NamesList.txt --
> 002D HYPHEN-MINUS
> = hyphen or minus sign
> * used for either hyphen or minus sign
> x (hyphen - 2010)
> x (non-breaking hyphen - 2011)
> x (figure dash - 2012)
> x (en dash - 2013)
> x (minus sign - 2212)
> x (roman uncia sign - 10191)
> --cut: http://unicode.org/Public/UNIDATA/NamesList.txt --

In typography, real symbols are preferred to substi-
tutes. When it comes to programming languages, you
are correct. For the sake of convenience they tend
to use as much ASCII and as little non-ASCII as pos-
sible. Same applies to good e-mail and Usenet mes-
sages.

> > --
>
> AIUI, the convention is to use “-- ” (i. e., with
> a trailing blank), /not/ “--” (though Gnus seem to
> accept it either way.)

Thanks for the correction. Applied.

[Ivan Shmakov]

>>>>> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>>>>> Ivan Shmakov:

[Cross-posting to news:comp.text, for there's too much *roff.]

>>> Normal text with correct apostrophes, hyphends and minuses
>>> .(VERBATIM
>>> My code...
>>> .)VERBATIM
>>> Back to normal text.

>> Then, a similar environment should be used for quoting non-code just
>> as well, as it's unlikely that the author of the quote was expecting
>> such a substitution performed on his or her text.

> In e-mail and Usenet -- yes. In typography -- no.

The distinction should be /not/ typography vs. e-mail, but “I do
care to proofread all the quoted text for possible wrong
substitutions” vs. “I don't.”

(Occasionally, I'd replace typewriter-like "double quotes" with
“proper ones” even in e-mail, for instance.)

>>> You can map ASCII [-] to minus if you want, and even make it for
>>> only specific environments.

>> On a second though, there're reasons /not/ to use this feature.

> OK, so in groff you'll say "5\(mi10-year-old".

I'd rather say 5\(en10-year-old for a proper EN DASH (U+2013),
which is /not/ the same as the MINUS SIGN (U+2212.)

[Anton Shepelev]

Ivan Shmakov:

> > In e-mail and Usenet -- yes. In typography -- no.
>
> The distinction should be /not/ typography vs. e-mail, but
> "I do care to proofread all the quoted text for possible
> wrong substitutions" vs. "I don't."
>
> (Occasionally, I'd replace typewriter-like "double quotes"
> with "proper ones" even in e-mail, for instance.)

Not so with me, because in electronic communication I _do_
prefer to use ASCII for everything except the characters of
a foreign language.

> > OK, so in groff you'll say "5\(mi10-year-old".
>
> I'd rather say 5\(en10-year-old for a proper EN DASH
> (U+2013), which is /not/ the same as the MINUS SIGN
> (U+2212.)

Yes!

[Ivan Shmakov]

>>>>> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:

>>>>> Ivan Shmakov:

>>> In e-mail and Usenet -- yes. In typography -- no.

>> The distinction should be /not/ typography vs. e-mail, but "I do
>> care to proofread all the quoted text for possible wrong
>> substitutions" vs. "I don't."

>> (Occasionally, I'd replace typewriter-like "double quotes" with
>> "proper ones" even in e-mail, for instance.)

> Not so with me,

I see. You do it the other way around.

> because in electronic communication I _do_ prefer to use ASCII for
> everything except the characters of a foreign language.

The only problem I see with using full Unicode these days is
that it has a plenty of characters which aren't that easy to
discern from one another, /especially/ when using a fixed-width
font. That's why I'd prefer to spell EN DASH as &ndash; (or
\[en], etc.), and it's also why I think that "ASCII to Unicode"
substitutions are flawed (be it *roff's - to HYPHEN, LaTeX's ---
to EM DASH, or the "smart quotes" feature, as implemented in the
contemporary office productivity suites.)

I make an exception for national language characters that look
similar to the ASCII ones, mainly because they tend to occur in
sequences, but also because one of my preferred fixed-width
fonts, koi8b-8x16, actually has /distinct/ shapes for the
similar looking Latin and Cyrillic glyphs.

However, this whole issue of Unicode characters'
indistinguishability would be solved with the adoption of HTML
for e-mail and netnews. And for me, it's one more reason to
support it.

[...]

[Ivan Shmakov]

>>>>> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:

>>>>> Shmuel (Seymour J.) Metz:

[Cross-posting to news:comp.text, and dropping news:news.misc
from Followup-To:.]

>> Eric Raymond's DocBook into:

>>> In a structural-markup language, you would tell the formatter to
>>> emphasize the word:

>>> All your base <emphasis>are</emphasis> belong to us!

>> No; that's still marking up the text for presentation. With
>> structural markup you tag the text to indicate its semantics, e. g.,
>> ":title.Return of the foo". That might cause emphasis, quoting or
>> something else. It might cause automatic indexing. It might do
>> something else. And it might do different things depending on the
>> context.

> I think you are nitpicking here, because the tag <emphasis> may be
> endowed with any meaning by means of a style sheet. Similarly you
> could have a <title> tag.

There's one more issue with the TeX approach, which is not as
much of structural vs. presentational kind, as it's of code
vs. data one.

Namely, while it's possible to parse DocBook, documents in
TeX-based markup are essentially /unparsable/. For instance,
while it's possible to extract all the section headings from a
DocBook document, it's impossible to do so, in general, for a
LaTeX one, as the LaTeX document in question can introduce its
own commands all along the way. Consider, e. g.:

\let \sec=\section

The same applies to *roff, and it's precisely the reason that
various *roff "viewers" have to either rely on an implementation
of the language (such as GNU Troff), or support only a
particular macro package (as in the case of Emacs' M-x woman.)

On the contrary, the software working with DocBook documents
doesn't have to rely upon, say, the DocBook XSL stylesheets.

[...]

>>> the interface of a macro package corresponds to a structured markup
>>> language

>> Some macro packages are strictly presentational.

> Yes. Structural mark-up is an abstraction from the lower-level
> presentational mark-up. For example, TeX is presentational and LaTeX
> is strutural.

Actually, LaTeX is structural, plain TeX is presentational, and
TeX is the macro processing language in which both of them are
implemented (as are, e. g., ConTeXt and certain GNU Texinfo
"conversions.")

[Anton Shepelev]

Ivan Shmakov:

> [Cross-posting to news:comp.text, and dropping
> news:news.misc from Followup-To:.]

What's the reason to have different Newsgroups and
Followup-To headers? Isn't it logical to reply to the same
groups to which the article was posted?

> There's one more issue with the TeX approach, which is not
> as much of structural vs. presentational kind, as it's of
> code vs. data one.
>
> Namely, while it's possible to parse DocBook, documents in
> TeX-based markup are essentially /unparsable/. For
> instance, while it's possible to extract all the section
> headings from a DocBook document, it's impossible to do
> so, in general, for a LaTeX one, as the LaTeX document in
> question can introduce its own commands all along the way.
> Consider, e. g.:
>
> \let \sec=\section
>
> The same applies to *roff, and it's precisely the reason
> that various *roff "viewers" have to either rely on an
> implementation of the language (such as GNU Troff), or
> support only a particular macro package (as in the case of
> Emacs' M-x woman.)
>
> On the contrary, the software working with DocBook
> documents doesn't have to rely upon, say, the DocBook XSL
> stylesheets.

Yes, because DocBook has a fixed convention for each
structural element, while macro packages invent their own
ones. In this sense, a document written using a macro
package, which is well-designed and properly used, is no
less parseable than DocBook.

> > Yes. Structural mark-up is an abstraction from the
> > lower-level presentational mark-up. For example, TeX is
> > presentational and LaTeX is strutural.
>
> Actually, LaTeX is structural, plain TeX is
> presentational, and TeX is the macro processing language
> in which both of them are implemented (as are, e. g.,
> ConTeXt and certain GNU Texinfo "conversions.")

That's what I said...

[tlvp]

On Fri, 4 May 2012 18:52:26 +0400, Anton Shepelev wrote:

> Ivan Shmakov:
>
>> [Cross-posting to news:comp.text, and dropping
>> news:news.misc from Followup-To:.]
>
> What's the reason to have different Newsgroups and
> Followup-To headers? Isn't it logical to reply to the same
> groups to which the article was posted?

Not necessarily. If replying to the Relf, for example, I might well prefer
to set Followup-To: dev/null :-) .

Cheers, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.

[Ivan Shmakov]

>>>>> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:

>>>>> Ivan Shmakov:

>> [Cross-posting to news:comp.text, and dropping
>> news:news.misc from Followup-To:.]

> What's the reason to have different Newsgroups and Followup-To
> headers? Isn't it logical to reply to the same groups to which the
> article was posted?

When the discussion has drift away sufficiently from the
original topic, it may be necessary to direct it into a
different newsgroup, or a set of them. Then, it's customary to
post the followup preserving Newsgroups:, while also setting
Followup-To: (and announcing so), so that the next followup will
be directed to the now-appropriate newsgroups.

For instance, this very question doesn't belong to
news:comp.text, so I've dropped it from Followup-To: (and hereby
announcing so.) Thus, the next followup to this thread is
likely to be posted to news:news.software.readers only.

The reason for preserving Newsgroups: is that NNTP doesn't allow
one to follow a /thread/ (or a /person/, BTW), so it's necessary
to warn the readers of the thread of the pending Newsgroups:
change, to give them chance to adjust their subscriptions.

[...]

[Ivan Shmakov]

>>>>> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:

[Cross-posting to news:comp.text and dropping news:news.misc and
news:news.software.readers from Followup-To:, for the question
has little or no relation to the netnews technology whatsover.]

[...]

> When quoting code in paper-oriented documents, I use an environment
> without these mappings, like:

> Normal text with correct apostrophes, hyphends and minuses
> .(VERBATIM
> My code...
> .)VERBATIM
> Back to normal text.

What macro package defines this one, BTW? All that I've found
so far are the -mm's (as bundled with GNU Troff 1.20.1) .VERBON
and .VERBOFF macros.

PS. Is there a macro similar to LaTeX's \today for GNU Troff? Or,
actually, I'd be more interested in an ISO 8601-based version,
akin to the following \todayiso one for LaTeX.

\newcommand \twodigits [1] {%
\ifnum #1<10 0\fi
\number #1}

\newcommand \todayiso {%
\number \year-\twodigits \month-\twodigits \day}

[Ivan Shmakov]

>>>>> Shmuel (Seymour J ) Metz <spam...@library.lspace.org.invalid> writes:

>>>>> Anton Shepelev <anton.txt@g{oogle}mail.com> said:

[Cross-posting to news:comp.text and dropping news:news.misc

from Followup-To:.]

>> Eric Raymond's DocBook Demystification HOWTO:

>>> In a structural-markup language, you would tell the formatter to
>>> emphasize the word:

>>> All your base <emphasis>are</emphasis> belong to us!

> No; that's still marking up the text for presentation.

Yes, somewhat.

--cut: http://docbook.org/tdg5/en/html/emphasis.html --
An emphasis is often used wherever its typographic presentation is
desired, even when other markup might theoretically be more
appropriate.
--cut: http://docbook.org/tdg5/en/html/emphasis.html --

I tend to think of <emphasis /> also as of a "I know that this
fragment of text stands out semantically, but I can't find a
suitable element for it right now" element.

[...]

>> In a structural-markup language, the physical appearance of the
>> final document would be controlled by a stylesheet.

> That's one posibility; there are others.

For instance?

>> -- the interface of a macro package corresponds to a structured

>> markup language

> Some macro packages are strictly presentational.

E. g., most of the LaTeX packages that provide additional
glyphs.

[Shmuel Metz]

In <20120504185226.4661bf55efa6a27e41dc7c48@g{oogle}mail.com>, on
05/04/2012

at 06:52 PM, Anton Shepelev <anton.txt@g{oogle}mail.com> said:

>What's the reason to have different Newsgroups and
>Followup-To headers? Isn't it logical to reply to the same groups
>to which the article was posted?

No; it's logical to reply to the relevant groups. Followup-To is
appropriate if the original article was posted to an inappropriate
news group or if there has been topic drift affecting what groups are
relevant.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Adam H. Kerman]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
>on 05/04/2012 at 06:52 PM, Anton Shepelev <anton.txt@g{oogle}mail.com> said:

>>What's the reason to have different Newsgroups and
>>Followup-To headers? Isn't it logical to reply to the same groups
>>to which the article was posted?

>No; it's logical to reply to the relevant groups. Followup-To is
>appropriate if the original article was posted to an inappropriate
>news group or if there has been topic drift affecting what groups are
>relevant.

So you're saying that the author who sets Followup-To is himself posting
an off-topic article in at least one of the groups in the crosspost. Do
we have a word for "Do as I say, not Do as I do"?

[tlvp]

On Sun, 6 May 2012 04:05:31 +0000 (UTC), Adam H. Kerman wrote:

> So you're saying that the author who sets Followup-To is himself posting
> an off-topic article in at least one of the groups in the crosspost. Do
> we have a word for "Do as I say, not Do as I do"?

Umm ... "elected official"? "moralist"? "evange..."?

[Shmuel Metz]

In <jo4taa$td2$1...@news.albasani.net>, on 05/06/2012

at 04:05 AM, "Adam H. Kerman" <a...@chinet.com> said:

>So you're saying that the author who sets Followup-To is himself
>posting an off-topic article in at least one of the groups in the
>crosspost.

One of the difficult tasks in programming is to handle boundary cases
properly.

>Do we have a word for "Do as I say, not Do as I do"?

Probably, but it doesn't apply here. See above.

[Anton Shepelev]

Ivan Shmakov:

> > Normal text with correct apostrophes, hyphends and
> > minuses
> >
> > .(VERBATIM
> > My code...
> > .)VERBATIM
> >
> > Back to normal text.
>
> What macro package defines this one, BTW? All that I've
> found so far are the -mm's (as bundled with GNU Troff
> 1.20.1) .VERBON and .VERBOFF macros.

That was out of my head, but I think that -mom has a similar
macro. Verbatim environments in groff are easy: just
disable filling (.nf) and undo undesireble character
mapping.

> Is there a macro similar to LaTeX's oday for GNU Troff?

> Or, actually, I'd be more interested in an ISO 8601-based

> version, akin to the following odayiso one for LaTeX.

Groff has:

\n[dy] Day of the month (1-31)

\n[mo] Current month (1-12).

\n[year] The current year.

[Troll?_Troll]

Anton Shepelev:
> Ivan Shmakov:

>
>> What macro package defines this one, BTW? All that I've
>> found so far are the -mm's (as bundled with GNU Troff
>> 1.20.1) .VERBON and .VERBOFF macros.
>
> That was out of my head, but I think that -mom has a similar
> macro.

Yeah, your -mom has a macro. A macro butt. 'Cause she's fat, gedit?

Couldn't resist, if someone's looking for me I be waiting under
me bridge.