Bug#311450: 'man mailto' typos: "comand", "diaplsyed", "impossble", "knowledgable", etc.
Package: metamail
Version: 2.7-47
Severity: minor
Tags: patch
Found some typos in '/usr/share/man/man1/mailto.1.gz', see attached '.diff'.
Hope this helps...
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.11-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Versions of packages metamail depends on:
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libncurses5 5.4-4 Shared libraries for terminal hand
-- no debconf information
--- - 2005-06-01 01:17:50.577636000 -0400
+++ /tmp/mailto1.gz.14204 2005-06-01 01:17:50.000000000 -0400
@@ -1,6 +1,6 @@
.TH MAILTO 1 "Release 1" "Bellcore Prototype"
.SH NAME
-mailto - Simple mutlimedia mail sending program
+mailto - Simple multimedia mail sending program
.SH SYNOPSIS
.ta 8n
\fBmailto\fP [-a] [-c] [-s] [recipient name(s)]
@@ -74,9 +74,9 @@
Basically, mailto can include the following things in mail:
-1. Simple formatted text, using the MIME type "text/richtext". This allows you to add emphasis to your message using underlining, bold text, italic (diaplsyed as reverse video), centering, and the like.
+1. Simple formatted text, using the MIME type "text/richtext". This allows you to add emphasis to your message using underlining, bold text, italic (displayed as reverse video), centering, and the like.
-2. Non-text data. Metamail can include pictures, sounds, and other non-textual data in the middle of any mail message. The mailcap configuration mechanism can even make this process reasonably user-friendly, but a knowledgable user can include non-textual data even in the absence of a proper mailcap entry.
+2. Non-text data. Metamail can include pictures, sounds, and other non-textual data in the middle of any mail message. The mailcap configuration mechanism can even make this process reasonably user-friendly, but a knowledgeable user can include non-textual data even in the absence of a proper mailcap entry.
3. Text including non-ASCII characters, such as Hebrew or Russian. Currently, mailto directly supports only the ISO-8859-* family of character sets, which means that it does not meet the needs of Asian users, in particular. However, languages that can not be expressed in the ISO-8859 family can still be included in the same way non-text data can be included.
@@ -275,7 +275,7 @@
.I
Altered editing behavior:
-The ~e and ~v commands, which are used to edit the message being composed, will behave differently in mailto if the mail includes non-text portions. In such cases, each part will be edited separately, in sequence, which makes it impossble for the user to accidentally mess up the inter-part boundaries. Moreover, if the mailcap entry for a given data type includes an "edit" field, the user will be given the choice of editing with the program named there or editing with his usual (text) editor. In most cases, this will be a choice between using a structured editor or editing the raw data stream.
+The ~e and ~v commands, which are used to edit the message being composed, will behave differently in mailto if the mail includes non-text portions. In such cases, each part will be edited separately, in sequence, which makes it impossible for the user to accidentally mess up the inter-part boundaries. Moreover, if the mailcap entry for a given data type includes an "edit" field, the user will be given the choice of editing with the program named there or editing with his usual (text) editor. In most cases, this will be a choice between using a structured editor or editing the raw data stream.
.I
Altered behavior for large messages:
@@ -283,7 +283,7 @@
.I
New -r command-line option
-The -r comand-line option is not found in standard Berkeley mail.
+The -r command line option is not found in standard Berkeley mail.
.SH SUMMARY OF OPTIONS
-a <charset> -- specifies an alternate character set in use. This had better be the one your terminal is actually using. Currently it must be in the iso-8859 character set family.
Reply to: