On Wed Jul 6 15:33:19 2005, [EMAIL PROTECTED] wrote:
> I'm getting escape characters in my -man output -- the 0m
> stuff. I googled and it isn't just me:
>
> http://lists.gnu.org/archive/html/bug-groff/2003-03/msg0.html
>
> http://lists.gnu.org/archive/html/bug-groff/2002-08/msg00092.html
>
Thanks, Jorgen, I had missed this -- I'm not technical enough
to recognize that these *m strings were SGR. However, I just
tried adding -c and -C to my groff line and I still have the
same thing. Here's my command line:
groff -mandoc -stC -Tlatin1 tmsplx.xml.5 | col -b > catman/tmsplx.xml.5
Apo
> > b) Recognize the encoding according to a note in the first line
> > '\" -*- coding: EUC-JP -*-
> > groff will then emit errors when it is fed input that is
> > non-ASCII and without coding: marker, so that man page
> > maintainers are notified that they need to add the
> >>> This looks like it would conflict with Emacs usage.
> >>
> >> Where is the conflict? This is precisely the syntax for declaring
> >> an encoding to Emacs, and by now Emacs also recognizes standard
> >> encoding names like "GB2312" and "UTF-8".
> >
> > It's also the method to describe a minor
> Thanks, then let's go for the proposed
>.\" t -*- coding: EUC-JP -*-
What's the `t'? BTW, attached is the file gpreconv which has been
written five years ago by a guy whose name I no longer know (sigh --
since then I'm thinking about UTF8 support without actually starting
with the impleme
> Since man has to look at the man page, decide whether a decompressor
> is needed, decide whether tbl and/or eqn must be invoked, etc, it
> seems that inserting an invocation of iconv after the decompressor
> and before tbl is also an appropriate job for man. It seems
> un-Unix-like to build know
On Thu Jul 7 01:34:04 2005, [EMAIL PROTECTED] wrote:
> Thanks, Jorgen, I had missed this -- I'm not technical enough
> to recognize that these *m strings were SGR.
Me neither. I know them under the (probably vaguely incorrect) name "ANSI
escape sequences".
> However, I just
> tried adding -c and
> BTW, attached is the file gpreconv [...]
Since it possible that some mailers don't accept attachments, I resend
it here, directly embedded in the email.
Werner
==
#define I18N
#include
#include
#include
#include
Andries Brouwer wrote:
> One wants something like (1) a system-wide default, (2) a user locale
> that can override (1), (3) coding reported in the file itself, probably
> overriding (2).
Yes, this is the idea. And since a user locale setting always exists,
(1) is never used. (In the worst case the
> .Character-Encoding EUC-JP
>
> This would incidentally also allow changing the character set in
> mid-stream, at least syntactically. I suspect there may be reasons
> that make it impractical.
Yes: there's no editor which can reasonably display a file in mixed
encodings. For another example,
You probably shuddered and laughed when you saw the hacks contained in
groff-utf8.tar.gz, but it shows which areas need work before groff can
handle man pages in Japanese and Vietnamese by default.
1) Recognition of the input file encoding.
2) The font system and the utf8/html devices.
3) Re
Werner LEMBERG wrote:
> > Thanks, then let's go for the proposed
> >.\" t -*- coding: EUC-JP -*-
>
> What's the `t'?
It's an example to demonstrate that a tag denoting 'tbl' preprocessing
is not incompatible with the "coding:" tag.
> BTW, attached is the file gpreconv which has been
> writte
srintuar wrote:
> Just fyi, under fedora core 3 with a nearly stock install,
> both of those files show up just fine in gnome terminal with
> the system "man".
Thanks for this info. Indeed, in Fedora core 3/4, they
- replaced the "nroff" command with one that understands a
--legacy CHARSET
> The obvious king's path for this is to use GNOME's pango.
Obvious? Some of us aren't using Linux, let alone GNOME.
> What else is needed to support Unicode on the input side?
My suggestion would be to start by picking one of the several UTF-8
preprocessors that have floated across the list
On Thu, Jul 07, 2005 at 10:43:40AM +0200, Jörgen Grahn wrote:
> The -c option mentioned is an option to grotty, so you have to "tunnel" it
> through groff's -P option. This works for me (with groff 1.19):
>
>groff -P-c -Tlatin1 -man [...]
>
> (To confuse things a bit, groff has a -c option wh
On Wed, Jul 06, 2005 at 01:50:31PM +0200, Bruno Haible wrote:
> Thanks, then let's go for the proposed
>.\" t -*- coding: EUC-JP -*-
> syntax.
or a Vim syntax, replacing vim (vi, ex) with groff.
.\" groff:option1:option2=value:option3
Notice that in vim syntax : can be replaced with
On Wed, Jul 06, 2005 at 03:36:07PM +0200, Andries Brouwer wrote:
> I am not really aware of use of groff other than as a backend to man.
Now, you are a little upset with Bruno's response, so you are sending a
little jab. Nice. Some people never heard of TeX either and they think
Word (or OpenOff
Over a million men have been helped with the potent ingredients in Pen is Growth Patch men have experienced bigger size, more action, and super-satisfying results for themselves and their partners.
Don't be left behind! Take advantage of price specials going on now.
Click here!
___
On Thu, Jul 07, 2005 at 11:04:24AM +0200, Werner LEMBERG wrote:
> The tag in the header makes groff call a
> preprocessor which inserts a proper encoding filter.
Which means that man should not call iconv when output is to groff,
while it should call iconv when output goes elsewhere.
Ugly.
Andr
On Thu, Jul 07, 2005 at 01:12:33PM -0400, Zvezdan Petkovic wrote:
> On Wed, Jul 06, 2005 at 03:36:07PM +0200, Andries Brouwer wrote:
> > I am not really aware of use of groff other than as a backend to man.
>
> Now, you are a little upset with Bruno's response, so you are sending a
> little jab.
On Thu, Jul 07, 2005 at 11:54:40AM +0200, Werner LEMBERG wrote:
> >.\" t -*- coding: EUC-JP -*-
>
> What's the `t'?
I muttered that there already are various conventions for
stuff that has to be on the first line. One of them is the
old convention that if the first line has '\" t or '\" e
o
> > What else is needed to support Unicode on the input side?
>
> My suggestion would be to start by picking one of the several UTF-8
> preprocessors that have floated across the list lately, and include
> it in groff. Perhaps it's a little late to do for 1.19.2, but the
> next update could incl
> > Thanks, then let's go for the proposed
> >.\" t -*- coding: EUC-JP -*-
> > syntax.
>
> or a Vim syntax, replacing vim (vi, ex) with groff.
Sorry, I'm rather an emacsist than a vimist :-)
> Also, vim syntax is allowed to be in the first N lines of the file,
> or the last N lines of the
On Thu Jul 7 13:36:36 2005, [EMAIL PROTECTED] wrote:
> 1) Currently on a Linux system you find man pages in the following encodings:
...
>and none of them contains an encoding marker.
>
>The agreement was to recognize the encoding according to a note in the
>first line
>'\
Andries Brouwer wrote:
> If there is a pipeline, then earlier
> stages in the pipeline already need the character set.
> So, conversion may have to be done before the input reaches groff.
Yes, and that's why groff is designed as a set of filters. If you need
one of the filters early on, just call
> - remove the "charset" section of the font files for utf8 and html,
> - split the "font" C++ class into a class hierarchy
> class font; // abstract
> class concrete_font: font;// useful for other devices,
> // with "charset" section
> class algor
> > The tag in the header makes groff call a
> > preprocessor which inserts a proper encoding filter.
>
> Which means that man should not call iconv when output is to groff,
> while it should call iconv when output goes elsewhere.
??? Nothing prevents man of calling iconv by itself to produce U
> Recently I have used TeX to write Amharic, Cyrillic, Arabic, Hebrew.
> It works, but some effort is required. Are such things possible in
> groff today?
With a preprocessor which converts Amharic input data into \N'...',
this should be possible. Cyrillic should work quite nicely, but
neither
Zvezdan Petkovic wrote:
>
> On Wed, Jul 06, 2005 at 03:36:07PM +0200, Andries Brouwer wrote:
> > I am not really aware of use of groff other than as a backend to man.
...
> However, to make you aware of some uses of groff, other than man pages,
...
> And we are talking about serious publishe
29 matches
Mail list logo
