[Groff] groff CVS now needs texinfo 4.8
In the CVS I've updated groff.texinfo to use texinfo 4.8 -- unfortunately, it no longer works with older versions (causing an endless loop on my Linux box which finally aborts due to a segfault). Werner ___ Groff mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/groff
[Groff] afmtodit updated
Michail has provided updates for afmtodit for better Unicode support (which I've complemented with syntax updates to use Perl 5 features). Please test! Werner PS: It took a long time to apply his changes because of postal delays with his assignment papers. ___ Groff mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] groff CVS now needs texinfo 4.8
> > In the CVS I've updated groff.texinfo to use texinfo 4.8 -- > > unfortunately, it no longer works with older versions (causing an > > endless loop on my Linux box which finally aborts due to a > > segfault). > > This is bad news, for those of us building groff on MS-Windows :-( Well, it is bad news only for CVS users on MS-Windows. A release already contains the info files (which can be displayed with info 4.6). > I guess the interim work around, until Kees ports texinfo 4.8, will > be to build first on my Linux box, and copy the generated info files > to my Win32 build host, before invoking 'make'; for me, this will be > a minor inconvenience, but it won't help users who don't have access > to a Linux box. I've uploaded groff.info.tar.bz2 and the current groff.pdf to groff.ffii.org/groff/devel Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] groff CVS now needs texinfo 4.8
> In fact, even Groff hasn't applied patches submitted almost a year > ago; see > http://lists.gnu.org/archive/html/groff/2004-05/msg00206.html Oops! I see this the first time, sorry. Will have a look soon. In general, if you don't get an answer from me please resubmit the mail. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] groff CVS now needs texinfo 4.8
> In fact, even Groff hasn't applied patches submitted almost a year > ago; see > > http://lists.gnu.org/archive/html/groff/2004-05/msg00206.html Kees, your patch looks fine. To include it, I need papers from you (a request has been sent separately). BTW, have you ever had a look at `progreloc.c' in the gnulib CVS (on Savannah)? I wonder whether it makes sense to use this `canonical' source code instead... Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] grohtml vertical space patch and (screwdriver, nail and hammer fix)
> here is a better patch, I broke formatted text with the last > patch, Uh, too late. Please provide a patch w.r.t. to the current CVS. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] groff CVS now needs texinfo 4.8
> As an aside, will info 4.8 be required to to read the info files > generated by makeinfo 4.8? No. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] grohtml vertical space patch and (screwdriver, nail and hammer fix)
> > Uh, too late. Please provide a patch w.r.t. to the current CVS. > > sure, here it is, Applied, thanks. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Re: grohtml vertical space patch and (screwdriver, nail and hammer fix)
> I've fixed this bug and a few others (many vertical space bugs have > been quashed). Right now I'm looking at my test output, pic.html, and I notice the following two problems: . Vertical space is missing right before a figure begins. . Vertical space is missing after a figure ends. Can you fix this? Otherwise the output is nice! Werner PS: Of course, groff_char from the CVS is still not formatted correctly... ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Re: grohtml vertical space patch and (screwdriver, nail and hammer fix)
> yes, basically the groff_char source needs to be altered to use .ta > rather than horizontal motion escapes. This isn't optimal. I trust you if you say that horizontal motion escapes can't be handled properly in grohtml. What I want instead is to add a special HTML position tag so that grohtml can do a good job. In case this can't be done with the current tags, we should invent a new one. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Proposed equation processor additions
> Has anyone tried the EQN processor additions that I submitted 3 > weeks ago, and have any experimenters uncovered any problems? > Assuming no problems, will the code be incorprated into EQN in the > near future? It looks very promising! Before integration I need your papers (request sent separately). Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Proposed equation processor additions
> Has anyone tried the EQN processor additions that I submitted 3
> weeks ago, and have any experimenters uncovered any problems?
I've now carefully read your sample_data document, without trying the
examples yet. A minor thing which slightly disturbs me is that I
always have to use a formatting argument as the first element of
rmatrix. What do you think of using an optional `col' keyword for
that purpose? Originally, `col' is equal to `ccol', but this fact
isn't properly described in the original eqn documentation, so it
might be a good candidate for `abusing' it.
rmatrix "{"
[ col "{" column_specification "}" ]
"{" row1 "}"
"{" row2 "}"
...
"}"
Thus,
rmatrix {
{ a b }
{ c d }
}
would be equal to
rmatrix {
col { l l }
{ a b }
{ c d }
}
I could also imagine to make the proposed `col' keyword accept a
string of column formatters instead, similar to tbl:
col "ll"
This avoids the introduction of the new keywords `c', `l', and `r'.
BTW, could you integrate the rmatrix stuff directly into eqn.y? How
much work is it?
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
[Groff] undocumented GNU eqn features
While studying eqn.y I've just discovered some features of GNU eqn which
appear to be undocumented in eqn.man.
. `undef' undefines a macro.
. `copy' is a synonym for `include'.
. `Alpha', `Beta', etc., is the same as `ALPHA', `BETA', etc.
. GNU eqn has two more predefined operators: `ldots' (three dots on
the base line) and `dollar'.
. The keyword `space' sets the vertical spacing (in hundredths of em),
normally before and after an equation. It provides an interface to
groff's \x escape but with opposite sign: positive values change the
space before the equation line, negative values change the space
after the equation line.
.EQ
space 50
a = b + c
space -300
.EN
. The keywords `lcol' and friends can be immediately followed by a
number which gives increases the vertical spacing of rows in
hundredths of ems:
.EQ
matrix {
ccol 100 { a above b above c }
ccol { d above e above f }
}
.EN
Since this vertical spacing is realized with \x also, it interferes
with the `space' command described above.
. The same is true for `lpile' and friends.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
[Groff] Re: undocumented GNU eqn features
> . The keyword `space' sets the vertical spacing (in hundredths of > em), normally before and after an equation. I forgot to mention two things: . `space' is ignored if an equation is used within a picture processed by pic. . `space' replaces the default values for the top and bottom space of an equation. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Re: grohtml vertical space patch and (screwdriver, nail and hammer fix)
> We could introduce a new tag (variant on .col tag, say .coln), which
> indicates that this position is has been generated via a \h
> motion. post-grohtml could check for sequences of `.coln' tags
> between `.sp' tags, record their positions and see whether they line
> up vertically (or at least don't overlap with their successive
> glyph). It could then replace `.coln' with `.col 1', `.col 2' as
> appropriate and then let the current table handling code do the
> rest.
I did some experiments and I now believe that DEVTAG-COL should be
sufficient. Sorry for the false alarm. On the other hand, I have
difficulties to make it work properly. Please have a look at the
attached file. Can you explain to me why the first invocation of the
`.He' macro (which finally calls DEVTAG-COL) produces such a bad
result, while the second call gives the expected result (not counting
the wrong indentation)? Either I'm doing something wrong, or the
explanation of the `.col n' tag in grohtml_tags.man (which I haven't
integrated yet into grohtml.man) is wrong, or there is a bug...
Werner
==
begin 644 groff_char.n.bz2
M0EIH.3%!62936>]R_X([EMAIL PROTECTED]@0?___8#:>>P^=X9OOOGWV
[EMAIL PROTECTED](5"+;4>M$H5[Q[WI3>WVLWSN7;ZY]][AOOO=[PN]QZH'14^J"\CR:HUO=O>KJHG7E\T>7WLGKZ%V-]D-LD3T=6]O5;
MO>N^[GUZKJ]:5ZI7W==MIVSM9CVU5'7OAKV:WVW%;0DJ\^<.6-]V&FB$`0TR
M:`$T9--3:$8C$8HT82GZ:*>TRIXU/1$!IH0`(@AI&@TF*:>U4]A)ZF4WJ:GJ
M:>B!ZF]2,@T``8(HF28)3T](GZIZC:GE/4](#30-`#0`$FE$("`$T%/)
MZ3U0R::GHTTFTF:1D'I&F30TT&[EMAIL PROTECTED]&A-,31)M3RGBFPIB-)H\U-0>IA&3
M(T:9,FC1HTT$B($)H$T!HAI&C*>2:;)JGI/(]3T2>D-#0T#(!H[N/$J"OPK!
M`X^6=?%_;'^.">S%/[EMAIL PROTECTED]"XW\U,C4D;)Y8+C!/_?91\
MLD^IAY>/[_U>/\WY^>Y/X>L/[EMAIL PROTECTED]("[EMAIL PROTECTED]'U4=&+^HG/,5BJ4'
[EMAIL PROTECTED](F`GB06QJ@'[EMAIL PROTECTED]&J2?2+1$,-.(/G3"
M>X6],6"F$,9O).DW#AO_%AFK%>_<#&7)?N6OB_R\M*!C(+?H'B`VY!]A\$N\
MV&N]1$-Q`XA7_7MS<$,3U7%/FUN>MA;0:P4Z/IC?[8VTUD+F&)C!ODUVLDV_
MPO]=*J8/+>,C>A,`6QKL_7`L-'64]EZ>\0[,AAAJ[".7?G2T^;CY+)E0G6A9
M<\`US5`Z(O?"T'7#/&T%QL+.XR5.F5$=91<1PL=FJ'P0%*]%CI8JSNFBF"*+
M-B"DV0*M':\)9MF^V+6WWSK.=#&,8QC&^Q*C0-;62T?QX^R[$:0A$)[EMAIL PROTECTED]>TKI`?9=")9:O"AMAY
ML1<([EMAIL PROTECTED],-%4&%%:*.GOV=U^U9)":[EMAIL
PROTECTED])T]'3I\&X9@&T,4A\J`]Z
M,XMI([EMAIL PROTECTED]N3:-?"K4_MR]E.S4"NL#554I6_LAV]FSLA`P:F:N)X_EO?X:S+.<8M[AG$=2E#5:3UK6M2U>]=8O'-;0S.D
M-\XC`O=[4AC:V=3Q")S&4=/H1=C\1'A\/U=+J->W:]^7WC7OVQ/,O$FO9Y:4
M.'?MZ?N<15(@;:`]HLK]7=TOU\6\"0]YAK+SC2VP[I
M&B["W=!M7VIF=94D(8#&59XL);XKW#_L_6?I_)XE?Z_PF-ML>
MCBU\F&_2E;5"&.4+Y;?1R&L.W]2N-`T*.J)>
M>C/3X:O1T52TB3O1:\84AA#O"AQ'$SCK"A[P%6MA).W"_MH/IB%7PF$XY>CT
M439';@Z=Z?Z)Y`HD(T
M#%_#8,V6*9XRYQ4[^7HD6;J<,L<2KL?_;9S:=MB#+V8Q(.8>_]*7:/;]LPEX,L<;E2[EMAIL PROTECTED]([EMAIL PROTECTED]GYOV`WQE#DN&A$3_)"4Z??>4(K9HP#KZ+Y(D82P_I8?K]/[EMAIL PROTECTED]
MPU:<-!OTLPUWKZ76\X_+:M<).MR^?()2(J0_L?%$[D=#!2*K%O".RE+N?!B5
MGX9G558J9)$B;RD1DG.][#.K,DF!P_W>&`/&[Y894#[8-YR!80='`P:J^PPQ
MJEVYW5O^7YH'X>5S!\?]YK2??3J:UYX6)I\U]\9][M-9FGEU!*+]/RJ)!!LS<(-VIZ.<-#.+`D7SH)9)+JQN7-*./6./
MN^F#Q#(KO\[#(WZ1/";[EMAIL PROTECTED];2]>A[?+B=/A&#\#4-O:*[;9\WL'F7I\
ME%-6MB-BB[<-E3N$Q`ZL+/PO`RLNXP;('N<1&]F#QBQ&78$.(0OYY9<[WP"R
MB6(YXZW6&_Y>(,DI&2Q1QNIE]\?RH'_+UF`"JJ?H.4^4Q8XTK9W!6T!.:TOW
M8PZ'^+H_%NV:&G*)!P>F=A#0KZ<$/[EMAIL PROTECTED];R;OC+J%
MF$`(P2$W2G"[EMAIL PROTECTED]/_E*5*T\82&W'\O7.Q$0Z,%-SL
M0TEJ=8V89=6DH@"/@1(&5?7.4]'/)H^+[_I0?F06*=O92^ONHL0,]C59J^1E
[EMAIL PROTECTED])TB\Z?DQV<%^9>'/([EMAIL PROTECTED]([=/
M/[EMAIL PROTECTED]<$)D-D;)Y=5[>TJ>9GYY"YBE%B1ZWZ8^#QAXP1VT7GR:CVF5ZE8MK
MWKIDVP1Q=&O,'+'(=#.+G>^M/O+J(O21KOK4+T1%EV`L$!T6(VC'HI'MY^#8
M28N.CG%([EMAIL PROTECTED];RY8643!J5G(9[LN$ASEN3B)]#.O].
ML!VI^.O-*(..,3Y*R1P8=%UZ:"`\O*1$716AC$\,PF`$Y3\;F(Y;^*NY)M5`OH/FW7'GR,[EMAIL PROTECTED]@D-"4F%P"JKC
M%*T+'.\AH\6:72-G%LW*Y>?GF6\^+?;9JHJT1JKHQS/XUQTS2ZHI2[5//RME
MB!XN/9T;HW+3;[4?/IHK./*.X*W+?PD?YCMS5YP:%NE091;Y<&[ADN4V8P["
MX,10!74^(.`([EMAIL PROTECTED]@WQ3X+N\27P3*M)OSW+A,./[EMAIL PROTECTED]'[EMAIL
PROTECTED]:9)P%CP\WH>OM3MHE#LJB/JM/SGGV[>[E0/<
MK,H"E[FO"RBPAX,*"BJAA`*7Y#IBYASP.2J5"[#4HCTA90RDB&Q-EC.E*=6;
M:.`L/.N?8LP>%YTXKOG*BRT7>$LB#K:XPLIW>-3]'DL,27S>$,FJ_`]_(V/**N])"@B'T:D=]A]$.X3#T2C3%`/6"(G87
M@(9,E"E*2B4UH8,%'&IO$Y:ZDL(&6,$8&%"AW]6QNH5*D"@9!I`220,G(V)E
M"2#,Y$E1EJEAHVE)**H1\QN+&VI4P0;3!D?89&B9)0P2-,DW?Z?GH8M;8`D#
MK&B+HJJHPAH&"15YUW$?%'!.S;?,Q`.&E5P_<[EMAIL
PROTECTED],7KCR^JE.'EJJJHW"[EMAIL PROTECTED]<'
M?QBJ'7R*QK'-')2H<-&(QEB]:HL%LUCZY_7W0_/W]::!V2U78YJO)L<[IK4,
M(%+X;,K4$<[EMAIL PROTECTED],#>*S^H_.N"TP<]^(8'#$^./BI%'ERC4>
MMEDDZ#'[EMAIL PROTECTED]'C3><+,\G+Q+4N'!XV&:P#E4`0M0(+1L!(]
MJK*>>IFTLQ'NSC>`-,(=O5(SIF&:))&*I%)%&[EMAIL PROTECTED]<[*J_
M#:[EMAIL PROTECTED],(;O"X0-^:&*3C*LCIBR),2"JJ!-J2W/XU=N?S14'
M16@"[EMAIL PROTECTED]"-CZ+QUO-9Q(^V.P?90LA?&O)&BS;1;CKI%FN,8DG!)4%%-BT/:R
M'D$DB([EMAIL PROTECTED]/P(B$(H/[EMAIL PROTECTED])[EMAIL
PROTECTED]@W_$I%/F4"<`OW[]W%"3[>9116)OKR
M+0_UNCYN!WG(@HA7YSNAZ3*^&+=_H2V]&K]1T(%*C7\([EMAIL PROTECTED]>:OH670O'
MZU087ZJ'0E)TM]`
Re: [Groff] DESC question
> thebeast:/usr/src/groff-1.19.1# groff > groff: can't find `DESC' file > groff:fatal error: invalid device `ps' > > The groff on my Debian system is 1.18.1 and the groff I compiled is > 1.19.1. I compiled the new groff statically, could that be a > problem? Is this a bug, or do I need to set up a DESC file? As shown in the `FILES' section in groff_font(5) and the section `groff Font Directory' of groff(1), groff expects for version X.Y.Z that the font files are located in /share/groff/X.Y.Z/font/devname/DESC /share/groff/X.Y.Z/font/devname/F (normally, is /usr/local or /usr). This can be overridden with the -F command line option of groff. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Proposed equation processor additions
> If I understand correctly, you would like the format line to be
> optional,
Yes.
> but if specified to be preceded by the work "col".
Yes.
> As an option, the second format statement above might also be used
> (col "ll").
Mhm, perhaps it is better to use just one the formats. I don't see a
need to have two syntax forms. Perhaps we should do a poll which
syntax form is preferable. Any opinions out there?
I now think that my proposed `col' keyword is redundant. The
following should do just fine:
rmatrix {
"ll"
{ a b }
{ c d }
}
Have a look at the attached diff of eqn.y which is a first try to
implement my syntax.
> > BTW, could you integrate the rmatrix stuff directly into eqn.y?
> > How much work is it?
>
> This might be a LOT more work. I specifically chose to minimize the
> impact of my code on James' work for two reasons:
>
> My C++ is somewhere past novice, but not yet at an
> intermediate stage. So I thought 'tacking' my code on would
> ensure that I didn't muck up his.
My C++ isn't that good either :-) Basically, it shouldn't be that
hard, and I'll assist you if questions arise.
> If you insist, then I'll spend some time on James' code to see how
> it might be done.
Please do so -- and thanks in advance! There is no need to hurry.
BTW, I see a problem with your proposed `#' comment token: It doesn't
work in in-line equations like $x$. We have two possibilities:
1. Disallow `#' in in-line equations.
2. Use, say, `#{' and `#}' to start and end a comment. (Are there
better suggestions for the comment delimiters?)
For item 1 I suggest to handle it directly in function get_token (in
lex.cpp) -- have a look at the similar code in the pic preprocessor
for comparison.
For item 2 (which I prefer) it is very simple to add a rule to eqn.y
since we no longer are limited to a single line.
Werner
==
--- eqn.y 2004-04-08 22:43:23.0 +0200
+++ eqn.y.new 2005-02-22 10:37:21.115271536 +0100
@@ -1,4 +1,5 @@
-/* Copyright (C) 1989, 1990, 1991, 1992, 2004 Free Software Foundation, Inc.
+/* Copyright (C) 1989, 1990, 1991, 1992, 2004, 2005
+ Free Software Foundation, Inc.
Written by James Clark ([EMAIL PROTECTED])
This file is part of groff.
@@ -33,8 +34,10 @@
box *b;
pile_box *pb;
matrix_box *mb;
+ rmatrix_box *rb;
int n;
column *col;
+ row *row;
}
%token OVER
@@ -67,6 +70,7 @@
%token DOWN
%token UP
%token MATRIX
+%token RMATRIX
%token COL
%token LCOL
%token RCOL
@@ -103,7 +107,7 @@
%right LEFT
%left RIGHT
-%right LPILE RPILE CPILE PILE TEXT QUOTED_TEXT MATRIX MARK LINEUP '^' '~' '\t'
'{' SPLIT NOSPLIT
+%right LPILE RPILE CPILE PILE TEXT QUOTED_TEXT MATRIX RMATRIX MARK LINEUP '^'
'~' '\t' '{' SPLIT NOSPLIT
%right FROM TO
%left SQRT OVER SMALLOVER
%right SUB SUP
@@ -117,6 +121,8 @@
%type pile_element_list pile_arg
%type column_list
%type column column_arg column_element_list
+%type row_list
+%type row row_element_list
%%
top:
@@ -214,6 +220,10 @@
{ $2->set_alignment(CENTER_ALIGN); $$ = $2; }
| MATRIX '{' column_list '}'
{ $$ = $3; }
+ | RMATRIX '{' QUOTED_TEXT row_list '}'
+ { $$ = convert_rmatrix($3, $4); }
+ | RMATRIX '{' row_list '}'
+ { $$ = convert_rmatrix(0, $3); }
| LEFT delim equation RIGHT delim
{ $$ = make_delim_box($2, $3, $5); }
| LEFT delim equation
@@ -312,6 +322,25 @@
{ $2->set_alignment(CENTER_ALIGN); $$ = $2; }
;
+row_list:
+ row
+ { $$ = new rmatrix_box($1); }
+ | row_list row
+ { $1->append($2); $$ = $1; }
+ ;
+
+row_element_list:
+ equation
+ { $$ = new row($1); }
+ | row_element_list equation
+ { $1->append($2); $$ = $1; }
+ ;
+
+row:
+ '{' row_element_list '}'
+ { $$ = $2; }
+ ;
+
text: TEXT
{ $$ = $1; }
| QUOTED_TEXT
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] japanese kana fonts
> (1) I googled on groff and japanese. There seems to be a "ja-groff" >or "jgroff" with the proper extensions, but trying to find it >became a kafkaesque adventure. I found diff.gz files at BSD ports >(this is a slackware 10.0), and description files, and then ".tbz" >files which I can't manage. I think that .tbz is the same as .tar.bz2 (using the bunzip2 program for decompression). >There was a ja-groff.[version].tgz at a bsd port, but after some >kilobyte the downloading process was canceled. Tried it several >times. It was a bit strange, chasing after hints and links to >ja-groff and then finding nothing... The default Debian GNU/Linux distribution of groff (version 1.18 or older but *not* 1.19 or newer) comes with support for Japanese, AFAIK. I've never used it, so I can't comment on its quality. You might check debian.org for the source diff file. > (2) Some time ago I made a good experience installing cyrillic >fonts, using the "wncyr" fonts of the latex distribution and >converting them with "tfmtodit". Worked with no problems at all. >So I thought this could be done with kana as well, and there is >the CJK-Latex package. While using Japanese fonts within standard groff is possible, you are lacking the necessary typographical support, namely intercharacter spacing, line break after any Japanese character except some punctuation characters, etc. >Should I learn TeX & friends (Latex, CJK, Omega - ?) properly and > go on in this direction - perhaps with the perspective of porting > the fonts to groff? (Eventually migrating from slackware to debian > or suse for this purpose, because there is a CJK package in the > distribution?) I suggest you get the *latest* TeX Live CD (or download an image which you can then install) which has everything ready to run. In case you like Emacs there is a special cjk-enc.el file which makes writing LaTeX documents with various scripts very simple. Write to me privately in case you need more help with the CJK package. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] ubuntu, groff and utf-8
> Readin info groff I found how to do utf-8 output, but nothing about
> input :(
This is correct, unfortunately. groff doesn't yet support UTF8 input.
You have to convert your file first to something groff can understand.
Below is a small perl script which does that. Note that it doesn't
`fake' glyphs, this is, it doesn't construct, say, `Amacron' from an
`A' and a `macron' glyph. Any volunteer for this?
Werner
==
#! /usr/bin/perl -w
#
# uni2groff.pl
#
# Convert input in UTF8 encoding to something groff 1.19 or greater
# can understand. It simply converts all Unicode values >= U+0080
# to the form \[u].
#
# Usage:
#
# perl uni2groff.pl < infile > outfile
#
# You need perl 5.6 or greater.
use strict;
binmode(STDIN, ":utf8");
while (<>) {
s/(\P{InBasicLatin})/sprintf("\\[u%04X]", ord($1))/eg;
print;
}
# EOF
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] ubuntu, groff and utf-8
> > This is correct, unfortunately. groff doesn't yet support UTF8 > > input. > > But, it's something impossible to implement, or just it isn't > interesting? I want to do this since years, but there are always more important things to do :-( Reason is that I'm involved in more than a single project... Any volunteer to start? It would already be of great help if someone takes src/roff/groff/input.cpp and replaces the relevant `char' and `int' with a new typedef `Char' or something similar to indicate that the variable represents an input character. Later on `Char' can be completely widened to a signed 32bit entity which easily covers the complete Unicode range. Internal character codes (like ESCAPE_AMPERSAND) then simply get negative values. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Re: grohtml vertical space patch and (screwdriver, nail and hammer fix)
> > Right now I'm looking at my test output, pic.html, and I notice the > > following two problems: > > > > . Vertical space is missing right before a figure begins. > > > > . Vertical space is missing after a figure ends. > > > > Can you fix this? Otherwise the output is nice! > > I believe I've fixed these bugs now, here are the patches: Applied, thanks. It's better now, but there is still missing vertical space before and after tables (created as images). Cf. the table at the top of pic-12.html. Werner PS: Have you seen the mail which describes my problems with DEVTAG-COL in the groff_char manpage? ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] status of pdfmark macros
> It's taken a while, but I have now produced a suitable script Great! > I've attached the update as a tarball containing the two new files, > `pdfroff.sh' and `pdfroff.man', together with a patch against the > CVS versions on which my additional modifications are based Only the attachment with the two new files have been sent to the mailing list; the patch file is missing. Please resend. Some comments: > * aclocal.m4: (GROFF_APPRESDIR_OPTION): use AC_HELP_STRING > instead of AS_HELP_STRING. > [...] > * configure.ac: Add AC_PREREQ(2.56), autoconf 2.56 is too old; you need 2.59 to have the `abs_xxx_dir' variables work correctly. As a consequence, I don't have to use AC_HELP_STRING which is now marked as obsolete. I will do those fixes by myself. > (For your possible convenience, I've included the above as ChangeLog > patches, in the overall patch file). Please don't do that in future postings. What you've done in your mail is the right solution and fully sufficient: ChangeLog entries should always be sent separately so that the patch applies cleanly even if there have been other changes meanwhile (which normally produce new entries in the ChangeLog file). Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Re: grohtml vertical space patch and (screwdriver, nail and hammer fix)
> But I've not got the fix yet. Here was my reply (a couple of days > ago, maybe it got lost in a thread?)..: I'm answering emails off-line normally. First I send my written mails, then I receive the next bunch emails. While sending the mail to you, I've received your answer :-) Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] uppercasing
Maybe some of you can use such a macro... Werner == .\" .\" .uppercase in out .\" .\" Convert the contents of string with name `in' to uppercase .\" and return the result in a string with name `out'. .\" .\" Note that this macro by default only translates the characters a-z; .\" if you need other characters, define them in the strings .\" `uppercase-set' and `uppercase-reset'. Both are used with the `.tr' .\" request; the former to set the mapping, the latter to reset it. .\" .de uppercase . tr aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ . tr \\*[uppercase-set] . di uppercase .nop \\*[\\$1] .br . di . asciify uppercase . chop uppercase . tr aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz . tr \\*[uppercase-reset] . ds \\$2 \\*[uppercase]\" .. . .ds uppercase-set ä\[:A] .ds uppercase-reset ä\[:a] . .ds xxx This Is A Täst. .uppercase xxx yyy .tm `\*[yyy]' => `THIS IS A TÄST.' ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] status of pdfmark macros
> The patch file was also included in the tarball, along with the two > new files. Oops! A bug in mc prevented me to see the patch. Very strange. > Consequently, I have modified my patch to set AC_PREREQ(2.59), and > to use AS_HELP_STRING instead of AC_HELP_STRING throughout. Thanks. I've now applied your changes. Please test! Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] status of pdfmark macros
> There are two errors in the ChangeLog entry: Fixed, thanks. > Also, I've noticed two small problems with my coding, fixed by the > attached patch: [...] Applied. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] ubuntu, groff and utf-8
> It seems there is a problem with this script. > If there is an `Amacron' in the data, the script produces `u0100'. > But glyphs in groff are named in decomposed form, > glyph name for `Amacron' is `u0041_0304'. > You can see this from unicode_decomposed hash in afmtodit > and uniglyph.cpp & glyphuni.cpp . > Thus your script has to be made a bit longer by inclusion of > unicode_decomposed hash ;) This is not correct. You actually can name a glyph `\[u0100]' within a groff input file, and groff itself decomposes it to glyph name `u0041_0304'. With other words, a glyph name `u0100' *within a font file* isn't allowed. > And, may be, it is a good idea to replace (optionally, where > possible) unicode glyph names with the (approx. two character) groff > glyph names, the way it is done in input.cpp, using > unicode_to_glyph_list and following precedents from latin?.tmac. > The reason is to make the output more portable and human-readable. I think this is not worth the trouble. Consider a UTF-8 document written in Russian. *All* Russian glyphs would be \[u], and this can't be made more human readable. > PS. Are you sure that mapping in devutf8 fonts (and other places) > `la' and `ra' to 0x27E8(MATHEMATICAL LEFT ANGLE BRACKET) and 0x27E9 > is a good idea? For UTF-8, this is the right solution IMHO. The other choice, U+2329, is problematic due to its canonical equivalence to the CJK left angle bracket, U+3008. It's easy to override this locally. > It do not think many fonts have that Math Symbols, while `la' and > `ra' are often used in roff files in non-math context Really? Can you give an example? Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] ubuntu, groff and utf-8
> .URL from www.tmac uses la and ra > .URL is often used in the groff man pages. Aah, I see. Can you do a survey which characters for la and ra could be used also, this is, what popular UTF8 console fonts actually have? It should be straightforward to add a fallback character with `.fchar' to tty.tmac: .fchar \[la] < .fchar \[ra] > perhaps using something `better' than `<' and `>'. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] The quest for a high-end typesetting system: A few questions
A preliminary remark: Some of the features you are asking for are possible but haven't been implemented in the macro packages. > 1: Regarding color, is it possible to specify color for, say, drop > caps, paragraphs, lines etc, in the CMYK color system? Yes. > 2: Being a non-programmer, font installation in TeX & Children > deterred me ALOT. To install a complete font with small caps, old > style figures, alternate characters etc one needs to write a > fontinst file, comprising a couple of hundred lines of code. Not > good for us mere mortals! I get the impression that this is > considerably more easy in groff? Correct? It depends. Contrary to LaTeX you aren't limited to 256 characters per font. On the other hand, no groff macro package (except `mom', to a certain extent) provides easy means to switch just one of the many font axes (font family, series, shape, etc.) -- this is something for a not-yet-written macro package or macro extension. Using troff's `.tr' request very powerful mappings can be realized; for example, small caps support could look like this, assuming that small caps are in the same font as .de start-smallcap . tr a\[Asmall]b\[Bsmall]... .. . .de end-smallcap . tr aabb... .. .start-smallcap This text is now typeset with small caps. .end-smallcap > 3: Is hanging punctuation (= commas, periods, colons, semicolons, > quotation marks and hyphens protruding slightly into the margin) > possible to achieve in groff? From reading posts in the archive I > get the impression it would be - or is - possible. No, it isn't -- someone had to implement it in groff. AFAIK, only pdftex offers this. > 4: Is it possible to have multiple series of footnotes and margin > notes? This should be possible, I think. Nested diversions are a quite powerful means. No macro package offers this, though. > 5: If it turns out the last line of a paragraph has only one or two > words, is it possible to slightly, slightly tighten the paragraph a > few thousandparts of an em so that the short line moves back to the > preceding line? I.e. "short line elimination". If so, can this be > automated (for long documents)? No, not automated. > 6: Is it possible to typeset on a "grid" in groff? E.g. if there is > a figure at the top of the page, to make sure that the following > main text starts at a multiple of the line spacing used, so that > lines on both sides of the paper line up when you hold up the sheet > against the light? Yes. To say it the other way round: groff doesn't have elastical space. > 7: I see few if any references in the archive to include external > graphics, like TIF, BMP, EPS files etc. Does including alot of > graphics pose a problem? If you stay with EPS there are no problems with many graphics. > 8: I found a discussion about making the linebreaking algorithm > paragraph-based (as in TeX)? Can this be done or has it been done > already? It hasn't been done. The lack of elastic horizontal and vertical space together with missing paragraph formatting are indeed typographical handicaps. > 9: Regarding drop caps, is it possible control the drop cap by > creating a more advanced macro than the examples shown in the > archive? Something like lettrine.sty in LaTeX - i.e. tweaking > vertical size and/or position of the drop cap, defining protruding > of the serifs into the margin, defining space between the drop cap > and the indented lines, sloping the intended lines when the drop cap > is a V or an A, etc.? I think most if not all of those features should be possible if someone sits down and writes appropriate macros for it. > 10: Parallel typesetting on a spread with vertically synchronized > paragraphs, line numbering and separate series of footnotes and > margin notes - possible, not possible? Ted Harding mentioned > something about that a few years ago. It should be possible. > 11: Can one define spot colors, i.e. 100 % solid Pantone PMS colors? > When a PS file is color separated at the service bureau, a spot > color goes on its own printing plate, having its own PMS ink (rather > than being separated to four different plates (C-M-Y-K). Sorry, I don't know exactly what you are talking about. Maybe someone more experienced in this field can answer this. > 12: If the last line on a page has a footnote reference, what > happens in groff? Does the footnote get printed on the next page, or > does the last line move over to the next page, so that the footnote > reference and the footnote get printed at the same page? This is > something many programs have severe problems with. Without actually testing I think that you can write macros so that the last line moves over to the next page. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] ubuntu, groff and utf-8
> > .fchar \[la] < > > .fchar \[ra] > > > Could we do that for \[hy] and \[mi] too? Of course! Which entities do you suggest? Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] ubuntu, groff and utf-8
> > Below is a small perl script which does that. Note that it > > doesn't `fake' glyphs, this is, it doesn't construct, say, > > `Amacron' from an `A' and a `macron' glyph. Any volunteer for > > this? > > It seems the following function is what you are looking for: > > $NFC_string = NFC($string) > returns the Normalization Form C (formed by canonical decomposition > followed by canonical composition). No, this is a misunderstanding. I want a library of artificial characters which combines base characters and accents to composite characters, e.g. .fchar \[u0041_0304] \Z''A .fchar \[-A] \[u0041_0304] Those macros should work for all platforms and -- if possible -- for all typesetting devices. Most device specific startup files already have support for that, e.g., `.ps-achar' or `.dvi-achar'. Using these macros the repertoire should be extended to cover a broad range of Unicode characters. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] The quest for a high-end typesetting system: A fewquestions
> 1: Language, how is that handled? Different languages need different > hyphenation files. A general remark: groff uses a simplified version of TeX's hyphenation algorithm; it can also directly read (simple) TeX pattern files. There is basically no restriction on the number of languages which can be used simultaneously. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] ubuntu, groff and utf-8
> > Below is a small perl script which does that. > > This does not work (Mdk 10.2rc1, groff 1.19 with some mdk patches > but they are unlikely be the cause). Manuals on mdk are in koi8-r, > my locale ru_RU.UTF-8. Actually, it does work. See below. > :3: warning: can't find special character `u041D' > [...] The UTF-8 fonts simply don't contain Russian characters. I've fixed that in the CVS: All Cyrillic characters (from Unicode 4.0) are now in devutf8, including the non-spacing characters. Please test. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] grohtml and Cyrillic
Gaius, I've added Cyrillic entities to grohtml's fonts. To avoid zillions of warnings, special care must be taken to select a proper font which is used during the PS run. The easiest way is to add the following at the beginning of the document: .if '\*[.T]'ps' \ . fam UT Here we assume that `UT' (which I use privately for URW Times) selects a font family which actually has Cyrillic glyphs. Note that the warnings are harmless if you don't have tables or similar things which actually need -Tps for proper rendering. I wonder whether it makes sense to add an option to grohtml so that no PS run is executed. Instead of calling groff with -Tps it should emit warning messages like `warning: table in line XXX won't be converted'. My question: Is this possible at all? Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] ubuntu, groff and utf-8
> > I want a library of artificial > > characters which combines base characters and accents to composite > > characters, [...] > > Such substuitution, if done properly, has to be font-dependent and > resorted to only if the font lacks precomposed characters. Right. This is what the `.fchar' request does, contrary to `.char' which always overwrites the font's definition. > AFAIK, opentype fonts have tables of relative positions of accented > characters and accents, AFM files can have a section describing the > construction of composites. Can groff use that information? No. It shouldn't be too difficult to write a script which transforms such information into proper .fschar commands. Similar to LaTeX, this data could be in a foo.fd file; more sophisticated font loading macros could automatically load such a file if it exists. On the other hand I'm not sure that it is worth the trouble. You are the first one who has ever mentioned this AFM feature on the groff list. > The use of font-specific tables seems to be the modern way to > typeset composite characters. For such font-specific changes you can use the `.fschar' request which defines a glyph for a specific font only. > Managing composites in device-specific (instead of font-specific) > way looks to me like a dead end. On the other hand, there may be no > popular demand for such feature. Well, it is non-trivial to add such support to the Type 1 handler, while we can support that already on the macro level. > BTW, what about creating a new output device, "psunicode", relying > not on the usual postscript fonts, but on the Miscosoft/Monotype > TrueType fonts or some other downloadable (if not redistributable) > fonts with a good coverage of extended latin, cyrillic, math and > technical symbols (i.e. everything groff can typeset)? Why do you want a new output device if you just have to install new fonts? In my local setup I've added the URW fonts (from ghostscript) which have Cyrillic glyphs also -- your afm2dit changes work great! Since those fonts are currently of rather bad quality and are changing frequently I hesitate to add them to the groff package by default. > Abundant precomposed characters already in the font may be a way > around the lack of composition support in groff. (E.g. no need for > artificial Amacron when such glyph is already in the font.) Well, my idea is to have fallback glyph definitions. > One more thought - that artificial Amacron you want to have will not > be recognised as such by ps converters to text or pdf, thus making > the output distorted or less searchable. That's true, but it's not always possible to use a font which has a real Amacron... > And what do you call "all output devices"? I've written `all typesetting devices', this is, where groff controls the actual layout, and where glyphs are used in the output: X, ps, lbp, and dvi. > As to la and ra mapping - as far as I can see, the most popular > console font, Lucida Console, does not have that math angle > brackets. None of the default Mac OS X fonts has them. If la and ra > are not math symbols by design - let them be mapped to the 2039 and > 203A (in the text mode at least). If they are - change .URL to use > fo and fc instead. (It is only my HO, of course.) The very problem of such mappings is that they must be done locally. The -Tutf8 device produces *font independent* output, this is, it outputs characters, not glyphs. groff simply doesn't know which console font is finally used. If you want to change the mappings, they must be put into your local troffrc file. I missed that in my last reply. With other words, I won't change them in the src package (since the mappings are correct), but distributions should provide local changes to be in sync with the used console fonts. > Please, take note of the mail from Andrey Borzenkov. He > demonstrates the incompleteness of devutf font description files > with respect to Russian. This is fixed now for devutf8 and devhtml. Please see my other mail with grohtml problems. > But the same problem arises for that Amacron - "can't find special > character u0041_0304" in both utf and html output devices. Yeah, I'll add support for that also. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] mom: Some follow-up questions
> Like I said, I'm willing to fund some work and maybe Ted H. is the > right guy. I'd like to see a new release of the docs: *roff > reference & user guide, pic/tbl/eqn/etc, macro packages, etc. To have groff documentation in info format has a) historical reasons -- there already was a groff.texinfo file written by Trent Fisher which I gradually extended -- and b) it is the standard document format of GNU. I always try to keep the various groff man pages in sync with groff.texinfo; this means that complete (yet short) documentation is already available in troff format. Anyway, your offer is great, and my favourite choice is to revise Unix Text Processing Book so that it is up to date. Perhaps it makes sense to remove all sections not related to groff and call the new book `UTPG': Unix Text Processing with Groff. Larry K., have you found a new CVS host for the UTP meanwhile? Have you finally announced the UTP on the various lists? Maybe we can find volunteers more easily if more people know of its existence... Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] mom: Some follow-up questions
> Indeed, as Robert points out, texinfo 4.8 is now required; but also, > IIRC, it had been previously been noted that 4.7 should *not* be > used, because of a bug -- before the step up to 4.8, you had to use > 4.6. Your use of 4.7 was always doomed to failure. It has been shown that groff.texinfo is a real torture test for texinfo. Over the last few years I've at least reported 20 bugs to the maintainers -- and I've provided a good deal of patches by myself. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] mom: Some follow-up questions
> > I ran into the same problem, before noticing in the ChangeLog that > > texinfo *4.8* is now required. > > Indeed, as Robert points out, texinfo 4.8 is now required; but also, > IIRC, it had been previously been noted that 4.7 should *not* be > used, because of a bug -- before the step up to 4.8, you had to use > 4.6. Your use of 4.7 was always doomed to failure. Sigh, I've just found out the 4.8 produces bad HTML output because an undocumented feature (which groff.texinfo urgently needs) has disappeared. Saying `make groff.html' within the `doc' subdirectory now postprocesses the output with a small sed script to get the correct result. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Re: post-grohtml core dump
> > This is a test > > .IP X > > Line number 2 > > .LP > > .ce 1 > > Line number 3 > > again, thanks for the report, here is a patch to fix the bug: Applied, thanks. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] bitkeeper vs. CVS vs. subversion
Dear groffers, I ask you to stop arguing for and against your favourite source code revision management system. You've done your recommendations, and it is now up to Larry K. to choose the system which fits his needs best. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] ubuntu, groff and utf-8
> as far as I understand, the situation with character composition > in groff is as follows [...] Thanks for your analysis, to which I agree. > 3) Metrics for some decent PostScript or TrueType fonts are to > be included in groff distribution. I think this will eventually come. The main question is: Which fonts shall we support? How to test? > And, BTW, Carthago delenda est ;) Just for correctness, see http://heimatseeker.com/archive/2004/03/03/ceterum-censeo-carthaginem-esse-delendam/ :-) Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Updated patch: m.tmac
> I've rewritten the m.tmac patch to reflect changes in www.tmac. No > functional changes beyond the previous patch; it simply marks > headings for grohtml and disables headers & footers. Applied, thanks! Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] backspace and Unicode in terminals
I'm going to improve grotty, the TTY backend of groff, so that it can handle zero-width and double-width characters, as needed for proper Unicode support. Doing so I wonder how is the backspace character (U+0008, \b) handled in TTYs? Is there any documentation for it? Most importantly: If I have a wide character at position p which is followed by `\b' (at position p+2), is the final position p again? With other words, is the width of `\b' dependent on the width of the previous character? What happens if I have a sequence of `\b' characters? I'm thinking especially of the interaction at the beginning of a new line. Is there a distinction between a user who presses the `backspace' key, and a `\b' character in the data stream? Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Re: grohtml and Cyrillic
> > I wonder whether it makes sense to add an option to grohtml so > > that no PS run is executed. Instead of calling groff with -Tps it > > should emit warning messages like `warning: table in line XXX > > won't be converted'. My question: Is this possible at all? > > certainly it is possible, but is there a way in which we can add the > code above to ps.tmac and only invoke it when ps4html is set? Or map > the Cyrillic glyphs (in ps.tmac) onto \(sq - similar to mozilla > (when it cannot find the glyph). Doing this we lose complete control whether there are missing glyphs in the PS run. This might be acceptable for on-the-fly viewing (as with a Web browser), but IMHO such behaviour is not tolerable if an HTML document is produced. > If we disable the ps run, then images, equ, pic will also break in > grohtml.. Yes. Instead of running preprocessors, I would like to see warning messages: PS run disabled. Equation in line XXX is not converted to image. A neat side effect would be faster creation of simple HTML documents. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Re: backspace and Unicode in terminals
> You mean the "erase" character, right ? I don't know how it is called correctly. Unicode says that `\b' (as used in the C language) is U+0008 BACKSPACE. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] mom: Some follow-up questions
Sorry for being off-topic: Ralph, do you ever get mails from me sent to you privately? I tried it a few times, and I never got a response, so I now have the feeling that I'm somehow filtered out by your email system. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] groff.html available
I've uploaded groff.html (from the current CVS) as http://groff.ffii.org/groff/devel/groff.html.bz2 Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: backspace and Unicode in terminals
Thanks to all who have answered my questions. I was unclear w.r.t. the backspace character: It isn't needed for positioning (this is done internally in grotty before the output is emitted) but for signalling that a character should be underlined or rendered bold.[1] This isn't directly supported on the console but by pagers like `less'. groff never uses termcap or terminfo information for its TTY output, and I don't plan to add this -- nobody has ever complained. Looking into the source of jless, the Japanized version of less (which apparently doesn't support Unicode), it seems that indeed two `\b's are expected for overstriking and bold printing. Bruno has also shown that two backspace characters give predictable results, so this is what I will use. Werner [1] This is the old scheme. The new scheme uses SGR escape sequences. ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Argh - updated www.tmac patch
> I forgot the documentation update. Use this patch tarball instead. Applied, thanks! Please use the `-u' switch of diff the next time. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Re: YaDCM (Yet another Drop Capital Macro)
> Yes thanks Werner and in return I offer `Yet another Drop Capital
> Macro'.
*Very* nice! This may be something for mom...
Below a patch for it.
Werner
==
--- dropcap.tmac.orig 2005-03-18 10:17:24.263842176 +0100
+++ dropcap.tmac2005-03-18 10:17:24.263842176 +0100
@@ -107,13 +107,13 @@
. nr dc::linesindex \\n[dc::linesm1]
. ds dc::font \\$4
. ds dc::family \\$5
-. nr dc::adjustment (\\$6;u)
-. nr dc::lastadjust (\\$6;u)
+. nr dc::adjustment (u;\\$6)
+. nr dc::lastadjust (u;\\$6)
. shift 5
. while \\n[dc::linesindex]>0 \{\
. nr dc::adjustarray\\n[dc::linesindex] 0
. ie \\n[.$]>0 \{\
-.nr dc::lastadjust (\\$1;u)
+.nr dc::lastadjust (u;\\$1)
.nr dc::adjustarray\\n[dc::linesindex] \\n[dc::lastadjust]
.shift
. \}
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: YaDCM (Yet another Drop Capital Macro)
> However, I see a couple of problems:- [...] Gaius, in case you've fixed those issues please repost your macro with all patches applied. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: YaDCM (Yet another Drop Capital Macro)
> > 2) if there isn't enough following text to bring the paragraph
> >baseline below the bottom of the dropped cap, and the following
> >para also begins with a dropped cap, the indentation is messed
> >up for subsequent paras.
>
> I've not fixed (2) either.. does anyone see an obvious fix for this?
Here's a patch. This also fixes dropcaps which vertically span more
than a single paragraph.
Werner
==
--- dropcap.tmac.orig 2005-03-19 00:09:46.0 +0100
+++ dropcap.tmac2005-03-19 08:12:15.163393160 +0100
@@ -77,6 +77,8 @@
. el \{\
'in \\n[dc::orig-indent]u
. \}
+. if \\n[.trunc] \
+. sp \\n[.trunc]u
..
.\"
.\" dropcap - WORD LINES COLOUR FONT FAMILY ADJUSTMENT { ADJUSTMENT }
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: YaDCM (Yet another Drop Capital Macro)
> This also fixes dropcaps which vertically span more > than a single paragraph. Well, this is not correct. It fixes the case where we have empty lines or a vertical space which is larger than the height of the dropcap. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Broken chars
> I have observed that groff changes certain characters in manpages.
> [...]
>
> For example, in perlcheat.1, the $| is changed into '$' and a
> vertical bar if the locale is UTF-8.
>
> real: | (U+0x7C)
> output: â (U+0x2502)
>
> This also to a number of other characters, including the backward
> apostrophe (accent grave) ` (0x60) which is transformed into â
> (U+0x2018). This is very bad for copy+paste, and if your screen
> font does not have all the UTF8 characters (especially the case on
> bare 80x25 tty1 terminal), it does not even show any apostrophe, but
> a block to indicate that 0x2018 is not available in this font.
>
> Is this a (big) bug in groff, or intention?
In
usr/[local/]share/groff//font/devutf8/R
you can see which output codes are used for which input characters.
Looking into perlcheat.1, you can find this (converted on my platform
with Pod::Man v 1.37):
.tr \(*W-|\(bv\*(Tr
The .tr request translates characters. In this particular case, it
translates `|' to `\(bv'. `bv' is equivalent to `braceex' in PS
output, and is by default mapped to U+23AA. I have no idea why you
get U+2502 instead. And I have no idea why Pod:Man uses `bv' at all.
Regarding the grave accent mapped to U+0x2018, here is the comment
from groff_char(7):
` the ISO Latin-1 `Grave Accent' (code 96) prints as ,
a left single quotation mark; the original character can be
obtained with `\`'.
' the ISO Latin-1 `Apostrophe' (code 39) prints as , a
right single quotation mark; the original character can be
obtained with `\(aq'.
For typesetting this is the right choice, since those two character
are used this way normally, similar to TeX.
Distributions can overwrite this. For example, in my SuSE 9.1, I have
this in /usr/share/groff/site-tmac/tmac.andocdb:
.if '\*[.T]'utf8' \{\
. char \- \N'45'
. char - \N'45'
. char ' \N'39'
.\}
To summarize:
. Mapping `|' to the `bv' entity is strange. If you use a plain `|'
in a troff input file, you actually get a plain `|'! This looks
like a bug in Pod::Man.
. The ` and ' characters in groff input files always indicate left
and right single quotation marks. U+0060 and U+0027 can be
accessed as \` and \(aq. Ideally, this is fixed in Pod::Man too,
if you use a `verbatim' mode, by translating those characters
temporarily. Otherwise, as shown above, this can be changed in
the configuration file of the man macros.
Werner
PS: Why the heck is `perlcheat.man' and all other non-program man
pages of perl in man section 1?
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Web Site Addresses
> In the section on creating links to internet resources, I propose > using the groff web site address in my examples. I note that this > site is mirrored at `http://groff.ffii.org' and at > `http://www.gnu.org/software/groff'; which of these is the preferred > address to cite in my examples? A good question. First, the two sites aren't mirrors but manually set up to contain the same page. Second, the former can only hold GPLed (or public-domain) software, while the latter doesn't have this restriction -- as discussed before, it is planned to add an archive of macros, and this shouldn't be restricted to GPL-compatible stuff. It seems best currently to point to ffii.org. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Bug in pdfroff, using `--no-reference-dictionary' option
> This *shouldn't* have happened, so here's a patch to fix it ... Applied, thanks. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Broken chars
> >The .tr request translates characters. In this particular case, it
> >translates `|' to `\(bv'. `bv' is equivalent to `braceex' in PS
>
> Hm, here's a suse'd perlcheat.1.gz, which when viewed with a plain text
> editor, contains $|, and not \(bv.
> (http://jengelh.hopto.org/f/perlcheat.1.gz)
Of course! And the line
.tr ... |\(bv ...
in the preamble of the man page converts it to the `bv' entity in the
output.
> In the "devutf8/R" file is:
> ba 24 0 0x007C
> or "
> | "
> br 24 0 0x2502
> bv "
Aah, sorry, I've changed the `bv' mapping in later groff versions
(U+2502 is wrong).
> > ` the ISO Latin-1 `Grave Accent' (code 96) prints as ,
> > a left single quotation mark; the original character can be
> > obtained with `\`'.
>
> Obviously, noone uses \`.
I do. But you are missing the point. It's the job of pod2man to
provide the correct mapping, not the user, for example by calling
.tr ... `\` ...
before handling verbatim text.
> > .if '\*[.T]'utf8' \{\
> > . char \- \N'45'
> > . char - \N'45'
> > . char ' \N'39'
> > .\}
>
> Yes the andocdb is a hack, really.
Indeed. It has been added only because most software isn't smart
enough to allow an easy search for all hyphen characters at the same
time with a single command.
> But adding all hacks, including the | mentioned above, would be an
> overkill.
No hack necessary! Just fix pod2man to avoid this braindead mapping
(at least for groff).
> Well, I do not know why they are, I guess because they don't fit in
> any other category-
> 2-syscalls and stuff 3-libc functions
> 4-block and char devices 5-config files
> 6-games 7-protocols
> 8-sysadmin9-kernel
I would put it into section 7. It describes a `protocol', namely perl
input files look like. For example, there is also `groff(7)' which
gives a short reference of the GNU language.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Broken chars
> Aah, sorry, I've changed the `bv' mapping in later groff versions > (U+2502 is wrong). BTW, I've just read the XFree 4.5.0 release notes, and I've found this item regarding xterm: Add translation to ASCII of commonly-used characters that groff translates to Unicode, when the font in use does not provide the corresponding glyphs. This seems to solve (some of) the problems. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: YaDCM (Yet another Drop Capital Macro)
> But, change that `.sp 4', half way down the second drop `A' in your
> latest example, to just a simple `.sp' -- oops, *that* wasn't meant
> to happen ;-(
The attached version fixes this. It inserts one line too much space,
though, but I haven't had time yet to investigate this further.
I've also patched some other minor details:
. The vertical size of the dropcap now also takes the depth into
account. Some fonts have capitals with descenders.
. Strings defined with .ds should end with `\"' to avoid trailing
spaces:
.ds foo abc\"
. Assignments with .nr should be enclosed in parentheses so that we
don't increment or decrement accidentally. I prefer this to the
`old' technique of using `0' as a prefix:
.nr foo (\$1)
. I've used additional parentheses for numerical expressions to make
them more readable.
. Numeric Registers must be removed with `.rr', not `.rm'.
`.dropcap' now tests whether those registers do exist, and emit a
proper `.sp' command to call all remaining traps from the previous
invocation of `.dropcap' before planting its own traps.
. Using (u;...) with `.nr' has no effect. I've removed such
constructions.
. In macros, using `\v' has exactly the same effect as `\\v'.
There's nothing to interpolate.
Werner
==
.\" dropcap.tmac 2005-03-22
.\"
.\" DROPCAP - macro set provides a reasonably comprehensive macro
.\"to achieve a drop capital.
.\"
.\"What is different from other drop capital implementations
.\"is that this allows a user to add in adjustments on
.\"a per line basis all the way down the drop capital.
.\"So for example a user may pull/push text in and out of a
.\"capital `I' if required.
.\"The first argument is the first whole word. This is
.\" automatically chopped into a letter and the subsequent
.\"letters are capitalised.
.\"
.\"Author Gaius Mulley
.\"Patches/fixes by: Keith Marshall and Werner Lemberg.
.\"
.\"It was based on a number of postings from the groff@gnu.org
.\"mailing list and it uses the .uppercase macro written by
.\"Werner Lemberg.
.\"
.\"From memory other postings which gave ideas to this
.\"macro were from: Werner Lemberg, Ted Harding,
.\"Ralph Corderoy (and others). Also some of its features
.\"were inspired by the great mom macros.
.\"
.\"Please feel free to improve and modify the macro or
.\"simply take ideas and incorporate them elsewhere.
.\"
.\" Usage:
.
.\" dropcap - WORD LINES COLOUR FONT FAMILY ADJUSTMENT [ADJUSTMENT ...]
.
.\" Example:
.
.\" .dropcap When 4 darkblue R T 0 -1n
.\" produces a rather nice effect as we can see the
.\" subsequent lines indented by -1n each line down
.\" the drop capital. It is possible to append more
.\" parameters to this macro, each parameter indicates
.\" the relative indentation for the next line.
.\" Therefore it is possible to make text pull in
.\" and out of a drop capital I.
.
.\"
.\" .uppercase in out
.\"
.\" Convert the contents of string with name `in' to uppercase
.\" and return the result in a string with name `out'.
.\"
.\" Note that this macro by default only translates the characters a-z;
.\" if you need other characters, define them in the strings
.\" `uppercase-set' and `uppercase-reset'. Both are used with the `.tr'
.\" request; the former to set the mapping, the latter to reset it.
.\"
.de uppercase
. rm \\$2
. tr aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ
. tr \\*[uppercase-set]
. di uppercase-div
. nop \\*[\\$1]
. br
. di
. asciify uppercase-div
. chop uppercase-div
. tr aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
. tr \\*[uppercase-reset]
. ds \\$2 \\*[uppercase-div]\"
..
.
.ds uppercase-set ä\[:A]\"
.ds uppercase-reset ä\[:a]\"
.
.de dc::next-line
. ie (\\n[dc::linesm1] > 0) \{\
' in +\\n[dc::adjustarray\\n[dc::linesm1]]u
. wh (\\n[nl]u + 1v) dc::next-line
. nr dc::linesm1 -1
. \}
. el \{\
. rr dc::lines dc::linesm1
' in \\n[dc::orig-indent]u
. \}
. if \\n[.trunc] \
. sp \\n[.trunc]u
..
.
.\"
.\" dropcap - WORD LINES COLOUR FONT FAMILY ADJUSTMENT [ADJUSTMENT ...]
.\"
.de dropcap
. if r dc::lines \
. sp \\n[dc::lines]
. ds dc::word \\$1\"
. ds dc::letter \\$1\&quo
[Groff] Re: troff.1 in French
> I would like to translate troff.1 in French, Great! Note that it is probably more important to translate groff.1 since this is what normal users should read first. > - do you know if this has already be done? As far as I know, this hasn't been done already. > - the version of this manpage I have is "9 December 2002"; is it the > latest one? No, the latest one is dated `12 Oct 2003'. Please check the CVS archive at http://savannah.gnu.org/cvs/?group=groff > - who should I send it to one the translation is achieved? A good question. It is probably best to directly include such files into the groff distribution. Have you contacted the French Linux translation project group? Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] TeXifying groff possible?
> Also is it possible to change the font eqn uses for > variables? Have a look at the `gfont', `grfont', and `gbfont' commands. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] pic: new box attribute - slanted
> While waiting for better suggestions, I played with > .PS > box xslanted color ... > box yslanted > .PE > to get the following results (see attached file) Nice! Can you send the source too? I wonder whether it is possible to provide high-level macros to handle such 3d-boxes... Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] developers only?
> > I'm printing the lyrics of a CD; I want it in 2-col; so I did
> >
> > .2c
> > .nf
> >
> > I wanted groff to *not* join short lines but break long lines;
> > Short lines were not joined, ok!
> > But groff did not break the long lines :-))
> > - Long lines in the first column invaded the second column
> > - Long lines in the second column were truncated
> >
> > How do I get groff to split but don't join?
> >
> > I'm using -me and groff 1.17.2 (debian stable);
>
> If you don't like the extra macro per line, the next step of
> sophistication might be a higher-level macro that reads an input
> line of text (using, e.g., an input line count trap) and formats
> that line, repeating until it reaches some end condition.
Here it is, independent of the macro package.
Werner
==
.\" break -- no join
.de BNJ
. nr BNJ-dobreak 1
. it 1 BNJ-break
..
.
.de /BNJ
. nr BNJ-dobreak 0
..
.
.de BNJ-break
. if \\n[BNJ-dobreak] \{\
.br
.it 1 BNJ-break
. \}
..
.
.ll 3i
.
.BNJ
This is a test of a very long line needed to test the BNJ macros.
This is another very long line to test the break-nojoin macros.
And here is the final long line we use for testing the BNJ stuff.
Some short lines.
Another short one.
./BNJ
This is a test of a very long line needed to test the BNJ macros.
This is another very long line to test the break-nojoin macros.
And here is the final line we use for testing the BNJ stuff.
Some short lines.
Another short one.
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] developers only?
> Darn! It seems you beat me to the list by 30 minutes. But the > funny thing is that this is not the first time we've come up with > structurally the same solution to a problem. Does this imply that > in groff normally only one workable approach to a problem exists? Well, some solutions can't be improved :-) Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Spam from list member addresses
> I got two pornographic-sounding spams today, one apparently from > Werner, the other apparently from Ted Harding. Rather than wait to > see if these are isolated incidents, I'm cut 'n' pasting both emails > with full headers into this post. Thanks. I've written a complaint to the savannah people. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] relocation support for Windows
Kees, Your relocation changes are now in the CVS. I had to do some heavy hacking to incorporate everything in a clean way. Please test. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] refer question
> I think, if there's a problem with refer, it's the documentation. > There's very little of it other than the manpage, and the manpage is > a pure example of what can be both good and bad about manpages: it > contains all the information you need, but in a form so terse you > have to know the program before you can make sense of it. Example: > >Macro interface >Each reference starts with a call to the macro ]-. > > The manpage doesn't say you have to create ]- yourself, which, > though self-explanatory once you grasp how refer works, would make > the grasping of it faster. Since I don't use refer actually, I would be glad if you can provide patches so that the man page becomes better. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] ~ in .so argument
> Is it considered a security risk to allow ~ or shell environment > variables in the argument to .so? For example, > > .so ~/.groffrc > > .so $HOME/.groffrc I don't think so. All `dangerous' requests like `.open' or `.sy' are enabled only if you add the `-U' flag to groff. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] ctype.h in pipeline.c
I was asked whether ctype.h should be included in src/roff/groff/pipeline.c -- this is for MS-DOS and Windows only. It seems to me that it is not necessary, right? Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] ctype.h in pipeline.c
> I don't see any such calls in pipeline.c, so I think you are > correct; it is not necessary. Thanks, I've removed it. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Fw: The FSF is moving
--- Begin Message ---
The Free Software Foundation will be moving to a new office on
Friday April 29, 2005.
Starting Friday morning (GMT-4) and extending through the weekend, the
following FSF services will be unavailable:
* fencepost.gnu.org: GNU project shell server
* lists.gnu.org, lists.nongnu.org: Mailing list services
* mail.gnu.org: FSF/GNU mail server
* order.fsf.org: On-line ordering system
* rt.gnu.org: FSF/GNU request tracking system
The FSF has backup mail servers that are located off-site which will
be able to accept mail during the downtime. This means that mail to
gnu.org, nongnu.org, and fsf.org addresses (including mailing lists)
will be delayed but will be delivered.
The FSF is releasing a new version of the GPL! Unfortunately, it's
not version 3 yet. Instead, it's the third revision of version 2. Like
the previous revision, it will differ only in that it will contain
FSF's new address. This version will be available and effective on
Friday, April 29, 2005.
When you next get the chance, please go through your source code and
replace the old copy of the GPL with the new version. Also, old
notices should be replaced with new ones. The following shell command
will do this for you in a sloppy way; its results should be carefully
checked:
find . -type f -exec sed -ie 's/59 Temple Place, Suite 330/51 Franklin
Street, Fifth Floor/;s/02111-1307/02110-1301/;' {} ';'
We will also be releasing new revisions of the LGPL and the FDL.
___
GNU Maintainers Announcement List [EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/gnu-prog
--- End Message ---
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] CVS Build Problem
> The first problem was easy -- you're not allowed to have > declarations mixed with code in C like you are in C++: Applied, thanks. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Re: pdfmark Support for Folded Outlines
> Here's a patch to add support for the creation of folded outlines, > in any PDF document formatted using the pdfmark macros. Applied, thanks. > Also Werner, when (if) you apply this, could you also please correct > a typo in my previous entry [...] Fixed too. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Re: CVS Broken for Win32
> The problem appears to be due to the use of `realpath()' in > `relocate.cpp'; the native Win32 equivalent for this function is > `_fullpath()', and the semantics are different. It could probably > be fixed with an appropriate `#define' in `nonposix.h', or, if this > module is specific to Win32 in any case, simply by modifying > `relocate.cpp' itself; which approach do you prefer? Please fix it in relocate.cpp (this is file is only used under Windows). > I don't have time to investigate further today, but may get an > opportunity to develop a patch later in the week. Thanks in advance for investigating! Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] CVS Build Problem
> > Sorry, but I can't see any obvious clues in the make trace you posted. > > Neither can I, that's why I'm asking for help. :-) Perhaps you can try to use `strace' or a similar program. Then you can check where the files are searched. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] groff and layout stability
On comp.tex.latex there was some discussion w.r.t. document layout stability and hyphenation patterns: Subject: Consistency of US hyphenation patterns across distributions References: <[EMAIL PROTECTED]> Up to today, noone has ever mentioned a similar problem here, and I must admit that I've never thought about it. The current state of groff is simple: It does *not* assure layout stability, this is, it is quite possible that documents look different if processed with different groff versions. I don't think this is a serious problem because you can always use an older groff release in case this stability is important to you. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] CVS Build Problem
> It appears that groff doesn't pass the command line font directories > on directly but rather sets an environment variable > ($GROFF_FONT_PATH). This is correct. > That variable does seem to be set correctly for both grn and troff, > but they don't seem to be paying any attention to it. Strange. The function font::load_desc (in font.cpp) calls font::open_file (in fontfile.cpp) which in turn calls font_path.open_file, where font_path is a search_path which explicitly uses $GROFF_FONT_PATH. Looking into searchpatch.cpp you can see that search_path::search_path loads the contents of GROFF_FONT_PATH with getenv. Please insert some code there to print the value of GROFF_FONT_PATH to stderr. All mentioned files are in src/libs/libgroff. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] CVS Build Problem
> It turns out that the problem is that search_path::search_path is > called from a static constructor, but static constructors are called > *before* the global environment pointer is set, so getenv() doesn't > work in a static constructor. Not being a C++ expert, I have no > idea whether this is a bug in my C++ implementation or a bug in > groff. I think this is a compiler bug. Can you try a newer compiler version? At least one other compiler (on OS/390) has problems with static constructors too (but more basic ones). BTW, the code in question is more than 15 years old since there is no specific entry in the ChangeLog file. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] CVS Build Problem
> It was BSD/OS 4.2 too. I never found the time to get to the bottom > of the problem and abandoned updating groff on that box. Somebody > changed groff's build/install stuff to make it more Linux-specific, > breaking backwards compatibility with the installed base. ??? This is nonsense. Normally, Nelson Beebe installs groff on more than 20 different UNIX flavours, and not a single report of him mentions severe installation problems. I don't think that he actually has a BSD/OS 4.2 machine, but your accusation is plain wrong. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] pic resize problem
> When i process a pic file into a postscript file, for some reason it > gets shrunk automatically, how do i stop this? i type this in the > command line: > > pic floorB.pic | psroff -ms -t > floorB.ps > > and get this output: > > pic: 60 X 42 picture shrunk to 7 X 4.9 Uh, oh, whatever you use, it isn't groff! Anyway, I'm very grateful because your input file has identified a parsing bug in GNU pic. This: A: (1,1) B: (2,2) line from (A) to (B) or this: A: (1,1) B: (2,2) line from (A + (1,1)) to (B - (2,2)) were rejected (a fix is now in the CVS). You have to omit the outer parentheses to make it work with older GNU pic versions, e.g. A: (1,1) B: (2,2) line from A + (1,1) to B - (2,2) To come back to your example: There is no shrinking with groff. Due to the big width I use the following invocation to print it in landscape: groff -Tps -dpaper=letterl -P-pletter -P-l -p floorB.pic > floorB.ps The `groff' program is a wrapper for the many different pre- and postprocessors. `-Tps' selects the output device, `-p' calls pic, `-dpaper=letterl' defines the string register `paper' to contain `letterl' -- groff then adjusts the width and height for various macro packages. THe `-P-pletter' tells the output device to select the (physical) letter paper format, and `-P-l' tells the output device to use landscape. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Re: Minor Problem Building from Distribution Tarball
> [...] I configured in a separate build directory, and uncovered a > small problem with the `doc' directory. Specifically, the `gnu.eps' > file needs to be in the build directory when `webpage.html' is > formatted, but the make doesn't copy it from the source. > > Attached patch fixes this, [...] Applied. Thanks a lot! Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] new groff prerelease
Nelson, groffers, I'm going to release a new groff version, and I ask you to run the current CVS snapshot tarball on your platforms to check for problems. Honestly, I do expect minor glitches because I've updated the getopt files to the latest versions of GNU libc. You can find the tarball at http://groff.ffii.org/groff/groff-1.19.2-pre.tar.gz Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: CVS Broken for Win32
Keith, thanks for the patch. I've simplified it a bit: Your _MAX_PATH code is now in maxpathname.cpp. Please test. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Re: New getopt depends on gettext
> Just a quick note in case you haven't already noticed, the new GNU > getopt routines that you checked in apparently require the GNU > gettext routines, too (which you haven't checked in as yet): @#$%! I missed it. Since groff doesn't use gettext, I'll undo the change, reverting to the old files. Aaaargh. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Re: new groff prerelease
> >> http://groff.ffii.org/groff/groff-1.19.2-pre.tar.gz > > Actually, it's > > http://groff.ffii.org/groff/devel/groff-1.19.2-pre.tar.gz Oops! Thanks for the correction. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] CVS Build Problem
> Having said that, I've subsequently realised that I omitted to test > `pdfroff' on Cygwin. I've since done just that, and uncovered a > problem with running in the `ash' shell, (which Cygwin uses, rather > than `bash', in place of `sh'). > > Here's a patch: [...] Applied, thanks. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Prerelease fails on OS X.3.9
> Like the title line says, with the messages: > > getopt.c:73:22: gettext.h: No such file or directory This is fixed now by reverting to the old getopt version. Will post a new preprelease soon. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] CVS Build Problem
> I could, but it wouldn't help -- the bug is in the system's startup > code, which isn't part of the compiler. Fortunately, I have source > code, so I can fix it. After setting up the environ global variable > before running the initialization code, things work much better. Can you prepare a small entry for groff's PROBLEM file? > I have one last problem -- contrib/pdfmark/pdfroff.sh makes > extensive use of the "type" command, which is *NOT* a standard shell > command. I was able to work around it by changing the first line > from #!/bin/sh to #!/bin/bash, but it should probably be rewritten > portably. Keith, does your latest patch fixes this? Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] new groff prerelease
> Using the tarball I mentioned in the other email, I've installed > Debian stable's DejaGnu and after `./configure && make' get > > $ make -s check > WARNING: Couldn't find tool init file > Test Run By ralph on Sun May 1 19:27:48 2005 > Native configuration is i586-pc-linux-gnu DejaGnu stuff isn't available (yet). The patches from Gaius were too confusing for me (he just ripped the changes off the gcc distribution). It is probably best to disactivate those stuff. Can you provide a patch? Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: CVS Broken for Win32
> However, my version *did* have one important difference -- according > to MSDN, _MAX_PATH is defined in stdlib.h, which isn't #included by > maxpathname.cpp, so you need to add that. Done. > If path_name_max() is to be used, in place of MAX_PATH in the > _fullpath() call, should it not also be used consistently in these > two subsequent calls as well? Done too. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] CVS Build Problem
> And thanks again, for this. Unless there are any objections from > others, I'll investigate a solution based on option 4. I agree. What the autoconf people use we can use also. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] refer question
> > is there a way to reset refer settings somewhere 'downstream' if > > the 'upstream' defaults are no good? > > > > specifically: > > > > in my document I source a certain defaults file in which, upon > > different other settings, one finds: > > > > ... > > .R1 > > database the_standard_database > > .R2 > > ... > > > > now, I want to set in the _current_ document > > > > ... > > .R1 > > database a_different_database > > .R2 > > ... > > > > which by itself of course _appends_ the new database to the set of > > databases searched (and is searched latest). > > > > can I enforce solely searching of the new database without > > eliminating the first one from the defaults file (which would be > > bad for other documents...)? i.e. is there a way to clear the > > variable holding the database string (well, what is it's name? :-) ) > > .R1 > no-default-database > database a_different_database > .R2 > > instructs refer not to search the default database. If later you > need to have refer include the default database again: > > .R1 > default-database > .R2 > > I think that should work. No, it doesn't. First of all, `default-database' doesn't take an argument. The default database is either the compiled-in value (normally `/usr/dict/papers/Ind') or the value set with the `REFER' environment variable. Second, databases are always additive; it isn't possible to either remove an entry or reset the list to an empty value. I suggest that you don't do .R1 database the_standard_database .R2 in your ini file; instead you should set the default database with the REFER environment variable. You can then suppress its loading by issuing .R1 no-default-database .R2 at the very beginning of your document, after which .R1 database ... .R2 loads your specific database(s). Note that `REFER' isn't something new; it just hasn't been documented before groff version 1.19. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] Fw: ac_ext problems
Good news for you, Jeff. Finally! Werner --- Begin Message --- Werner LEMBERG <[EMAIL PROTECTED]> writes: > Is there any reason to stay with `.cc' as the extension for C++ files > for the autoconf tests, given that `.cpp' is much more portable? Not that I know of. I installed your patch. Thanks. --- End Message --- ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Fw: ac_ext problems
> Sorry I didn't follow this thread and exact reason to change. > I see this as a good reason to leave it as .cc There are at least two C++ compilers (MSVC and a native OS/390 one) which can't handle the `.cc' extension, while *all* C++ compilers can handle `.cpp'. > c++ -O2 -o tryme tryme.cc > $ rm tryme > $ mv tryme.cc tryme.cpp > $ make tryme > make: don't know how to make tryme. Stop in /home/zvezdan. > $ gmake tryme > g++ tryme.cpp -o tryme > > Obviously only gmake recognizes .cpp as a C++ file on a Unix system. > With older version of gmake on a different Unix machine .cpp has not > been recognized. Whether `make' programs recognize the `.cpp' extension by default is completely irrelevant for autoconf. BTW, groff's Makefiles don't use *any* built-in make rules. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Fw: ac_ext problems
> I should have known better than to question the wisdom of groff > developers. I guess I got paranoid using some other software where > people are quick to introduce changes without thinking them through. > Sorry for the noise. Well, it's sometimes very valuable to have an advocatus diaboli :-) Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] CVS Build Problem
> Should I rather use option 3, [...] No. > Attached is a small script, demonstrating a possible `searchpath' > shell function. [...] On my Linux box it works fine. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Using pic/groff/gs to produce gif/jpeg
> Hi, I'm new to pic/groff and I've been having some problems > producing either gif or jpeg images using them. The basic problem > seems to be that pic/groff/postscript all have the concept of a page > that they are drawing on whereas I want the resulting image to have > all the whitespace cropped from the margins. This is to go in a web > page so the idea of a page doesn't make sense. If you just want to convert a PIC image you might also try the pic2graph script which comes with groff, which always crops the image. Using the `-density' comomand line option you can control the resolution of the final image. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Using pic/groff/gs to produce gif/jpeg
> Hmmm, what I didn't notice was that this time the _bottom_ of the > image wasn't getting cropped! This seems to be a bug. Please send me an example file together with the exact command line. Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Using pic/groff/gs to produce gif/jpeg
> Hi, create a file foo.pic containing just one line: > > box "hello world" > > process like this: > > pic2graph -format jpg -density 90 < foo.pic > foo.jpg > > if you put foo.jpg into a web page you can see that there is a load > of blank space below the box. > > This was using groff version 1.19.1 and convert version 6.2.2. Hmm, with the current CVS and my installed `convert' program (from ImageMagick 5.5.7 03/11/05), I get the attached JPG image which has a size of 69x47 pixels. This is the smallest bounding box possible. > You get the correct behaviour with a file foo.pic containing: > > .PS > box "hello world" > .PE > > and processed like this: > > groff -p -P-pletter foo.pic | convert -trim -density 90 - foo.jpg It seems that newer `convert' versions have changed the meaning of `-crop'. I've added `-trim' to pic2graph in the CVS. Thanks for the report. Werner <>___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Using pic/groff/gs to produce gif/jpeg
> By the way, another weird little quirk which doesn't seem to be > mentioned in my admittedly brief read of the documentation: if your > diagram goes beyond the default width as understood by pic then it > starts scaling the image automatically! It's really baffling when it > first happens - you make your boxes wider and instead of getting > wider, the height shrinks. > > Setting maxpswid to some suitably large value prevents this > behaviour. Can you provide a patch to the documentation to fix this? Werner ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
