[groff] 01/01: Updated example files for 2.1-a
PTPi pushed a commit to branch master in repository groff. commit 72c5d994c4de3ae41c7d026ddcc761fc7293453f Author: Peter Schaffter pe...@schaffter.ca Date: Tue Apr 28 12:43:09 2015 -0400 Updated example files for 2.1-a --- contrib/mom/examples/mom-pdf.mom |7 ++- contrib/mom/examples/sample_docs.mom | 17 +--- contrib/mom/examples/typesetting.mom | 74 +- 3 files changed, 51 insertions(+), 47 deletions(-) diff --git a/contrib/mom/examples/mom-pdf.mom b/contrib/mom/examples/mom-pdf.mom index b972c69..0749f41 100644 --- a/contrib/mom/examples/mom-pdf.mom +++ b/contrib/mom/examples/mom-pdf.mom @@ -116,8 +116,8 @@ If not, see: .char \[-Tpdf]\*[BD]-Tpdf\*[PREV] .char \[-Tps] \*[BD]-Tps\*[PREV] .\ Strings for inline code -.ds cod \E*[CODE]\\E*[COND] -.ds codx \E*[CONDX]\E*[CODE off]\ +.ds cod \E*[CODE]\\E*[COND] +.ds codx \E*[CONDX]\E*[CODE off]\ .\ Paragraph spacing .de PP2 . ALD .3v @@ -128,6 +128,7 @@ If not, see: . QUOTE . nop \*[COND]\\$*\*[CONDX] . QUOTE OFF +. sp -\\n[#SHIM]u .. .\ Note box .de BOX-NOTE @@ -618,7 +619,7 @@ the output through \[ps2pdf]\*[B] .FLOAT .QUAD LEFT .BR_AT_LINE_KERN -.IQ +.IL -2P .BOX-NOTE (\n[.l]u-6P) 3P .EW .3 \*[BD]Note:\*[PREV] Owing to a known bug, PDF files piped diff --git a/contrib/mom/examples/sample_docs.mom b/contrib/mom/examples/sample_docs.mom index 8c06262..c2cb79a 100644 --- a/contrib/mom/examples/sample_docs.mom +++ b/contrib/mom/examples/sample_docs.mom @@ -81,13 +81,13 @@ .DOC_COVER_TITLE_STYLE \ SIZE +8 \ SMALLCAPS \ - UNDERLINE 1 3p + UNDERLINE 1 3p .DOC_COVER_SUBTITLE_STYLE \ FONT I \ - SIZE +3 \ + SIZE +2 \ LEAD 18 \ - SPACE .5v -.DOC_COVER_COPYRIGHT_SIZE +.5 + SPACE .75v +.DOC_COVER_COPYRIGHT_SIZE -.5 \# .COVER_TITLE_SIZE +5 .COVER_ATTRIBUTE_STYLE \ @@ -99,7 +99,7 @@ .COVER_DOCTYPE_STYLE \ SIZE +4 \ UNDERLINE DOUBLE 1 -.COVER_COPYRIGHT_SIZE +.5 +.COVER_COPYRIGHT_SIZE -.5 \# \# Here we style the docheader a bit. \# @@ -280,11 +280,11 @@ nonumy eirmod tempor invidunt ut labore et do\%lo\%re magna. \# \# Style the title page \# -.COVER_CHAPTER_SIZE +3 +.COVER_CHAPTER_SIZE +6 .COVER_CHAPTER_TITLE_STYLE \ SIZE +5 \ SPACE .25v -.COVER_MISC_SIZE +.5 +.COVER_MISC_SIZE -.25 \# \# What goes on the title page \# @@ -292,6 +292,9 @@ nonumy eirmod tempor invidunt ut labore et do\%lo\%re magna. \# \# Begin the document \# +.CHAPTER_SIZE +3.5 +.CHAPTER_TITLE_SIZE +5 +.CHAPTER_TITLE_SPACE +3p .START .EPIGRAPH BLOCK Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam diff --git a/contrib/mom/examples/typesetting.mom b/contrib/mom/examples/typesetting.mom index 6965da3..0ed2d46 100644 --- a/contrib/mom/examples/typesetting.mom +++ b/contrib/mom/examples/typesetting.mom @@ -1,6 +1,5 @@ -.\ -*- mode: troff; coding: utf-8; -*- -. -\# Copyright (C) 2004-2014 Free Software Foundation, Inc. +\# Copyright 2004, 2005, 2006, 2009, 2010, 2011, 2012 +\# Free Software Foundation, Inc. \# \# Copying and distribution of this file, with or without modification, \# are permitted in any medium without royalty provided the copyright @@ -37,7 +36,7 @@ .SP |1i-1v \ Advance 1 inch from top of paper to first baseline Example 1\*[BU 2]: .ALD .25v \ Advance an extra 1/4 linespace -.UNDERSCORE 3.75p T\*[BU 4]asting notes using padding, string tabs \ +.UNDERSCORE 3.5p T\*[BU 4]asting notes using padding, string tabs \ and multi-columns \# .SP\ Add an extra line space @@ -82,27 +81,27 @@ and multi-columns \# .TAB 1 \ Notice that this tab gets set line-for-line \*[IT]Peelee Island\ Set italic -\*[PREV]Gewürztraminer \ Revert to former font (roman) +\*[PREV]Gew�rztraminer \ Revert to former font (roman) 2000 (Canada) .MCR \ Return to top of column .TAB 2 \ Call tab 2; in multi-column mode, don't use .TN -Jaune pâle. +Jaune p�le. .MCR .TB 3 \ Notice that from here on, we use the alias TB instead of TAB -Frais, fruité, ci\%tronné, arômes fortes de lichee et de fruits +Frais, fruit�, ci\%tronn�, ar�mes fortes de lichee et de fruits tropicaux. .MCR .TB 4 -Doux, fruité, bien équilibré avec une bonne acidité. +Doux, fruit�, bien �quilibr� avec une bonne acidit�. .MCR .TB 5 -Bon apéro. Servir avec des plats +Bon ap�ro. Servir avec des plats .RW .1 \ Reduce Whitespace between letters to tighten this line indiens ou \%chinois. .RW 0 \ Back to normal spacing between letters .BR -Excellent rapport qualité/prix. +Excellent rapport qualit�/prix. .MCX 8p\ Multi-column mode off; advance an extra 8 points .MCO \ Re-invoke multi-columns for next wine description .TB 1 @@ -112,11 +111,11 @@ Excellent rapport qualité/prix. (Uraguay) .MCR .TB 2 -Rubis foncé, vio\%lacée, presque opaque. +Rubis fonc�, vio\%lac�e, presque opaque. .MCR .TB 3 -Belles arômes de fruits foncés (prunes, cerises noires, cassis). -Odeurs
Re: [Groff] Problem with html output
Mikkel -- On Mon, Mar 16, 2015, Mikkel wrote: What do you think I could do about this? - Command - groff -mom -Thtml ret0tmp.mom ret0tmp.html - System output: - /usr/local/share/groff/1.22.2/tmac/om.tmac:13959: warning: macro `END' not defined (possibly missing space after `EN') Format with -ms rather than -mom. I know, not the answer you want to hear. :( -mom has no -Thtml integration. She's specifically for - Tpdf or -Tps (and fairly acceptable -Tascii/latin1/utf8, though these are not her target output devices). There are two reasons for no -Thtml. One is that, IMO, the driver isn't stable enough. The other is that -mom is a more complex macro set than -ms; the amount of work required to implement -Thtml integration would be huge. I confess I'm puzzled by the specific error reported, though. -mom uses this style to define macros .MAC macroname END ... .END rather than the conventional .de macroname ... .. Seems odd that -Thtml would choke on valid groff syntax. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Lack of professionalism ....
On Sat, Mar 07, 2015, Doug McIlroy wrote: I was surprised to learn that distributed macro packages aren't the real thing, but only shadows left by a complex build process. The given reason was unpersuasive, so I ran an experiment. I made a copy of s.tmac with 10 spaces after each initial dot. Then I ran groff on a 25,000-line source file which includes 8,000 request lines, essentially all -ms macros. User times with and without extra space were indistinguishable to three significant digits: any difference was swamped out by timing noise. So it looks to me as if the policy of distributing mildly compressed macro packages has only two perceptible effects: it complicates maintenance and it complicates understanding. I am thus led to believe that this is yet another instance of ungainly galloping gnus departing from Unix's original path of simplicity and transparency. Well said. Truth is, I've never been happy with om.tmac being stripped of comments and indenting. It's dashed annoying for users, who have to replace their installed om.tmac with om.tmac-u in order to apply patches for special, site-specific features I send them. The alternative--me adding the features to an unstripped om.tmac, then stripping it before preparing the patch--is also a PITA. Plus, there's a reason for the comments and indenting. It's called clarity. My two cents worth. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] adding non-native font directories [Was: fontconfig]
On Sat, Mar 07, 2015, Larry Kollar wrote: Has anyone else successfully used site-font? I admit that I’ve always dumped custom fonts into the regular fonts directory. Been using it for years, through multiple installs. I have a very large font library, and it seems the safest place for it. -- Peter Schaffter http://www.schaffter.ca
[groff] 01/01: Fixes to PDF_IMAGE, DROPCAP, PAD and margin notes. MNbottom-left and MNbottom-right wrapped into a single macro, MNbottom.
PTPi pushed a commit to branch master
in repository groff.
commit b77f7b9019b9f912ce9dadc840489688d6a47550
Author: Peter Schaffter pe...@schaffter.ca
Date: Thu Mar 5 10:42:11 2015 -0500
Fixes to PDF_IMAGE, DROPCAP, PAD and margin notes.
MNbottom-left and MNbottom-right wrapped into a single macro,
MNbottom.
---
contrib/mom/BUGS | 17 +++-
contrib/mom/om.tmac-u | 263 +
2 files changed, 149 insertions(+), 131 deletions(-)
diff --git a/contrib/mom/BUGS b/contrib/mom/BUGS
index e113a88..f731509 100644
--- a/contrib/mom/BUGS
+++ b/contrib/mom/BUGS
@@ -1,5 +1,5 @@
-*- text -*-
-Copyright 2004-2014 Free Software Foundation, Inc.
+Copyright 2004-2015 Free Software Foundation, Inc.
Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
@@ -24,6 +24,21 @@ Also, please--no html email. That, too, gets nuked.
Version 2.1
===
+PDF_IMAGE and FLOAT environments conflicting.
+---Fixed---
+
+DROPCAP picking up color from last call to .gcolor.
+---Fixed---
+
+PAD not working properly with mom's indent macros.
+---Fixed---
+
+Margin notes not respecting differing recto-verso margins.
+---Fixed---
+
+Graphical object macros not clearing fill/no-fill registers and
+modes.
+---Fixed---
LIST ALPHA emitting a number register to output.
---Fixed---
diff --git a/contrib/mom/om.tmac-u b/contrib/mom/om.tmac-u
index 660a907..9c5e80e 100644
--- a/contrib/mom/om.tmac-u
+++ b/contrib/mom/om.tmac-u
@@ -1778,7 +1778,14 @@ end
. rm $ST\\n[#LOOP]_FILL
.\}
.rr #LOOP
-.po \\n[#L_MARGIN]u
+.ie '\\n[.z]'FLOAT*DIV' \{\
+\!. po \\n[#L_MARGIN]u
+\!. ll \\n[#L_LENGTH]u
+.\}
+.el \{\
+. po \\n[#L_MARGIN]u
+. ll \\n[#L_LENGTH]u
+.\}
.ll \\n[#L_LENGTH]u
.ta \\n[.l]u
.ie \\n[#QUAD] \{\
@@ -1865,10 +1872,11 @@ end
\#
\# Pre-define xcolors black and white
\#
-.ds black \m[black]
-.ds BLACK \m[black]
-.ds white \m[white]
-.ds WHITE \m[WHITE]
+.ds black \m[black]
+.ds BLACK \m[black]
+.ds white \m[white]
+.ds WHITE \m[white]
+.ds default \m[black]
\#
\# =
\#
@@ -2369,6 +2377,11 @@ end
\\f[\\*[$FONT_FOR_PAD]]\\s[\\n[#SIZE_FOR_PAD]u]\\*[$PAD_STRING]
.br
.di
+.if \\n[#INDENT_ACTIVE] \{\
+. if \\n[#INDENT_LEFT_ACTIVE] .ll -\\n[#L_INDENT]u
+. if \\n[#INDENT_RIGHT_ACTIVE] .ll -\\n[#R_INDENT]u
+. if \\n[#INDENT_BOTH_ACTIVE] .ll -\\n[#BR_INDENT]u
+.\}
.char \\*[$PAD_MARKER] \
\R'#SPACE_TO_END \En[.l]-\En[p]'\R'#PAD_SPACE
\En[#SPACE_TO_END]/\En[#PAD_COUNT]'
.di PAD_STRING
@@ -2376,6 +2389,8 @@ end
\\f[\\*[$FONT_FOR_PAD]]\\s[\\n[#SIZE_FOR_PAD]u]\\*[$PAD_STRING]
.br
.di
+.if \\n[#INDENT_ACTIVE] \
+. if (\\n[#INDENT_LEFT_ACTIVE]=1):(\\n[#INDENT_BOTH_ACTIVE]) .ll
.char \\*[$PAD_MARKER] \h'\En[#PAD_SPACE]u'
.if \\n[#SILENT] .SILENT
.fam \\*[$FAMILY_FOR_PAD]
@@ -2396,7 +2411,7 @@ end
.rr #PAD_SPACE
.rm $PAD_STRING
.rm PAD_STRING
-.rchar #
+.rchar \\*[$PAD_MARKER]
.if '\\$2'NOBREAK' \{\
. TRAP OFF
. EOL
@@ -2614,7 +2629,7 @@ end
. \}
. el .PRINT \
\\*[DOWN \\n[#DC_LINES]v]\
-\m[\\*[$DC_COLOR]]\\*[$DROPCAP]\m[]\\*[UP \\n[#DC_LINES]v]
+\\*[$DROPCAP]\\*[UP \\n[#DC_LINES]v]
.\}
.if '\\$3'COND' \E*[COND]
.if '\\$3'EXT' \E*[EXT]
@@ -2684,6 +2699,10 @@ end
\# RULE_WEIGHT.
\#
.MAC DRH END
+.rr #FILLED
+.rr #FILL_MODE
+.rr #NOFILL
+.rr #NOFILL_MODE
.if \\n[.vpt]=1 \{\
. vpt 0
. nr #RESTORE_TRAP 1
@@ -2709,7 +2728,7 @@ end
.ds $RL_INDENT \\$2
.ds $RL_LENGTH \\$3
.ie !'\\$4'' .ds $RL_COLOR \\$4
-.el .ds $RL_COLOR default
+.el .ds $RL_COLOR \\*[default]
.nr #SAVED_WEIGHT \\n[#RULE_WEIGHT]
.nr #SAVED_WEIGHT_ADJ \\n[#RULE_WEIGHT_ADJ]
.di NULL
@@ -2746,6 +2765,7 @@ end
\D'l \\*[$RL_LENGTH] 0'\
\v'-\\n[#RULE_WEIGHT_ADJ]u'\
\D't \\n[#SAVED_RULE_WEIGHT]'
+. rr #RESTORE_L_LENGTH
.\}
.if \\n[#FILLED]=1 \{\
. if \\n[#FILL_MODE]=0 .QUAD LEFT
@@ -2826,6 +2846,10 @@ end
\# .gcolor.
\#
.MAC DRV END
+.rr #FILLED
+.rr #FILL_MODE
+.rr #NOFILL
+.rr #NOFILL_MODE
.if \\n[.vpt]=1 \{\
. vpt 0
. nr #RESTORE_TRAP 1
@@ -2853,7 +2877,7 @@ end
.ie !'\\$4'' \{\
. ds $RL_COLOR \\$4
.\}
-.el .ds $RL_COLOR default
+.el .ds $RL_COLOR \\*[default]
.nr #SAVED_WEIGHT \\n[#RULE_WEIGHT]
.nr #SAVED_WEIGHT_ADJ \\n[#RULE_WEIGHT_ADJ]
.RULE_WEIGHT \\*[$RL_WEIGHT]
@@ -2881,9 +2905,8 @@ end
. vpt 1
. rr #RESTORE_TRAP
.\}
-.if '\\n[.z]'FLOAT*DIV' \{\
+.if '\\n[.z]'FLOAT*DIV' \
. if !(\\n[.d]+\\*[$RL_DEPTH])\\n[D-float] .nr D-float
\\n[.d]+\\*[$RL_DEPTH]
-.\}
.END
Re: [Groff] adding non-native font directories [Was: fontconfig]
On Tue, Mar 03, 2015, SGT. Garcia wrote: thanks for clarifying. my question however is aiming at something different. i think i should have asked: is it possible to use any font other than the ones that come with groff. following some other pointer i came across heirloom project and some hints here and there about TROFFONTS environment variable. has there been any implementation of that in groff? for those who know what TROFFONTS does in heirloom troff, does it do what i'm asking for? i.e. does it allow to specify directories other than the one native to troff and use fonts in those directories? Here's a quick overview * Supported font types: - devps - .pfa, .t42 - devpdf - .pfa Fonts not of these types can be converted, including .otf. * Requirements for using a non-standard groff font: - the font itself in .pfa or .t42 format - a groff font file - a DESC file - a listing in the 'download' file Note: - devps uses *spaces* as the field delimiter in the 'download' file - devpdf uses *tabs* as the field delimiter in the 'download' file Making fonts available to both devps and devpdf requires separate 'download' files for both devices. * Directories: - anydir/devps - anydir/devpdf Any directory may be used to hold groff fonts provided it has the subdirectories ../devps and ../devpdf, and ../devps and ../devpdf contain the .pfa/.t42 font, the groff font file, the DESC file, and a 'download' file Use the GROFF_FONT_PATH variable or the -F flag to groff to access fonts in anydir. A simple solution to non-standard groff fonts is to place them all in /usr/share/groff/site-font/devps /usr/share/groff/site-font/devpdf or /usr/local/share/groff/site-font/devps /usr/local/share/groff/site-font/devpdf If these directories do not exist, you may create them. The site-font directory is searched by groff so there's no need to set GROFF_FONT_PATH or use the -F flag. site-font is not overwritten by any new groff install, so your fonts are safe. Lastly, as Dale pointed out, the bash script 'install-font.sh' takes care of all the details of groff font installation. Hope this clarifies things. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] adding non-native font directories [Was: fontconfig]
On Tue, Mar 03, 2015, SGT. Garcia wrote: just a note on the script which seems very old; back-ticks (`) are deprecated and also mkdir could use -p. first run failed for me but that's probably because groff in on my system (gentoo-linux) is installed under /usr as opposed to /usr/local. Backticks are still part of the POSIX standard, so changing them for $(...) would just be refactoring. Directories created with mkdir are tested for before they're created, so -p isn't really necessary, though if you want it, pass install-font.sh the '-p' flag. To install fonts to /usr rather than /usr/local/, pass install-font.sh the '-s' flag. Of course, what's really needed is for install-font to be a Perl script... Cheers. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] adding non-native font directories [Was: fontconfig]
On Tue, Mar 03, 2015, SGT. Garcia wrote: Peter Schaffter: i noticed something odd. when i use .PDF_WWW_LINK and .DROPCAP in the same document, the .DROPCAPS letter turns up blue, the same colour as the link! i could send you the source file for further inspections if need be. Please do. This is a scenario I haven't encountered before. -- Peter Schaffter http://www.schaffter.ca
[groff] 01/01: - Fix to bug in LIST ALPHA. - Add ADJUST to QUOTE/BLOCKQUOTE. - Improve handling of PDF_TARGET when descriptive text is to be output. - Doc updates.
PTPi pushed a commit to branch master in repository groff. commit 5f755aaeb6fcd284d2f4557eedab929323e9a626 Author: Peter Schaffter pe...@schaffter.ca Date: Sat Feb 28 09:42:10 2015 -0500 - Fix to bug in LIST ALPHA. - Add ADJUST to QUOTE/BLOCKQUOTE. - Improve handling of PDF_TARGET when descriptive text is to be output. - Doc updates. --- contrib/mom/BUGS |3 + contrib/mom/ChangeLog|9 +++- contrib/mom/momdoc/docelement.html | 86 ++ contrib/mom/momdoc/headfootpage.html |4 +- contrib/mom/om.tmac-u| 47 +-- 5 files changed, 101 insertions(+), 48 deletions(-) diff --git a/contrib/mom/BUGS b/contrib/mom/BUGS index 3412e74..e113a88 100644 --- a/contrib/mom/BUGS +++ b/contrib/mom/BUGS @@ -25,6 +25,9 @@ Also, please--no html email. That, too, gets nuked. Version 2.1 === +LIST ALPHA emitting a number register to output. +---Fixed--- + HEADER_PLAIN and FOOTER_PLAIN broken. ---Fixed--- diff --git a/contrib/mom/ChangeLog b/contrib/mom/ChangeLog index 755e8d3..89db7ae 100644 --- a/contrib/mom/ChangeLog +++ b/contrib/mom/ChangeLog @@ -1,7 +1,12 @@ +* Sat Feb 28 2015 + + o Added an ADJUST argument to QUOTE and BLOCKQUOTE to facilitate + optical centering tweaks + * Sat Feb 21 2015 - o Expanded scope of _STYLE macros to headers/footers and -page numbers + o Expanded scope of _STYLE macros to headers/footers and + page numbers * Thu Feb 5 2015 diff --git a/contrib/mom/momdoc/docelement.html b/contrib/mom/momdoc/docelement.html index 50017d6..a267e66 100644 --- a/contrib/mom/momdoc/docelement.html +++ b/contrib/mom/momdoc/docelement.html @@ -2016,31 +2016,9 @@ This behaviour can be changed with the control macro /p div class=box-tip -p class=tip -span class=tipTips on vertical spacing around quotes:/span -If you wish to adjust the spacing before or after a quote or blockquote -manually (with -a href=typesetting.html#spaceSPACE/a/ -a href=typesetting.html#aldALD/a/ -a href=typesetting.html#rldRLD/a), -do so ioutside/i the kbd.QUOTE/kbd or kbd.BLOCKQUOTE/kbd, -like this: -br/ -span class=pre-in-pp - .SP -3p - .QUOTE - Candy is dandy - But liquor is quicker. - .QUOTE OFF - .SP -3p -/span -/p -/div - -div class=box-tip -h2 id=quote-spacing-notes class=docs style=padding-top: 9px; font-size: 100%;Further notes on quote spacing/h2 +h3 id=quote-spacing-notes class=docs style=padding-top: 9px; font-size: 95%;Notes on quote spacing/h3 -p clasdefaults +p style=margin-top: .5em If your quote (or blockquote) leading differs from the document leading, mom attempts to observe the same rules for vertical whitespace outlined above; however, she will also insert a small, @@ -2056,7 +2034,7 @@ equalized whitespace at marked places is a limitation of groff, which, by and large, processes text on a line-per-line basis.) /p -h3 id=no-shim class=docsDisable shimming of quotes and blockquotes/h3 +h4 id=no-shim class=docsDisable shimming of quotes and blockquotes/h4 p If you don#8217;t want the behaviour described above (ie you @@ -2137,8 +2115,12 @@ the kbdFORCE/kbd argument. /div div class=box-macro-args -Macro: bQUOTE/b kbd class=macro-argstoggle/kbd +Macro: bQUOTE/b kbd class=macro-args[ ADJUST +|-lt;spacegt; ] | lt;anythinggt;/kbd /div +p class=requires +bull;nbsp;The argument to kbd style=font-style: normalADJUST/kbd requires a +a href=definitions.html#unitofmeasureunit of measure/a +/p p QUOTE is a toggle macro. To begin a section of quoted text, invoke @@ -2155,6 +2137,24 @@ END, X, Q/kbd...) to turn it off. Example: And bits of her tits in Brazil. .QUOTE END /span +Mom does her best to equalize whitespace around quotes and make +sure the line following it falls on a valid baseline. On occasion, +you may need to tweak the quote placement slightly, which is done +by passing kbdADJUST/kbd to QUOTE with a plus or minus value. +The quote will be lowered (kbd+/kbd) or raised (kbd-/kbd) +iwithin the space allotted for it/i by the given amount. For +example, to lower a quote slightly within the space allotted for it, +you#8217;d do +br/ +span class=pre-in-pp + .QUOTE ADJUST +3p + There was a soprano named Golda + Whose lovers grew colda and colda + For during love-making + She'd sing the earth-shaking + Love theme from Tristan und Isolde. + .QUOTE off +/span /p div class=defaults-container style=background-color: #ded4bd; border: none; @@ -2242,7 +2242,7 @@ below quotes, invoke /span with no argument. If you wish to restore mom#8217;s default behaviour regarding the spacing of quotes (see -a href=#quote-spacingabove/a), +a href=#quote-spacingQuote spacing/a), invoke the macro with any argument (kbdOFF, QUIT, END, X/kbd...) /p @@ -2309,7 +2309,7 @@ left. Besides indenting blockquotes, mom further sets them off from running text with a small amount of vertical
Re: [Groff] mom bug: ALPHA list
On Sat, Feb 28, 2015, Ellam ByDefault wrote: Given simple input as follows, .PRINTSTYLE TYPESET .START .PP Lorem ipsum. .LIST ALPHA .ITEM one .ITEM two .ITEM three .LIST END mom unexpectedly typeset nr #LIST_INDENT1 21600 appended at the paragraph. I dug in the om.tmac of mom 2.1 and found out there's missing period before nr request at line 15243: . if '\\*[$LIST_ARG_1]'ALPHA' nr #LIST_INDENT\\n[#DEPTH] \ While in mom 2.0-a it's at line 11133: .if '\\*[$LIST_ARG_1]'ALPHA' nr #LIST_INDENT\\n[#DEPTH] \ Putting a period before the nr cures the bug. Tested on groff 1.22.2 with mom 2.0-a and 2.1. Fixed in the repo. Thanks. -- Peter Schaffter http://www.schaffter.ca
[groff] 01/01: Updated scope of _STYLE macros to include headers/footers and page numbers.
PTPi pushed a commit to branch master
in repository groff.
commit bd081b8673168a9cc8d54ec3cc09156f90b4ee74
Author: Peter Schaffter pe...@schaffter.ca
Date: Sat Feb 21 15:02:20 2015 -0500
Updated scope of _STYLE macros to include headers/footers and page numbers.
---
contrib/mom/ChangeLog |5 ++
contrib/mom/om.tmac-u | 100 ++--
2 files changed, 76 insertions(+), 29 deletions(-)
diff --git a/contrib/mom/ChangeLog b/contrib/mom/ChangeLog
index f8f65eb..755e8d3 100644
--- a/contrib/mom/ChangeLog
+++ b/contrib/mom/ChangeLog
@@ -1,3 +1,8 @@
+* Sat Feb 21 2015
+
+ o Expanded scope of _STYLE macros to headers/footers and
+page numbers
+
* Thu Feb 5 2015
o Version 2.1 release (see NEWS)
diff --git a/contrib/mom/om.tmac-u b/contrib/mom/om.tmac-u
index cf6d4f4..b55ba58 100644
--- a/contrib/mom/om.tmac-u
+++ b/contrib/mom/om.tmac-u
@@ -5223,6 +5223,19 @@ y\R'#DESCENDER \\n[.cdp]'
.MAC _STYLE END
.ds $STYLE_TYPE \\$0
.substring $STYLE_TYPE 0 -7
+.ds $HDR_FTR \\*[$STYLE_TYPE]
+.substring $HDR_FTR 0 5 \ HEADER or FOOTER
+.if '\\*[$HDR_FTR]'HEADER' .ds $HDR_FTR HEADER
+.if '\\*[$HDR_FTR]'FOOTER' .ds $HDR_FTR FOOTER
+.ds $POS \\$0
+.substring $POS 7 7
+.if '\\*[$POS]'L' .ds $POS LEFT
+.if '\\*[$POS]'C' .ds $POS CENTER
+.if '\\*[$POS]'R' .ds $POS RIGHT
+.if '\\*[$STYLE_TYPE]'\\*[$HDR_FTR]_\\*[$POS]' \{\
+. ds $\\*[$HDR_FTR]_\\*[$POS] \\*[$HDR_FTR]_\\*[$POS]
+. ds $STYLE_TYPE HDRFTR_\\*[$POS]
+.\}
.if '\\*[$STYLE_TYPE]'ENDNOTES_HEADER' \
. ds $BIB-EN-TOC EN_STRING
.if '\\*[$STYLE_TYPE]'ENDNOTE_STRING' \
@@ -5231,6 +5244,8 @@ y\R'#DESCENDER \\n[.cdp]'
. ds $BIB-EN-TOC BIB_STRING
.if '\\*[$STYLE_TYPE]'TOC_HEADER' \
. ds $BIB-EN-TOC TOC_STRING
+.if '\\*[$STYLE_TYPE]'PAGENUMBER' \
+. ds $STYLE_TYPE PAGENUM
.nr #LOOP 0 1
.nr #STYLE_PARAMS \\n[#NUM_ARGS]
.while \\n+[#LOOP]=\\n[#STYLE_PARAMS] \{\
@@ -5262,10 +5277,14 @@ CAPS takes precedence.
. rr #\\*[$STYLE_TYPE]_SMALLCAPS
. \}
. \\*[$STYLE_TYPE]_CAPS
+. if d $\\*[$HDR_FTR]_LEFT .HEADER_LEFT_CAPS
+. if d $\\*[$HDR_FTR]_CENTER .HEADER_CENTER_CAPS
+. if d $\\*[$HDR_FTR]_CENTRE .HEADER_CENTER_CAPS
+. if d $\\*[$HDR_FTR]_RIGHT .HEADER_RIGHT_CAPS
. shift
. \}
. if '\\$1'NO_CAPS' \{\
-. rr #\\*[$STYLE_TYPE]_CAPS
+. nr #\\*[$STYLE_TYPE]_CAPS 0
. if !'\\*[$BIB-EN-TOC]'' \
. rr #\\*[$BIB-EN-TOC]_CAPS
. shift
@@ -5367,6 +5386,11 @@ SMALLCAPS takes precedence.
.\}
.br
.rm $STYLE_TYPE
+.rm $HDR_FTR
+.rm $POS
+.rm $HEADER_LEFT
+.rm $HEADER_CENTER
+.rm $HEADER_RIGHT
.rm $BIB-EN-TOC
.rm ul-args
.END
@@ -5391,16 +5415,26 @@ SMALLCAPS takes precedence.
.ds STYLE_TYPE_18 ENDNOTE_STRING
.ds STYLE_TYPE_19 EPIGRAPH
.ds STYLE_TYPE_20 FINIS
-.ds STYLE_TYPE_21 LEAD
-.ds STYLE_TYPE_22 LINENUMBER
-.ds STYLE_TYPE_23 MISC
-.ds STYLE_TYPE_24 QUOTE
-.ds STYLE_TYPE_25 SUBTITLE
-.ds STYLE_TYPE_26 TITLE
-.ds STYLE_TYPE_27 TOC_HEADER
+.ds STYLE_TYPE_21 FOOTER_LEFT
+.ds STYLE_TYPE_22 FOOTER_CENTER
+.ds STYLE_TYPE_23 FOOTER_CENTRE
+.ds STYLE_TYPE_24 FOOTER_RIGHT
+.ds STYLE_TYPE_25 HEADER_LEFT
+.ds STYLE_TYPE_26 HEADER_CENTER
+.ds STYLE_TYPE_27 HEADER_CENTRE
+.ds STYLE_TYPE_28 HEADER_RIGHT
+.ds STYLE_TYPE_29 LEAD
+.ds STYLE_TYPE_30 LINENUMBER
+.ds STYLE_TYPE_31 MISC
+.ds STYLE_TYPE_32 QUOTE
+.ds STYLE_TYPE_33 PAGENUMBER
+.ds STYLE_TYPE_34 SUBTITLE
+.ds STYLE_TYPE_35 TITLE
+.ds STYLE_TYPE_36 TOC_HEADER
+.
.
.nr #LOOP 0 1
-.while \n+[#LOOP]=27 \{\
+.while \n+[#LOOP]=36 \{\
. ALIAS \*[STYLE_TYPE_\n[#LOOP]]_STYLE _STYLE
. ALIAS COVER_\*[STYLE_TYPE_\n[#LOOP]]_STYLE _STYLE
. ALIAS DOC_COVER_\*[STYLE_TYPE_\n[#LOOP]]_STYLE _STYLE
@@ -5724,9 +5758,9 @@ SMALLCAPS takes precedence.
. if \\n[#UNDERLINE_QUOTES]=1 .UNDERLINE_QUOTES
. if \\n[#UNDERLINE_QUOTES]=0 .UNDERLINE_QUOTES OFF
. if !\\n[#HDRFTR_PLAIN] \{\
-. if !r #HDRFTR_RIGHT_CAPS .nr #HDRFTR_RIGHT_CAPS 1
-. if \\n[#HDRFTR_RIGHT_CAPS]=0 .ab
-. if !d $HDRFTR_RIGHT_SIZE_CHANGE .HDRFTR_RIGHT_SIZE +0
+. if !r #HDRFTR_RIGHT_CAPS .nr #HDRFTR_RIGHT_CAPS 1
+. if \\n[#HDRFTR_RIGHT_CAPS]=0 \
+. if !d $HDRFTR_RIGHT_SIZE_CHANGE .HDRFTR_RIGHT_SIZE +0
. \}
.\ +Doctype underlining (if NAMED)
. if !r #DOCTYPE_UNDERLINE .nr #DOCTYPE_UNDERLINE 1
@@ -6002,14 +6036,16 @@ SMALLCAPS takes precedence.
. if !d $HDRFTR_RIGHT_FAM \
. HDRFTR_RIGHT_FAMILY \\*[$DOC_FAM]
. if !d $HDRFTR_RIGHT_FT .HDRFTR_RIGHT_FONT R
-. if !r #HDRFTR_RIGHT_CAPS \{\
+. ie !r #HDRFTR_RIGHT_CAPS \{\
. nr #HDRFTR_RIGHT_CAPS 1
. if !d $HDRFTR_RIGHT_SIZE_CHANGE \
.HDRFTR_RIGHT_SIZE -2
. \}
-. if \\n
[groff] 01/01: Doc fixes; removed superfluous annotation from om.tmac-u
PTPi pushed a commit to branch master in repository groff. commit 8c992eb1444da538c47f023c10f2d7d2f5b60e56 Author: Peter Schaffter pe...@schaffter.ca Date: Sun Feb 15 18:29:19 2015 -0500 Doc fixes; removed superfluous annotation from om.tmac-u --- contrib/mom/momdoc/rectoverso.html |4 ++-- contrib/mom/momdoc/refer.html |4 ++-- contrib/mom/om.tmac-u |1 - 3 files changed, 4 insertions(+), 5 deletions(-) diff --git a/contrib/mom/momdoc/rectoverso.html b/contrib/mom/momdoc/rectoverso.html index 4e83a6f..6877952 100644 --- a/contrib/mom/momdoc/rectoverso.html +++ b/contrib/mom/momdoc/rectoverso.html @@ -291,14 +291,14 @@ after the last line of text, before kbd.COLLATE/kbd and/or any concluding macros. For example, br/ span class=pre-in-pp - some concluding text. + some concluding text.\c .EL .COLLATE /span or br/ span class=pre-in-pp - some concluding text. + some concluding text.\c .EL .LIST OFF .COLLATE diff --git a/contrib/mom/momdoc/refer.html b/contrib/mom/momdoc/refer.html index 9f43db5..05ba1a6 100644 --- a/contrib/mom/momdoc/refer.html +++ b/contrib/mom/momdoc/refer.html @@ -794,7 +794,7 @@ are very few rules, and those there are make sense. In a nutshell: %N journal number ndash; journal or magazine number %R report numberndash; technical report number %G gov#8217;t. ndash; government ordering number -a class=quick href=#O%O/a otherndash; information or which there is no appropriate +a class=quick href=#O%O/a otherndash; information for which there is no appropriate field letter a class=quick href=#C%C/a city ndash; city of publication %I publisherndash; publisher @@ -1008,7 +1008,7 @@ publication data is desired, include it in the field, like this: %A Kazuo Ishiguro %T The Remains of the Day %d London: Faber, 1989 - %D New York + %C New York %I Knopf %D 1990 /span diff --git a/contrib/mom/om.tmac-u b/contrib/mom/om.tmac-u index 2514c99..cf6d4f4 100644 --- a/contrib/mom/om.tmac-u +++ b/contrib/mom/om.tmac-u @@ -1,5 +1,4 @@ .\ -*- nroff -*- om.tmac -.\ This one's temp, part of attempt to deal with blockquote indents. .ig Mom -- a typesetting/document-processing macro set for groff. ___ Groff-commit mailing list Groff-commit@gnu.org https://lists.gnu.org/mailman/listinfo/groff-commit
[groff] 01/01: Fixes broken HEADER/FOOTER_PLAIN
PTPi pushed a commit to branch master
in repository groff.
commit db2b877959cc3c09f2190fbf36f72118102ae07a
Author: Peter Schaffter pe...@schaffter.ca
Date: Sat Feb 14 17:31:18 2015 -0500
Fixes broken HEADER/FOOTER_PLAIN
---
contrib/mom/BUGS |7 +
contrib/mom/om.tmac-u | 72 -
2 files changed, 54 insertions(+), 25 deletions(-)
diff --git a/contrib/mom/BUGS b/contrib/mom/BUGS
index 86c66b6..3412e74 100644
--- a/contrib/mom/BUGS
+++ b/contrib/mom/BUGS
@@ -22,7 +22,14 @@ Also, please--no html email. That, too, gets nuked.
+Version 2.1
+===
+
+HEADER_PLAIN and FOOTER_PLAIN broken.
+---Fixed---
+
Version 2.0-c_1
+===
.TS with no H causing FN_OVERFLOW warning when there are footnotes
on same page.
diff --git a/contrib/mom/om.tmac-u b/contrib/mom/om.tmac-u
index 8cec0d5..2514c99 100644
--- a/contrib/mom/om.tmac-u
+++ b/contrib/mom/om.tmac-u
@@ -5605,9 +5605,6 @@ SMALLCAPS takes precedence.
. if \\n[#PAGE_NUM_HYPHENS]=1 .PAGENUM_HYPHENS
.\}
.el .PAGENUM_HYPHENS
-.if !r #HDRFTR_RIGHT_CAPS .nr #HDRFTR_RIGHT_CAPS 1
-.if \\n[#HDRFTR_RIGHT_CAPS]=0 \
-. if !d $HDRFTR_RIGHT_SIZE_CHANGE .HDRFTR_RIGHT_SIZE +0
.if !d $FN_FAM .FOOTNOTE_FAMILY \\*[$DOC_FAM]
.if !d $FN_FT .FOOTNOTE_FONT R
.if !d $FN_QUAD.FOOTNOTE_QUAD \\*[$DOC_QUAD]
@@ -5727,6 +5724,11 @@ SMALLCAPS takes precedence.
. SS DEFAULT
. if \\n[#UNDERLINE_QUOTES]=1 .UNDERLINE_QUOTES
. if \\n[#UNDERLINE_QUOTES]=0 .UNDERLINE_QUOTES OFF
+. if !\\n[#HDRFTR_PLAIN] \{\
+. if !r #HDRFTR_RIGHT_CAPS .nr #HDRFTR_RIGHT_CAPS 1
+. if \\n[#HDRFTR_RIGHT_CAPS]=0 .ab
+. if !d $HDRFTR_RIGHT_SIZE_CHANGE .HDRFTR_RIGHT_SIZE +0
+. \}
.\ +Doctype underlining (if NAMED)
. if !r #DOCTYPE_UNDERLINE .nr #DOCTYPE_UNDERLINE 1
.\ +Quotes and blockquotes
@@ -5980,31 +5982,50 @@ SMALLCAPS takes precedence.
. if !d $DOCTYPE_FT .DOCTYPE_FONT BI
. if !d $DOCTYPE_SIZE_CHANGE .DOCTYPE_SIZE +3
.\ +Headers and footers
-. if !d $HDRFTR_LEFT_FAM .HDRFTR_LEFT_FAMILY \\*[$DOC_FAM]
-. if !d $HDRFTR_LEFT_FT .HDRFTR_LEFT_FONT R
-. if \\n[#HDRFTR_LEFT_CAPS] \
-. if !d $HDRFTR_LEFT_SIZE_CHANGE .HDRFTR_LEFT_SIZE -2
-. if !d $HDRFTR_LEFT_SIZE_CHANGE .HDRFTR_LEFT_SIZE -.5
-. if !d $HDRFTR_CENTER_FAM.HDRFTR_CENTER_FAMILY \\*[$DOC_FAM]
-. if !d $HDRFTR_CENTER_FT .HDRFTR_CENTER_FONT I
-. if \\n[#HDRFTR_CENTER_CAPS] \
-. if !d $HDRFTR_CENTER_SIZE_CHANGE .HDRFTR_CENTER_SIZE -2
-. if !d $HDRFTR_CENTER_SIZE_CHANGE.HDRFTR_CENTER_SIZE -.5
-. if !d $HDRFTR_RIGHT_FAM .HDRFTR_RIGHT_FAMILY \\*[$DOC_FAM]
-. if !d $HDRFTR_RIGHT_FT .HDRFTR_RIGHT_FONT R
-. ie !\\n[#HDRFTR_RIGHT_SMALLCAPS] \{\
-. if \\n[#HDRFTR_RIGHT_CAPS] \
-. if !d $HDRFTR_RIGHT_SIZE_CHANGE .HDRFTR_RIGHT_SIZE -2
-. \}
-. el \{\
-. nr #SKIP_CAPS_SMALLCAPS_WARNING 1
-. if \\n[#HDRFTR_RIGHT_CAPS] .HDRFTR_RIGHT_CAPS OFF
-. \}
-. if !d $HDRFTR_RIGHT_SIZE_CHANGE .HDRFTR_RIGHT_SIZE -.5
+. if !\\n[#HDRFTR_PLAIN] \{\
+. if !d $HDRFTR_LEFT_FAM \
+. HDRFTR_LEFT_FAMILY \\*[$DOC_FAM]
+. if !d $HDRFTR_LEFT_FT \
+. HDRFTR_LEFT_FONT R
+. if \\n[#HDRFTR_LEFT_CAPS] \
+. if !d $HDRFTR_LEFT_SIZE_CHANGE \
+.HDRFTR_LEFT_SIZE -2
+. if !d $HDRFTR_LEFT_SIZE_CHANGE \
+. HDRFTR_LEFT_SIZE -.5
+. if !d $HDRFTR_CENTER_FAM \
+. HDRFTR_CENTER_FAMILY \\*[$DOC_FAM]
+. if !d $HDRFTR_CENTER_FT .HDRFTR_CENTER_FONT I
+. if \\n[#HDRFTR_CENTER_CAPS] \
+. if !d $HDRFTR_CENTER_SIZE_CHANGE \
+.HDRFTR_CENTER_SIZE -2
+. if !d $HDRFTR_CENTER_SIZE_CHANGE \
+. HDRFTR_CENTER_SIZE -.5
+. if !d $HDRFTR_RIGHT_FAM \
+. HDRFTR_RIGHT_FAMILY \\*[$DOC_FAM]
+. if !d $HDRFTR_RIGHT_FT .HDRFTR_RIGHT_FONT R
+. if !r #HDRFTR_RIGHT_CAPS \{\
+. nr #HDRFTR_RIGHT_CAPS 1
+. if !d $HDRFTR_RIGHT_SIZE_CHANGE \
+.HDRFTR_RIGHT_SIZE -2
+. \}
+. if \\n[#HDRFTR_RIGHT_CAPS]=0 \
+. if !d $HDRFTR_RIGHT_SIZE_CHANGE \
+.HDRFTR_RIGHT_SIZE -.5
+. ie !\\n[#HDRFTR_RIGHT_SMALLCAPS] \{\
+. if \\n[#HDRFTR_RIGHT_CAPS] \
+.if !d $HDRFTR_RIGHT_SIZE_CHANGE \
+. HDRFTR_RIGHT_SIZE -2
+. \}
+. el \{\
+. nr #SKIP_CAPS_SMALLCAPS_WARNING 1
+. if \\n[#HDRFTR_RIGHT_CAPS] .HDRFTR_RIGHT_CAPS OFF
+. \}
+. if !d $HDRFTR_RIGHT_SIZE_CHANGE .HDRFTR_RIGHT_SIZE -.5
+. \}
.\ +Quotes
Re: [Groff] redefining symbols on a per-font basis
On 2/12/15, Werner LEMBERG w...@gnu.org wrote: In case you want to follow Bringhurst everywhere, I guess you have to define a `.paren' macro anyways because `\,' and `\/' have no effect within a `.char' definition, IIRC. With the mom macros, there's no need to define a macro because of the '\,' '\/' problem. The following works in .char definitions: .char ( (\*[FU1]\fP .char ) \fR\*[FU1])\fP 'FU' stands for Forward Units, and is used, along with 'BU' (Back Units), for kerning on-the-fly between any pair of characters. 1 Unit=1/36m by default, but can be changed to any fraction you like. Thus, it's suitable for making the italic correction in definitions such as the one above. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Blast from the past
On Wed, Feb 11, 2015, Larry Kollar wrote: The spacing comment reminds me of when I was using nroff in 1983. We had a NEC daisy-wheel printer that could do arbitrary motions, at least horizontally. I cobbled an nroff “driver” (a compiled struct, IIRC) to even out the word spacing. Still Courier, though. We had a Times-like wheel, and I had made a start on a driver for it when the job dried up. I probably would have had some issues with underlining. Given the thread we had going a while back about underlining and other text decorations, I'm inclined to say: Plus ça change... -- Peter Schaffter http://www.schaffter.ca
[Groff] Blast from the past
Groffers -- I don't see any mention of this in the list archives, and it's too wonderful to miss. If you want a glimpse of days gone by, have a look at http://www.dtic.mil/dtic/tr/fulltext/u2/751318.pdf -- Peter Schaffter http://www.schaffter.ca
[groff] 04/04: Version 2.1 updates
PTPi pushed a commit to branch master in repository groff. commit 191cf2c02f66e415a290ecad61ea606fbe86b37e Author: Peter Schaffter pe...@schaffter.ca Date: Thu Feb 5 15:20:44 2015 -0500 Version 2.1 updates --- contrib/mom/momdoc/appendices.html |2 +- contrib/mom/momdoc/color.html |2 +- contrib/mom/momdoc/cover.html | 714 ++-- contrib/mom/momdoc/definitions.html|2 +- contrib/mom/momdoc/docelement.html | 289 +++- contrib/mom/momdoc/docprocessing.html | 610 ++-- contrib/mom/momdoc/goodies.html| 19 +- contrib/mom/momdoc/graphical.html |2 +- contrib/mom/momdoc/headfootpage.html |2 +- contrib/mom/momdoc/images.html |4 +- contrib/mom/momdoc/inlines.html|2 +- contrib/mom/momdoc/intro.html |2 +- contrib/mom/momdoc/letters.html|2 +- contrib/mom/momdoc/macrolist.html | 35 ++- contrib/mom/momdoc/rectoverso.html |7 +- contrib/mom/momdoc/refer.html |5 +- contrib/mom/momdoc/reserved.html |2 +- contrib/mom/momdoc/stylesheet.css | 13 +- contrib/mom/momdoc/tables-of-contents.html | 109 + contrib/mom/momdoc/toc.html|6 +- contrib/mom/momdoc/typesetting.html| 114 +- contrib/mom/momdoc/using.html |2 +- contrib/mom/momdoc/version-2.html | 56 ++- 23 files changed, 1159 insertions(+), 842 deletions(-) diff --git a/contrib/mom/momdoc/appendices.html b/contrib/mom/momdoc/appendices.html index 32a9ce4..d8b5b9c 100644 --- a/contrib/mom/momdoc/appendices.html +++ b/contrib/mom/momdoc/appendices.html @@ -2,7 +2,7 @@ !-- This file is part of groff, the GNU roff type-setting system. -Copyright (C) 2004-2014 Free Software Foundation, Inc. +Copyright (C) 2004-2015 Free Software Foundation, Inc. Written by Peter Schaffter (pe...@schaffter.ca). Permission is granted to copy, distribute and/or modify this document diff --git a/contrib/mom/momdoc/color.html b/contrib/mom/momdoc/color.html index e447110..8bd8eb4 100644 --- a/contrib/mom/momdoc/color.html +++ b/contrib/mom/momdoc/color.html @@ -2,7 +2,7 @@ !-- This file is part of groff, the GNU roff type-setting system. -Copyright (C) 2004-2014 Free Software Foundation, Inc. +Copyright (C) 2004-2015 Free Software Foundation, Inc. Written by Peter Schaffter (pe...@schaffter.ca). Permission is granted to copy, distribute and/or modify this document diff --git a/contrib/mom/momdoc/cover.html b/contrib/mom/momdoc/cover.html index 3b49df8..ec62913 100644 --- a/contrib/mom/momdoc/cover.html +++ b/contrib/mom/momdoc/cover.html @@ -2,7 +2,7 @@ !-- This file is part of groff, the GNU roff type-setting system. -Copyright (C) 2004-2014 Free Software Foundation, Inc. +Copyright (C) 2004-2015 Free Software Foundation, Inc. Written by Peter Schaffter (pe...@schaffter.ca). Permission is granted to copy, distribute and/or modify this document @@ -40,28 +40,42 @@ FDL in the main directory of the groff source package. h1 class=docsCreating cover pages/h1 -div style=width: 63%; margin: auto; +div style=width: 66%; margin: auto; ul class=no-enumerator lia href=#cover-introIntroduction to cover pages/a ul style=margin-left: -.5em; list-style-type: disc; lia href=#important-noteImportant note/a/li lia href=#descDescription of cover pages/a/li -lia href=#paginationHeaders/footers/pagination and cover pages/a/li +lia href=#paginationHeaders/footers/pagination/a + ul style=margin-left: -1.25em; list-style-type: circle; +lia href=#paginationDOC_COVERS_COUNT_PAGES/a/li +lia href=#paginationCOVERS_COUNT_PAGES/a/li + /ul +/li lia href=#designDesigning your own cover pages/a/li +lia href=#persistencePersistence of data and formatting/a/li /ul/li - lia href=#index-coversCover and document cover macros/a + lia href=#index-coversDoc-cover and cover macros/a ul style=margin-left: -.5em; list-style-type: disc; -lia href=#coverCOVER / DOC_COVER/a -ul style=margin-left: -.5em; list-style-type: circle; - lia href=#required-argThe required argument/a/li +lia href=#coverDOC_COVER / COVER/a +ul style=margin-left: -1.25em; list-style-type: circle; + lia href=#cover-argsThe argument list: saying what goes on doc-cover and cover pages/a/li + lia href=#meaningsWhat the arguments mean/a/li lia href=#chapterHow the CHAPTER argument and friends work/a/li - lia href=#optional-argsThe optional arguments/a/li - lia href=#doctypeWhat the DOCTYPE argument means/a/li - lia href=#blankpageWhat the BLANKPAGE argument means/a/li /ul/li +lia href=#covertextDOC_COVERTEXT / COVERTEXT/a + ul style=margin-left: -1.25em; list-style-type: circle; +lia href=#placementPlacement/a/li + /ul
[groff] 03/04: Small alterations incorporating version 2.1 changes
PTPi pushed a commit to branch master in repository groff. commit f3df08a2a55f38b2552a92bba1ac97caaf003d4f Author: Peter Schaffter pe...@schaffter.ca Date: Thu Feb 5 15:18:57 2015 -0500 Small alterations incorporating version 2.1 changes --- contrib/mom/examples/README-fr.txt |2 +- contrib/mom/examples/README.txt |4 +- contrib/mom/examples/letter.mom |2 +- contrib/mom/examples/mom-pdf.mom | 109 +-- contrib/mom/examples/mon_premier_doc.mom |5 +- contrib/mom/examples/sample_docs.mom | 225 +- contrib/mom/examples/typesetting.mom |2 +- 7 files changed, 238 insertions(+), 111 deletions(-) diff --git a/contrib/mom/examples/README-fr.txt b/contrib/mom/examples/README-fr.txt index 0cbbc27..c5573f9 100644 --- a/contrib/mom/examples/README-fr.txt +++ b/contrib/mom/examples/README-fr.txt @@ -19,7 +19,7 @@ Je n'ai pas inclu les PDF parce que je voulais conserver l'archive mom aussi petite que possible. Pour générer les PDF, traitez les fichiers avec pdfmom(1). -pdfmom letter.mom letter.pdf +pdfmom -k letter.mom letter.pdf pdfmom mom-pdf.mom mom-pdf.pdf pdfmom -k mon_premier_doc.mom mon_premier_doc.pdf pdfmom sample_docs.mom sample_docs.pdf diff --git a/contrib/mom/examples/README.txt b/contrib/mom/examples/README.txt index 2892f5f..e4fefb1 100644 --- a/contrib/mom/examples/README.txt +++ b/contrib/mom/examples/README.txt @@ -1,5 +1,5 @@ -*- text -*- -Copyright (C) 2004-2014 Free Software Foundation, Inc. +Copyright (C) 2004-2015 Free Software Foundation, Inc. Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright @@ -18,7 +18,7 @@ I haven't included the PDF output because I want to keep the mom archive as lean as possible. To view the PDF output, process the files with pdfmom(1). -pdfmom letter.mom letter.pdf +pdfmom -k letter.mom letter.pdf pdfmom mom-pdf.mom mom-pdf.pdf pdfmom -k mon_premier_doc.mom mon_premier_doc.pdf pdfmom sample_docs.mom sample_docs.pdf diff --git a/contrib/mom/examples/letter.mom b/contrib/mom/examples/letter.mom index a6e19b6..5be8674 100644 --- a/contrib/mom/examples/letter.mom +++ b/contrib/mom/examples/letter.mom @@ -1,6 +1,6 @@ .\ -*- mode: troff; coding: utf-8; -*- . -\# Copyright (C) 2004-2014 Free Software Foundation, Inc. +\# Copyright (C) 2004-2015 Free Software Foundation, Inc. \# \# Copying and distribution of this file, with or without modification, \# are permitted in any medium without royalty provided the copyright diff --git a/contrib/mom/examples/mom-pdf.mom b/contrib/mom/examples/mom-pdf.mom index 72610df..b972c69 100644 --- a/contrib/mom/examples/mom-pdf.mom +++ b/contrib/mom/examples/mom-pdf.mom @@ -1,5 +1,5 @@ .\ -*- nroff -*- -.\ Copyright (C) 2012-2014 Free Software Foundation, Inc. +.\ Copyright (C) 2012-2015 Free Software Foundation, Inc. .\ .\ This file is part of mom, which is part of groff, a free software .\ project. @@ -8,68 +8,92 @@ .\ GNU General Public License as published by the Free Software \ Foundation, version\~2. .\ -.\ The license text is available in the internet at +.\ The license text is available on the internet at .\ http://www.gnu.org/licenses/gpl-2.0.html .\ -.PAPER A4 +.PAPER A4 .\ Reference macros (metadata) .TITLE Producing PDFs with groff and mom .PDF_TITLE \*[$TITLE] -.AUTHOR\v'-.5v'\*[UP 4p]Deri James \ - \v'-.5v'\*[UP 8p]and \ - \v'-.5v'\*[UP 11p]Peter Schaffter -.MISC This file is part of groff. \ - .sp .25v \ - groff is free software; you can redistribute it \ - and\*[FU3]/or modify it under the terms of the GNU \ - General Public License as published by the \ - Free Software Foundation, either version 3 \ - of the License, or (at your option) any later \ - version. \ - .sp .25v \ - You should have received a copy of the GNU \ - General Public License along with this program. \ - If not, see: \ - .sp .25v \ - .IL 2P \ - .PDF_WWW_LINK http://www.gnu.org/licenses/; \ - .IQ CLEAR -.COPYRIGHT 20\*[BU3]1\*[BU2]2 Free Software Foundation +.COPYRIGHT 20\*[BU3]1\*[BU2]5 Free Software Foundation +.AUTHOR Deri James \*[UP .5p]and Peter Schaffter +.\ Cover author style +.COVER_AUTHOR_STYLE \ + LEAD 15 \ + SPACE -.5v +.\ Docheader author style +.AUTHOR_STYLE \ + LEAD 14 \ + SPACE -.75 .ATTRIBUTE_STRING \ Don't print 'by' +.\ .PDF_BOOKMARKS_OPEN 2 -.\ Cover and page header -.COVER TITLE AUTHOR COPYRIGHT MISC -.HEADER_LEFT James, Schaffter -.\ Page, style, formatting +.\ Formatting style, margins .PRINTSTYLE TYPESET .L_MARGIN 2.5c .R_MARGIN 2.5c .B_MARGIN 2.5c -.\ +.\ General defaults .FAM H .FT R .PT_SIZE 10.5
Re: [Groff] Proper Small Caps.
Tadziu -- On Mon, Jan 19, 2015, Tadziu Hoffmann wrote: Which raises the point, does anyone know of a way to extract just the small caps from an OpenType font that has them? Not sure if this is really helpful, but since I have not yet arrived in the OpenType era I use cfftot1 to convert OpenType fonts to Type 1 and then simply use different font encoding vectors to display text either with upper and lower case letters or with caps and small caps. (The conversion preserves the exact letter shapes, but you lose the fancy OpenType code that does all those funky character replacements for you, so you must do that manually.) Interesting. Thanks. I'll look into this. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Proper Small Caps.
Tadziu -- On Mon, Jan 19, 2015, Tadziu Hoffmann wrote: I'm fond of smallcaps, but I don't like the faked version, not even the OpenType smallcaps. Whenever possible, I always advise getting a designer-cut smallcaps font. I don't understand. Aren't the small caps of OpenType fonts that support this feature supposed to be real, designer-cut small caps? Like those in the expert sets of traditional Type-1 fonts, but additionally with matching punctuation etc.? I think you are right. My confusion comes from statements like this: InDesign: Small Caps: This command, which can be accessed from the Character panel, will convert only the lowercase in selected text to small caps – either to true-drawn versions that are available with some OpenType fonts, or to fake, scaled-down ones for fonts that don't have the real thing. [fonts.com] This is actually a statement about how InDesign handles small caps, not a statement about OpenType small caps management. A tad misleading. Thanks for pointing out my error. Which raises the point, does anyone know of a way to extract just the small caps from an OpenType font that has them? -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Proper Small Caps.
On Sun, Jan 18, 2015, Ralph Corderoy wrote: Hi, http://2d.laboratorium.net/post/108351875900/small-caps-big-problem complains about small caps from Word, etc., compared with small caps designed by the designer. I'm fond of smallcaps, but I don't like the faked version, not even the OpenType smallcaps. Whenever possible, I always advise getting a designer-cut smallcaps font. That said, and against my better judgment, I'm adding .SMALLCAPS to mom in the next release (within a couple of weeks). It's similar to Ted's macro, but allows for changing the size of smallcaps (as a user-settable percentage of the current point size) as well as their weight (by fattening them a user-settable percentage of their point size). -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Introduction to groff in french
Grégoire -- On Thu, Jan 15, 2015, Grégoire Babey wrote: I wrote a second version for the introducion to groff in french. I splitted general presentation https://doc.ubuntu-fr.org/groff and user tutorial https://doc.ubuntu-fr.org/groff_tuto The tutorial link gives Cette page n'existe pas encore. Also, I've modified the end of 2. Installation slightly. -- Peter Schaffter http://www.schaffter.ca
[groff] 01/01: Fixed typos
PTPi pushed a commit to branch master in repository groff. commit 71b653a6fe6b7f42e6894bf4bf681c2f9dfa7f66 Author: Peter Schaffter pe...@schaffter.ca Date: Fri Jan 16 13:59:15 2015 -0500 Fixed typos --- contrib/mom/examples/README-fr.txt |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/mom/examples/README-fr.txt b/contrib/mom/examples/README-fr.txt index 2182cf7..0cbbc27 100644 --- a/contrib/mom/examples/README-fr.txt +++ b/contrib/mom/examples/README-fr.txt @@ -55,7 +55,7 @@ fonctionnalités PDF de mom dont l'écriture d'une ébauche de nouvelle ou des liens cliquables dans une table des matières. Le dernier exemple démontre, par un texte séparé en deux colonnes, la -souplesse de mom pour la coneption de document. +souplesse de mom pour la conception de document. Le PRINTSTYLE de ce fichier est TYPESET et vous donne une idée du comportement par défaut de mom pour la composition typographique de @@ -68,7 +68,7 @@ début du fichier. ***letter.mom*** -Ceci est simplement l'exemple du turorial de momdocs, prêt à être vu. +Ceci est simplement l'exemple du tutorial de momdocs, prêt à être vu. ***mon_premier_doc.mom*** ___ Groff-commit mailing list Groff-commit@gnu.org https://lists.gnu.org/mailman/listinfo/groff-commit
Re: [Groff] Introduction to groff in french
Bertrand -- On Sat, Dec 13, 2014, Bertrand Garrigues wrote: - Added my example mon_premier_doc.mom in contrib/mom/examples and modified contrib/mom/Makefile.sub accordingly (attached my diff against master). The result after building is: - In build/contrib/mom/examples, mon_premier_doc.pdf is not correctly built. - All others .pdf files are correctly built, including letter.pdf, which has some French accented glyphs. - Then, if I install groff and generate either mon_premier_doc.pdf or letter.pdf with pdfmom -k both are correctly generated. The -k option is necessary to these 2 files. - However, if I use LC_ALL=C pdfmom -k (LC_ALL=C is passed during the build of all mom examples) letter.pdf is still correctly generated, but not mon_premier_doc.pdf. Adding .\ -*- mode: troff; coding: utf-8; -*- to the top of mon_premier_doc.mom should fix the problem. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Introduction to groff in french
Bertrand -- On Thu, Dec 11, 2014, Bertrand Garrigues wrote: I was about to commit my example, however I ran into a problem. When I generate the pdf with pdfmom -k, I have a few can't translate character code 233 to special character `'e' in transparent throughput errors but the output is fine. This is a known by-product of pdfmom/gropdf. The message can safely be ignored. However, the .mom files in contrib/mom/examples are generated with LC_ALL=C; this causes more can't translate character code[...] errors and this time the output is incorrect (é and è letters are not correctly displayed). The latest versions of the .mom files in examples/ should build without this error. They do at my end, anyway. Update your examples/ files, and let me know if the problem persists. Attached my original .mom file. Nice demonstration of mom usage. Builds fine. -- Peter Schaffter http://www.schaffter.ca
[groff] 02/02: Fix brace mismatches in FLOAT and PDF_IMAGE
PTPi pushed a commit to branch master
in repository groff.
commit 6b4e68f57d44213fc1bf53d7087f007868fc97b5
Author: Peter Schaffter pe...@schaffter.ca
Date: Mon Dec 8 18:43:30 2014 -0500
Fix brace mismatches in FLOAT and PDF_IMAGE
---
contrib/mom/om.tmac | 25 +++--
1 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/contrib/mom/om.tmac b/contrib/mom/om.tmac
index 83d0128..dd6d527 100644
--- a/contrib/mom/om.tmac
+++ b/contrib/mom/om.tmac
@@ -422,8 +422,10 @@ end
\#
.MAC DO_B_MARGIN END
.nr #T_MARGIN_LEAD_ADJ \\n[#LEAD]-12000
+.if !\\n[#DOCS] .vpt 0
.ev B_MARGIN
'sp |\\n[.p]u
+.if !\\n[#DOCS] .vpt
.if !n .nop \X'ps: exec 0 setlinejoin'\X'ps: exec 0 setlinecap'
.ev
.END
@@ -11743,7 +11745,7 @@ $DOC_COVER_TITLE_\\n+[#DOC_COVER_TITLE_NUM]
\\$\\n[#DOC_COVER_TITLE_NUM]
.ie \\n[#ENDNOTE] .ALD \\n[#EN_LEAD]u
.el .ALD \\n[#DOC_LEAD]u
. \}
-. el .SHIM
+. el .ALD \\n[#DOC_LEAD]u/2u
. ie \\n[#Q_FITS] \{\
.ie (\\n[#Q_TOP]=\\n[#PAGE_TOP]):(\\n[@TOP]=1) \{\
. nr #Q_AT_TOP 1
@@ -16290,8 +16292,8 @@ E\\R'#CAP_HEIGHT \\n[.cht]'
. vpt
.\}
.if \\n[#NUM_ARGS]0 \{\
-.nr loop-count 0 1
-.nr loop-counter \\n[#NUM_ARGS]
+. nr loop-count 0 1
+. nr loop-counter \\n[#NUM_ARGS]
. while \\n+[loop-count]=\\n[loop-counter] \{\
. if '\\$1'FORCE' \{\
. nr #FORCE 1
@@ -16378,15 +16380,16 @@ E\\R'#CAP_HEIGHT \\n[.cht]'
. rr @TOP
. \}
. nf
-. if \\n[float*tbl] \
+. if \\n[float*tbl] \{\
. if (\\n[#MLA]=1)(\\n[tbl@source]=0) \
. chop FLOAT*DIV
. if \\n[nl]=\\n[#PAGE_TOP] \{\
. if \\n[tbl*have-caption] \{\
.ie !\\n[#MLA] .sp \\n[tbl*caption-lead-diff]u
.el \{\
-.ch RR_@TOP
-.sp \\n[tbl*label-lead-diff]u-.5v
+. ch RR_@TOP
+. sp \\n[tbl*label-lead-diff]u-.5v
+.\}
. \}
. \}
. \}
@@ -21126,10 +21129,12 @@ Macro MN: Warning: Right margin note #\\n[MN-curr] on
page \\n[#P] shifted down.
. nr float*no-shim 1
. \}
.\}
-.ds pdf-img*label-sffx-tmp \\*[pdf-img*label-sffx]
-.substring pdf-img*label-sffx-tmp -1
-.if '\\*[pdf-img*label-sffx-tmp]'.' \
-. if \\n[pdf-img*caption-after-label]=0 .chop pdf-img*label-sffx
+.if !'\\*[pdf-img*label-sffx]'' \{\
+. ds pdf-img*label-sffx-tmp \\*[pdf-img*label-sffx]
+. substring pdf-img*label-sffx-tmp -1
+. if '\\*[pdf-img*label-sffx-tmp]'.' \
+. if \\n[pdf-img*caption-after-label]=0 .chop pdf-img*label-sffx
+.\}
.PDF_TARGET fig:\\n+[lists*target]
.if '\\*[pdf-img:pos]'-C' \
. nr pdf-img:ind (\\n[.ll]-\\n[ind-pre-img]-\\n[pdf-img:width])/2
___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit
[groff] 01/01: Updated section on quote spacing to reflect new policy when shimming is disabled.
PTPi pushed a commit to branch master in repository groff. commit e8883ed8c1fc4b7933055c2c550700d279b488e4 Author: Peter Schaffter pe...@schaffter.ca Date: Fri Dec 5 13:28:06 2014 -0500 Updated section on quote spacing to reflect new policy when shimming is disabled. --- contrib/mom/momdoc/docelement.html | 19 +++ 1 files changed, 15 insertions(+), 4 deletions(-) diff --git a/contrib/mom/momdoc/docelement.html b/contrib/mom/momdoc/docelement.html index d34c585..6203964 100644 --- a/contrib/mom/momdoc/docelement.html +++ b/contrib/mom/momdoc/docelement.html @@ -1987,8 +1987,8 @@ which, by and large, processes text on a line-per-line basis.) p If you don#8217;t want the behaviour described above (ie you -don#8217;t want mom shimming -quotes and blockquotes), issue the macro +don#8217;t want mom shimming quotes and blockquotes), issue the +macro br/ span class=pre-in-pp .NO_SHIM @@ -1999,6 +1999,17 @@ per-instance basis prior to kbd.QUOTE/kbd or kbd.BLOCKQUOTE/kbd. /p p +If you set the leading of +a href=#quote-autoleadquotes/a +or +a href=#blockquote-autoleadblockquotes/a +to a value other than the one used in paragraphs, mom will apply +shimming iafter/i the quote, whether or not kbd.NO_SHIM/kbd +is enabled. This is the only way mom can guarantee that the +difference in leading will not result in uneven bottom margins. +/p + +p If you#8217;ve disabled shimming of quotes and blockquotes with kbd.NO_SHIM/kbd and you want mom to return to her default behaviour in this matter, invoke kbd.NO_SHIMnbsp;OFF/kbd (or @@ -2094,7 +2105,7 @@ See .QUOTE_FAMILY default = prevailing document family; default is Times Roman .QUOTE_FONT default = italic; underlined in TYPEWRITE .QUOTE_SIZE default = +0 (ie same size as paragraph text) -.QUOTE_AUTOLEAD default = none; leading of quotes is the same as paragraphs +a id=quote-autolead.QUOTE_AUTOLEAD default = none; leading of quotes is the same as paragraphs /a .QUOTE_COLORdefault = black .QUOTE_INDENT (see below, Quote indent) /span @@ -2286,7 +2297,7 @@ See .BLOCKQUOTE_FAMILY default = prevailing document family; default is Times Roman .BLOCKQUOTE_FONT default = roman .BLOCKQUOTE_SIZE default = -1 (point) -.BLOCKQUOTE_AUTOLEAD default = none; leading of blockquotes is the same as paragraphs +a id=blockquote-autolead.BLOCKQUOTE_AUTOLEAD default = none; leading of blockquotes is the same as paragraphs/a .BLOCKQUOTE_COLORdefault = black .BLOCKQUOTE_QUAD default = left .BLOCKQUOTE_INDENT (see below) ___ Groff-commit mailing list Groff-commit@gnu.org https://lists.gnu.org/mailman/listinfo/groff-commit
[groff] 01/01: Documentation updates for 2.0-c_2
PTPi pushed a commit to branch master in repository groff. commit fd15172aa52e2a515b118eca35a6d794bb5a1284 Author: Peter Schaffter pe...@schaffter.ca Date: Sun Nov 30 19:10:13 2014 -0500 Documentation updates for 2.0-c_2 --- contrib/mom/momdoc/docelement.html | 156 +++- contrib/mom/momdoc/macrolist.html |2 +- contrib/mom/momdoc/tables-of-contents.html | 116 - contrib/mom/momdoc/toc.html|5 +- 4 files changed, 225 insertions(+), 54 deletions(-) diff --git a/contrib/mom/momdoc/docelement.html b/contrib/mom/momdoc/docelement.html index 090352e..d34c585 100644 --- a/contrib/mom/momdoc/docelement.html +++ b/contrib/mom/momdoc/docelement.html @@ -469,11 +469,24 @@ or div class=box-tip p class=tip -span class=tipTip:/span +span class=tipTips on vertical spacing around epigraphs:/span +If you wish to change the vertical position of an epigraph with +a href=typesetting.html#spaceSPACE/a/ +a href=typesetting.html#aldALD/a/ +a href=typesetting.html#rldRLD/a, +do so before invoking kbd.EPIGRAPH/kbd, like this: +br/ +span class=pre-in-pp + .SP -6p + .EPIGRAPH + A notable quote. + .EPIGRAPH OFF +/span If you#8217;re setting a document in a href=docprocessing.html#columnscolumns/a -and you#8217;d like to add or subtract space after the epigraph, -the place to do it is inside the epigraph, like this: +and you#8217;d like to add or subtract space iafter/i the +epigraph, which is centered over the top of both columns, the place +to do it is inside the epigraph, like this: br/ span class=pre-in-pp .EPIGRAPH @@ -1927,6 +1940,31 @@ This behaviour can be changed with the control macro /p div class=box-tip +p class=tip +span class=tipTips on vertical spacing around quotes:/span +If you wish to adjust the spacing before or after a quote or blockquote +manually (with +a href=typesetting.html#spaceSPACE/a/ +a href=typesetting.html#aldALD/a/ +a href=typesetting.html#rldRLD/a), +do so ioutside/i the kbd.QUOTE/kbd or kbd.BLOCKQUOTE/kbd, +like this: +br/ +span class=pre-in-pp + .SP -3p + .QUOTE + Candy is dandy + But liquor is quicker. + .QUOTE OFF + .SP -3p +/span +/p +/div + + + + +div class=box-tip h2 id=quote-spacing-notes class=docs style=padding-top: 9px; font-size: 100%;Further notes on quote spacing/h2 p clasdefaults @@ -4711,13 +4749,13 @@ appearance of endnotes pages, set them up prior to lia href=#endnotes-hdrftr-centerHeader/footer centre string when doctype is CHAPTER/a/li lia href=#endnotes-allows-headersAllow headers on endnotes pages/a/li /ul/li - lia href=#endnotes-main-titlebEndnotes' first-page title control/b/a + lia href=#endnotes-headerbEndnotes header (first-page title) control/b/a ul style=margin-left: -.5em; -lia href=#endnote-stringTitle string/a/li -lia href=#endnote-string-controlTitle string control macros and defaults/a/li -lia href=#endnote-string-placementTitle string placement/a/li -lia href=#endnote-string-underlineTitle string underscoring/a/li -lia href=#endnote-string-capsTitle string capitalization/a/li +lia href=#endnotes-header-stringHeader string/a/li +lia href=#endnotes-header-string-controlHeader string control macros and defaults/a/li +lia href=#endnotes-header-placementHeader string placement/a/li +lia href=#endnotes-header-underscoreHeader string underscoring/a/li +lia href=#endnotes-header-capsHeader string capitalization/a/li /ul/li lia href=#endnotes-doc-titlebEndnotes document-identification string control/b/a ul style=margin-left: -.5em; @@ -5200,30 +5238,34 @@ ENDNOTES_ALLOWS_FOOTERS OFF. /p /div -h4 id=endnotes-main-title class=docs4. Endnotes' first-page title control/h4 +h4 id=endnotes-header class=docs4. Endnotes header (first-page title) control/h4 -!-- -ENDNOTE_STRING- -- +!-- -ENDNOTES_HEADER_STRING- -- -h5 id=endnote-string class=docs style=margin-top: 1em; margin-bottom: .5em; margin-left: .5em;bull;nbsp;Title string/h5 +h5 id=endnotes-header-string class=docs style=margin-top: 1em; margin-bottom: .5em; margin-left: .5em;bull;nbsp;Header (first-page title) string/h5 div class=box-macro-args -Macro: bENDNOTE_STRING/b kbd class=macro-argsquot;lt;head to print at the top of endnotesgt;quot;/kbd +Macro: bENDNOTES_HEADER_STRING/b kbd class=macro-argsquot;lt;title to print at the top of endnotesgt;quot;/kbd /div +p class=alias style=margin-bottom: 0; +iAlias:/i bENDNOTE_STRING/b (for compatibility with older documents) +/p + p By default, mom prints the word #8220;ENDNOTES#8221; as a head at the top of the first page of endnotes. If you want her to -print something else, invoke kbd.ENDNOTE_STRING/kbd with the -endnotes-page head you want, surrounded by double-quotes. If you -don#8217;t want a head at the top of the first endnotes-page, -invoke kbd.ENDNOTE_STRING/kbd with a blank argument (either two -double-quotes side by sidemdash;kbdquot;quot
Re: [Groff] [mom] Error with footnote and table
Bertrand -- On Sat, Nov 29, 2014, Bertrand Garrigues wrote: I have a document (using Mom package) that I generated without problem with the 1.22.2 tarball, but when I used up-to-date groff I encountered an obscure error. I've wrote a minimal, simpler doc (attached, test.mom) to reproduce the problem. It seems to me the error occurs when I put a .FOOTNOTE and a table on the same page. This is now fixed in the repo and the latest tarball on the mom homepage. FWIW, get into the habit of passing the BOXED and CENTER args to .TS when your tables are boxed and centered with tbl(1) flags. It isn't necessary all the time, but it takes care of some spacing/indenting/quadding issues that crop up with TS, and it does no harm to include them. Equally, I usually suggest users pass the 'H' arg to TS, à la ms(1). Thanks for catching this bug. In fixing it, I found another. :) -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Introduction to groff in french
Bertrand -- On Sun, Nov 30, 2014, Bertrand Garrigues wrote: If I have a paragraph starting just after a HEADING, and I use the defaut behaviour (no indentation of the first paragraph), is it the same thing to add or omit .PP before this first paragraph just after a HEADING? Isn't .PP useless as I don't want to indent the pragraph? Always use .PP to start a paragraph, including initial paras after headings. Partly, it's for semantic clarity. Also, if you omit the .PP after .HEADING 1, the first time you use .PP afterwards will result in a non-indented paragraph since mom indents only second and subsequent paragraphs. Second question, is it a recommended style not to indent the first paragraph, at least in English typesetting? Yes. I've noticed that most of the English books I have don't indent the first paragraph while most of the French books do so, although it's not always the case. Whether or not to indent first paragraphs can be turned on and off with .INDENT_FIRST_PARAS. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Introduction to groff in french
Bertrand -- On Thu, Nov 27, 2014, Bertrand Garrigues wrote: Thanks for your remarks, I will correct my example and commit it. I have a tendency to add a blank line before or after a HEADING for clarity pupose in the source file, but this add an extra blank line. I guess the recommandation is to simply add a comment with \#? The simplest ways to add blank lines to input without affecting output are to put a period on a line by itself, or define a dummy macro for .blm so you you use real blank lines. .de dummy .. .blm dummy You can use comment lines, too. Also, I found out that in the mom examples, sometimes .PP is added right after a HEADING, sometimes no. What is the general rule? Not sure I understand. There's no general rule. If what comes after HEADING is a paragraph, then PP comes right after the heading (with as many blank or comment lines as you like in between--assuming, if blank lines, you've added the above to your file). -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] condition: OR of two string comparisons
On Sun, Nov 23, 2014, Ralph Corderoy wrote: I'm fed up pointing out in different emails this is about having some of those new mom-using users step across into troff: So I'm going to step into the breach. The input language is the main criticism of roff today... The *roff language has had a reputation for being thorny since the dawn of time(2). Remember the last entry of the UNIX Expertise Hierarchy? Wizard: - writes device drivers with “cat ” - fixes bugs by patching the binaries - posts his changes to Unix utilities to the net – and they work - can tell what question you are about to ask, and answer it = - writes his own troff macro packages = - is on a first-name basis with Dennis, Bill, and Ken I posit that *roff's über-geekiness nearly resulted in its death as a player in UNIX typesetting even after James Clark released the GNU implementation in 1990. Aside from the conceptual difficulties presented by *roff generally (page transitions, end-of-file handling, copy-in mode, interaction of '.di' with running text, etc) and the terse, sometimes idiosyncractic requests (e.g. absolute spacing that doesn't move from the top edge of the page), the *roff language has only the most simplistic of programming constructs. Until '.while' got added, there were only '.if' and '.ie/.el'. Conditional testing of numeric values requires an almost childish literalness; conditional testing of strings is restricted to one-offs. That it is possible to write complex macros with groff's limited programming constructs does not mean the language wouldn't benefit from some extensions and enhancements. The chief reason for adding them would be to bring groff into line with contemporary programming expectations *so as to encourage development by programmers raised with those expectations.* I am merely paraphrasing Ralph, here. If we're to have them step beyond the friendly macro package into doing a bit of troff, getting involved, helping keep interest going, perhaps specialised macros or preprocessors, or adding troff backends to other tools, then a nicer syntax for control flow and expressions would lower the hurdle. ... (by users who use LaTeX or GUI tools). Their argument vanishes with a comfortable macro package. That is true. It's the reason for the mom macros. In my estimation, groff, as a complete typesetting system, is far, far too good to be a wizards-only tool. That [i.e. a comfortable macro package, ed.] can hide nearly anything from the complicated low level language. So MOM is the interface to new users, not the .if statement. The key words, above, are nearly anything. Nearly. Effective use of any macro package, including -mom, benefits from at least some knowledge of the low-level language. It's a point made repeatedly in the document Groff and mom: an overview http://www.gnu.org/software/groff/groff-and-mom.pdf Therefore, I cannot agree that '.if' is not part of the interface when -mom is being used. I believe the sentence is better phrased: So MOM is a good introduction for new users. All this to support Ralph's position. A nicer syntax for control flow and expressions would not only make it easier (dare I say more intuitive?) for users dipping into '.if' for the first time, it would be good for the health of groff. Speaking as a macro writer, I very much prefer the idea of a flag, in the manner of compatibility mode, for extended conditional testing, rather then '.iff' and friends as has been fielded. It leaves the 'if' request name and syntax alone, preserves backward compatibility, and allows for easy insertion of '.if' with extended conditional testing into existing macro packages. I see such a flag as being analogous to grep(1)'s -E option. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] condition: OR of two string comparisons
On Fri, Nov 21, 2014, Ralph Corderoy wrote: Oh, I think a basic .if is still useful to the novice who will probably want to conditionally do something, e.g. DRAFT heading, etc. Does mom aim to remove the need for any non-mom-macro command, e.g. `.ds company Google, Inc.'? No, not at all. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] condition: OR of two string comparisons
Ralph -- On Fri, Nov 21, 2014, Ralph Corderoy wrote: But new users to troff, and I think Peter's Mom can attract them, At 90, I'm sure my mom will be thrilled to hear you think so. :) -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Introduction to groff in french
Bertrand -- On Wed, Nov 19, 2014, Bertrand Garrigues wrote: So I've written a very simple example with Mom in French with a step-by-step explanation on Ubuntu's French documentation page. Could I commit it into contrib/mom/examples so that I could refer to this file in the Ubuntu article? Go for it. Couple of small changes, though. In your code demonstrating HEADING, I'd remove the blank lines. Also add a PP before the first Lorem ipsum (...). In the para describing HEADING, you say ...HEADING indique un titre de chapître... which isn't entirely accurate. It would be better to say ...HEADING indique un titre de section, suivi par le niveau du titre (1 pour les sections principales, 2 pour les sous-sections, 3 pour les sous-sous-sections)... or words to that effect. Chapter titles are handled by the CHAPTER_TITLE macro. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] [Heirloom] Double word space after :
On Fri, Nov 14, 2014, Mike Bianchi wrote: It seems ease of reading or better comprehension (which are the reasons I prefer extra space after sentences, etc.) have nothing to do with the rules. Sigh. I wouldn't say nothing, but the issue of spacing between sentences is tricky and hard to pin down with a rule or algorithm. The choice of typeface plays an important role. Overall, Didone typefaces don't benefit from sentence spacing. For example, the contrast between thick and thin in Bodoni creates a rhythm that becomes choppy when sentence spacing is introduced. On the other hand, the readability of humanist typefaces like Garamond is improved by discreet pauses in the flow of text. The matter gets more complicated when you have sentences that end with r. or y.. The period should be kerned back, which can result in visibly uneven sentence spacing. Same goes for sentences that begin with T or W or Y. Without some manual adjustment, the space between sentences appears larger than the prevailing norm. BTW--something I've never figured out is whether it's possible to set up kern pairs in groff font files that have space as the first element of the pair. I pipe my files through sed(1) to catch space-W, space-T, etc and kern them, but it would be great to have these pairs included in the kerning tables. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] [Heirloom] Double word space after :
On Fri, Nov 14, 2014, Dale Snell wrote: But I am wondering if the publishing houses are hiring professionals anymore. Pretty much, no, at least here in Canada. To be expected now that typesetter, as a recognized trade, is dead. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] [Heirloom] Double word space after :
On Wed, Nov 12, 2014, Carsten Kunze wrote: Hello, by default Heirloom troff inserts a double word space if a line ends with :. Is this correct US English typography? For typeset copy with proportionally-spaced fonts, no. For monospaced fonts (terminal), yes, but only if sentences are separated by two wordspaces as well. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] PDF_IMAGE and MOM
On Mon, Nov 03, 2014, Dale Snell wrote: BTW, out of my 'satiable curiosity, is mom being used by other *roffs, or is it strictly Groff? Strictly groff since it relies the GNU extensions. It could probably be adapted for other roffs, but I haven't had the time to explore the situation. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] PDF_IMAGE and MOM
On Mon, Nov 03, 2014, Dale Snell wrote: On Mon, 03 Nov 2014 16:36:04 + Ralph Corderoy ra...@inputplus.co.uk wrote: BTW, your mombog.mom had a blank line at the start and the comments were lines starting `\#' rather than `.\#'. One or the other might have an affect on your attempt at A3 in mom, I don't know. \# is a _groff_ comment, not mom's. Mom shouldn't care. If she does, she needs to be chastised, but I think she's safe. She is. :) As for the blank line at the top of the file, I don't think mom cares. She doesn't. -- Peter Schaffter http://www.schaffter.ca
[groff] 01/01: Makefile.sub: added KFLAG to run pdfmom with -k flag
PTPi pushed a commit to branch master in repository groff. commit 43e7a6096544c4f48ea56e042696d9567db4378b Author: Peter Schaffter pe...@schaffter.ca Date: Wed Oct 29 14:56:53 2014 -0400 Makefile.sub: added KFLAG to run pdfmom with -k flag Set utf-8 preconv coding tag in examples/typesetting.mom and examples/letter.mom --- contrib/mom/ChangeLog| 11 +-- contrib/mom/Makefile.sub |3 ++- contrib/mom/examples/letter.mom |2 ++ contrib/mom/examples/typesetting.mom |2 ++ 4 files changed, 15 insertions(+), 3 deletions(-) diff --git a/contrib/mom/ChangeLog b/contrib/mom/ChangeLog index be8fdd9..f185371 100644 --- a/contrib/mom/ChangeLog +++ b/contrib/mom/ChangeLog @@ -1,13 +1,20 @@ +* Wed Oct 29 2014 + + o Makefile.sub: KFLAG to run pdfmom with -k + + o Set utf-8 preconv coding tag in examples/typesetting.mom and + examples/letter.mom + * Mon Oct 20 2014 - o Changes to caption/label/source quadding strategy. + o Changes to caption/label/source quadding strategy. * Wed Sep 03 2014 Bernd Warken groff-bernd.warken...@web.de o all files in contrib/mom source: Copying and Emacs setting. o contrib/mom source/ChangeLog: Repair file. The file runs now in - Emacs change-log mode. + Emacs change-log mode. * Tue Aug 12 2014 diff --git a/contrib/mom/Makefile.sub b/contrib/mom/Makefile.sub index 020fc9f..5109333 100644 --- a/contrib/mom/Makefile.sub +++ b/contrib/mom/Makefile.sub @@ -30,6 +30,7 @@ groff_bin_dirs=\ FFLAG=-F$(top_builddir)/font -F$(top_srcdir)/font TFLAG=-M$(top_builddir)/tmac -M$(top_srcdir)/tmac -M$(srcdir) +KFLAG=-k GROFF=\ GROFF_COMMAND_PREFIX= \ @@ -40,7 +41,7 @@ PDFMOM=\ GROFF_COMMAND_PREFIX= \ GROFF_BIN_PATH=$(GROFF_BIN_PATH) \ PDFMOM_BIN_PATH=$(top_builddir)/src/devices/gropdf \ - $(PDFMOMBIN) $(FFLAG) $(TFLAG) + $(PDFMOMBIN) $(FFLAG) $(TFLAG) $(KFLAG) MAN7=\ groff_mom.n diff --git a/contrib/mom/examples/letter.mom b/contrib/mom/examples/letter.mom index ac83e61..a6e19b6 100644 --- a/contrib/mom/examples/letter.mom +++ b/contrib/mom/examples/letter.mom @@ -1,3 +1,5 @@ +.\ -*- mode: troff; coding: utf-8; -*- +. \# Copyright (C) 2004-2014 Free Software Foundation, Inc. \# \# Copying and distribution of this file, with or without modification, diff --git a/contrib/mom/examples/typesetting.mom b/contrib/mom/examples/typesetting.mom index b006083..2c497bd 100644 --- a/contrib/mom/examples/typesetting.mom +++ b/contrib/mom/examples/typesetting.mom @@ -1,3 +1,5 @@ +.\ -*- mode: troff; coding: utf-8; -*- +. \# Copyright (C) 2004-2014 Free Software Foundation, Inc. \# \# Copying and distribution of this file, with or without modification, ___ Groff-commit mailing list Groff-commit@gnu.org https://lists.gnu.org/mailman/listinfo/groff-commit
Re: [Groff] Introduction to groff in french
Salut, Gregoire ! On Tue, Oct 21, 2014, GregExp wrote: Hi groffies, I wrote a short introduction in french, hoping to allow people who are non-geeks to start using groff. https://doc.ubuntu-fr.org/groff I am thankful for any feedback. Good work. It's always a tough job summarizing groff. Here are a couple of things I noticed: Section 2, Installation : The last paragraph reads: C'est en l'utilisant en ligne de commande avec ses options que vous pourrez vérifier que l'installation a eu lieu. This isn't the best way to verify package installation from the command line. I recommend inserting a bit of code into your article for checking whether groff is installed: dpkg -l | sed -n '/groff[^-]/p' Section 3, Groff pas à pas : The word logiciel at the end of the first paragraph has a superfluous hyphen. Section 3.1, Le terminal : After the little poem entered using printf, you say: Au lieu de .ps, vous pouvez demander un autre format.: .pdf, .html ou .dvi This could be misleading. Users might think all that's required for alternative formats is to save the file to a different extension. You should probably mention the -T flag (-Tpdf, -Thtml, -Tdvi) in conjunction with saving to alternate formats. Section 3.2, L'éditeur du texte : I wouldn't recommend users switch to a virtual console (Ctl-Alt-F1) for testing groff at the terminal. Rather, just instruct them to fire up a terminal window. This becomes important when later you say: L'aperçu gxditview (par l'option -X) ne fonctionne évidemment pas en console. Le seul moyen de voir votre fichier de sortie est donc de l'imprimer. While the statement is true, it's misleading; if the user is in a terminal window, s/he can perfectly well use gxditview. Section 4, subsection Polices, sub-subsection Changer de familles de polices : Pour retourner à la police par défaut entrez .ft p. That should be .ft P (P majuscule). Also, I'd have been inclined to be a bit more precise in the section, introducing '.fam' as the way to change families, and '.ft' as the way to change fonts, adding that '.ft' can also be used to change *both*, e.g. '.ft HR'. Section 5.4, -mom The French Linux Gazette translation (first ici link) contains a broken link to mom's old homepage. Not much that can be done about that without contacting the page's author. The ici link in Pour apprendre à travailler vraiment avec -mom points to http://www.schaffter.ca/mom-03.html whereas mom-04.html makes more sense. Also, there's a good document on groff and -mom that's appropriate for your target audience at http://www.schaffter.ca/shared/groff-and-mom.pdf Section 10, Groff l'ent There's a space after the l' in the section title: l' ent. Same thing in the third paragraph: n' apparaissant. Generally, I wouldn't spend so much space on piping text at the command line through to groff (your poem, e.g.). It's a lot to wade through before getting to the important stuff, creating a groff file in a text editor, which accounts for 99% of real-world usage. Again, good work. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Introduction to groff in french
Gregoire -- On Tue, Oct 21, 2014, GregExp wrote: I could take the chapter 3.1 (terminal)and 3.2 (éditeur de texte en console) after the chapter 3.3 (wich describe the normal using of groff) of even at the very end, after chapter 7, as special using of groff. That's probably the best way to deal with it. From my own experience of leading people through groff for the first time, I always begin with: Step one, fire up a text editor. The basic learning flow is: - fire up a text editor (doesn't matter if it's a console or GUI interface) - demonstrate basic groff usage with some simple text - introduce command line and options - process the demonstration -- Peter Schaffter http://www.schaffter.ca
[groff] 01/01: Doc updates to reflect changes in 2.0-c_1.
PTPi pushed a commit to branch master in repository groff. commit 83b356011af6aebdde77b2bf0568f8e107afb216 Author: Peter Schaffter pe...@schaffter.ca Date: Mon Oct 20 12:55:20 2014 -0400 Doc updates to reflect changes in 2.0-c_1. --- contrib/mom/momdoc/docelement.html | 27 +++ contrib/mom/momdoc/images.html | 128 +++ contrib/mom/momdoc/toc.html | 22 +++--- contrib/mom/momdoc/typesetting.html |6 ++- 4 files changed, 97 insertions(+), 86 deletions(-) diff --git a/contrib/mom/momdoc/docelement.html b/contrib/mom/momdoc/docelement.html index 4e79421..090352e 100644 --- a/contrib/mom/momdoc/docelement.html +++ b/contrib/mom/momdoc/docelement.html @@ -1981,6 +1981,33 @@ quotes on the same page are all spaced identically. /p /div +h3 id=float-quote class=docsKeeping QUOTEs and BLOCKQUOTEs together as a block/h3 + +p +The text of quotes and blockquotes is output immediately, and may therefore +start on one page and finish on the next. If you wish to keep the +text together as a block, deferred to the following page if the +block doesn#8217;t all fit on one page, wrap +(BLOCK)QUOTEnbsp;/nbsp;(BLOCK)QUOTEnbsp;OFF +inside a +a href=images.html#floats-introfloat/a. If you further wish to +force a page break before the floated quote or blockquote (leaving +whitespace at the bottom of the page, pass +a href=images.html#floatFLOAT/a +the kbdFORCE/kbd argument. +span class=pre-in-pp + .FLOAT FORCE + .QUOTE + Fly me to the moon + And let me play among the stars + Let me see what life is like + On Jupiter and Mars + .QUOTE END + .FLOAT OFF +/span + +/p + !-- -QUOTE- -- div class=macro-id-overline diff --git a/contrib/mom/momdoc/images.html b/contrib/mom/momdoc/images.html index 0b3a9cb..fdff0c0 100644 --- a/contrib/mom/momdoc/images.html +++ b/contrib/mom/momdoc/images.html @@ -937,7 +937,7 @@ in any order, although it is advisable to put kbdCAPTION/kbd, kbdSHORT_CAPTION/kbd, and/or kbdLABEL/kbd last. /p -h5 class=docs style=margin-top: 1em; text-transform: none'H'/h5 +h5 id=h class=docs style=margin-top: 1em; text-transform: none'H'/h5 p With the bH/b argument, a table will span as many pages as @@ -1078,6 +1078,13 @@ in The text of the caption must be surrounded by double-quotes. /p +p +Please note that if your table has a caption, you must invoke +kbdTS/kbd with the kbdH/kbd flag, which also entails the use +of +a href=#thTH/a. +/p + h5 class=docs style=margin-top: 1em; text-transform: none'SHORT_CAPTION'/h5 p @@ -1105,12 +1112,26 @@ which, if enabled, overrides the kbdLABEL/kbd argument. The bTH/b macro (bT/bable bH/beader), which is required when you begin a table with kbd.TS H/kbd, allows you to determine what goes in a table#8217;s running header if it spans -multiple pages. If you place it immediately underneath your -kbdtbl/kbd formatting specifications, the last line of which -always ends with a period (see kbdtbl(1)/kbd), there will -be no running header. If you place it under the first row of -kbdtbl/kbd data, the first row will form the header; under the -second row, the first and second rows form the header, and so on. +multiple pages. Placing kbd.TH/kbd under the first row of +kbdtbl/kbd data makes the first row the header. If placed under +the second row, the first and second rows form the header, and so +on. +/p + +p +As there are sometimes reasons to run kbd.TS H/kbd when +you don#8217;t, in fact, want a running header (e.g. when +your table has a caption), you can suppress it by placing +kbd.TH/kbd immediately underneath your kbdtbl/kbd formatting +specifications, the last line of which always ends with a period +(see kbdtbl(1)/kbd)./p +/p + +p +See the +kbda href=#hH/a/kbd +argument to kbd.TS/kbd for examples demonstrating kbd.TH/kbd +placement. /p div class=macro-id-overline @@ -1390,7 +1411,7 @@ required) br/ nbsp;nbsp;[ LABEL lt;labelgt; ] br/ -nbsp;nbsp;[ LABEL_ADJUST +|-lt;vertical adjustmentgt; ] +nbsp;nbsp;[ SHIFT_LABEL +|-lt;vertical adjustmentgt; ] br/ nbsp;nbsp;[ SHORT_CAPTION lt;short captiongt; ] br/ @@ -1495,14 +1516,14 @@ Equations. Mom provides an auto-labelling facility for equations (see which, if enabled, overrides the kbdLABEL/kbd argument. /p -h5 class=docs style=margin-top: 1em; text-transform: none'LABEL_ADJUST'/h5 +h5 class=docs style=margin-top: 1em; text-transform: none'SHIFT_LABEL'/h5 p -kbdLABEL_ADJUST/kbd allows you to raise (kbd-/kbd) or lower +kbdSHIFT_LABEL/kbd allows you to raise (kbd-/kbd) or lower (kbd+/kbd) the equation label. It#8217;s primary use is to center equation labels vertically on the equation rather than flush with the last line. Assuming a three-line equation, -kbd.EQnbsp;LABEL_ADJUSTnbsp;-1v/kbd would raise the label by +kbd.EQnbsp;SHIFT_LABELnbsp;-1v/kbd would raise the label by one line, thus centering it vertically on the equation. /p @@ -1629,27 +1650,27 @@ pdf images as #8220;Fig. lt;ngt;#8221
[groff] 01/01: Changed file encoding to utf8.
PTPi pushed a commit to branch master in repository groff. commit 5a0d7ecb109c577aaeb48dcf51fcd52701bda5d3 Author: Peter Schaffter pe...@schaffter.ca Date: Mon Oct 20 13:03:50 2014 -0400 Changed file encoding to utf8. --- contrib/mom/examples/letter.mom |6 +++--- contrib/mom/examples/typesetting.mom | 22 +++--- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/contrib/mom/examples/letter.mom b/contrib/mom/examples/letter.mom index 41ad6d2..ac83e61 100644 --- a/contrib/mom/examples/letter.mom +++ b/contrib/mom/examples/letter.mom @@ -11,7 +11,7 @@ .DATE August 25, 2013 .TO -GUILLAUME BARRI�RES +GUILLAUME BARRIÈRES Minidoux Corporation 5000 Pannes Drive Redmond, Virginia @@ -19,10 +19,10 @@ USA .FROM Y.P. GUIQUE 022 Umask Road -St-Sauveur-en-dehors-de-la-mappe, Qu�bec +St-Sauveur-en-dehors-de-la-mappe, Québec CANADA .GREETING -Dear Mr. Barri�res, +Dear Mr. Barrières, .PP It has come to my attention that you have been lobbying the US government to prohibit the use of open source software by diff --git a/contrib/mom/examples/typesetting.mom b/contrib/mom/examples/typesetting.mom index 2305410..b006083 100644 --- a/contrib/mom/examples/typesetting.mom +++ b/contrib/mom/examples/typesetting.mom @@ -80,27 +80,27 @@ and multi-columns \# .TAB 1 \ Notice that this tab gets set line-for-line \*[IT]Peelee Island\ Set italic -\*[PREV]Gew�rztraminer \ Revert to former font (roman) +\*[PREV]Gewürztraminer \ Revert to former font (roman) 2000 (Canada) .MCR \ Return to top of column .TAB 2 \ Call tab 2; in multi-column mode, don't use .TN -Jaune p�le. +Jaune pâle. .MCR .TB 3 \ Notice that from here on, we use the alias TB instead of TAB -Frais, fruit�, ci\%tronn�, ar�mes fortes de lichee et de fruits +Frais, fruité, ci\%tronné, arômes fortes de lichee et de fruits tropicaux. .MCR .TB 4 -Doux, fruit�, bien �quilibr� avec une bonne acidit�. +Doux, fruité, bien équilibré avec une bonne acidité. .MCR .TB 5 -Bon ap�ro. Servir avec des plats +Bon apéro. Servir avec des plats .RW .1 \ Reduce Whitespace between letters to tighten this line indiens ou \%chinois. .RW 0 \ Back to normal spacing between letters .BR -Excellent rapport qualit�/prix. +Excellent rapport qualité/prix. .MCX 8p\ Multi-column mode off; advance an extra 8 points .MCO \ Re-invoke multi-columns for next wine description .TB 1 @@ -110,11 +110,11 @@ Excellent rapport qualit (Uraguay) .MCR .TB 2 -Rubis fonc�, vio\%lac�e, presque opaque. +Rubis foncé, vio\%lacée, presque opaque. .MCR .TB 3 -Belles ar�mes de fruits fonc�s (prunes, cerises noires, cassis). -Odeurs tertiares de cuir, c�dre, violets, eucalyptus, avec une trace +Belles arômes de fruits foncés (prunes, cerises noires, cassis). +Odeurs tertiares de cuir, cèdre, violets, eucalyptus, avec une trace exotique de Band-Aid*\*[BU 12]. \# \# The \*[BU 12], above, pulls the period back so that it falls @@ -123,11 +123,11 @@ exotique de Band-Aid*\*[BU 12]. \# .MCR .TB 4 -Tr�s rond, tannins m�res et velout�s, avec un long finis fruit� et +Très rond, tannins mûres et veloutés, avec un long finis fruité et doucement alcoolique. .MCR .TB 5 -Superbe\|! Une aubaine � ne pas manquer. Pr�t � boire maintenant. +Superbe\|! Une aubaine à ne pas manquer. Prêt à boire maintenant. .MCX 1v \ Multi-columns off; advance an extra linespace \# \# Now, an example of a hanging indent. This is excessively fussy ___ Groff-commit mailing list Groff-commit@gnu.org https://lists.gnu.org/mailman/listinfo/groff-commit
[groff] 01/01: Fixes missing page numbers after BLANKPAGE DIVIDER
PTPi pushed a commit to branch master
in repository groff.
commit 791a228815399bef4c2555dbd5d50ec01447d254
Author: Peter Schaffter pe...@schaffter.ca
Date: Tue Oct 21 00:07:45 2014 -0400
Fixes missing page numbers after BLANKPAGE DIVIDER
---
contrib/mom/om.tmac |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/contrib/mom/om.tmac b/contrib/mom/om.tmac
index 905950c..adf1df1 100644
--- a/contrib/mom/om.tmac
+++ b/contrib/mom/om.tmac
@@ -15673,6 +15673,10 @@ E\\R'#CAP_HEIGHT \\n[.cht]'
.rr #COVER
.rr #LAST_LEVEL
.rr #LEVEL
+.if \\n[#RESTORE_PN_V_POS] \{\
+. nr #PAGE_NUM_V_POS \\n[#RESTORE_PN_V_POS]
+. rr #RESTORE_PN_V_POS
+.\}
.END
\#
\# NUMBER_LINES
@@ -15849,6 +15853,7 @@ E\\R'#CAP_HEIGHT \\n[.cht]'
. \}
. if \\n[#PAGE_NUM_V_POS]=2 \{\
. if \\n[#PAGINATE]=1 .nr #PAGINATE_WAS_ON 1
+. nr #RESTORE_PN_V_POS \\n[#PAGE_NUM_V_POS]
. PAGINATION OFF
. \}
. if \\n[#HEADERS_WERE_ON] .HEADERS
@@ -15858,7 +15863,7 @@ E\\R'#CAP_HEIGHT \\n[.cht]'
.shift
.ie '\\$1'DIVIDER' \{\
. if \\n[#FOOTERS_WERE_ON] .FOOTERS
-. if \\n[#PAGE_NUM_V_POS]=2 \{\
+. if \\n[#RESTORE_PN_V_POS]=2 \{\
. if \\n[#PAGINATE_WAS_ON] .nr #RESTORE_PAGINATION 1
. \}
. shift
___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit
[groff] 01/01: Ensure pre-built html (mom) docs are always installed
PTPi pushed a commit to branch master in repository groff. commit e5ab613ed052900138e489207a2d60f482969aa3 Author: Peter Schaffter pe...@schaffter.ca Date: Sun Oct 19 13:12:19 2014 -0400 Ensure pre-built html (mom) docs are always installed --- Makefile.in |6 ++ contrib/mom/Makefile.sub |9 + m4/groff.m4 |9 + 3 files changed, 20 insertions(+), 4 deletions(-) diff --git a/Makefile.in b/Makefile.in index 4dd82ef..16543ae 100644 --- a/Makefile.in +++ b/Makefile.in @@ -282,6 +282,10 @@ make_htmlexamples=@make_htmlexamples@ make_install_htmlexamples=@make_install_htmlexamples@ make_uninstall_htmlexamples=@make_uninstall_htmlexamples@ +# However, there may always be some prebuild HTML documentation +make_install_shipped_htmldoc=@make_install_shipped_htmldoc@ +make_uninstall_shipped_htmldoc=@make_uninstall_shipped_htmldoc@ + # The configure script also checks whether all necessary utility programs # for pdfroff are available -- only then we can build PDF documentation. make_pdfdoc=@make_pdfdoc@ @@ -575,6 +579,8 @@ MDEFINES=\ make_htmlexamples=$(make_htmlexamples) \ make_install_htmlexamples=$(make_install_htmlexamples) \ make_uninstall_htmlexamples=$(make_uninstall_htmlexamples) \ + make_install_shipped_htmldoc=$(make_install_shipped_htmldoc) \ + make_uninstall_shipped_htmldoc=$(make_uninstall_shipped_htmldoc) \ make_pdfdoc=$(make_pdfdoc) \ make_install_pdfdoc=$(make_install_pdfdoc) \ make_uninstall_pdfdoc=$(make_uninstall_pdfdoc) \ diff --git a/contrib/mom/Makefile.sub b/contrib/mom/Makefile.sub index 04fc501..020fc9f 100644 --- a/contrib/mom/Makefile.sub +++ b/contrib/mom/Makefile.sub @@ -134,7 +134,7 @@ examples/stamp: touch $@ install_data: install_always \ - $(make_install_pdfdoc) $(make_install_htmldoc) \ + $(make_install_pdfdoc) $(make_install_shipped_htmldoc) \ $(make_install_examples) install_always: stamp-strip $(NORMALFILES) @@ -151,7 +151,7 @@ install_always: stamp-strip $(NORMALFILES) install_pdfdoc: # Since this uses examples/, it's in install_pdfexamples -install_htmldoc: install_always $(HTMLDOCFILES) +install_shipped_htmldoc: install_always $(HTMLDOCFILES) -test -d $(DESTDIR)$(htmldocdir)/mom \ || $(mkinstalldirs) $(DESTDIR)$(htmldocdir)/mom for f in $(HTMLDOCFILES_); do \ @@ -160,6 +160,7 @@ install_htmldoc: install_always $(HTMLDOCFILES) $(DESTDIR)$(htmldocdir)/mom/$$f; \ done + install_examples: install_examples_always $(make_install_pdfexamples) install_examples_always: $(EXAMPLEFILES) @@ -192,7 +193,7 @@ stamp-strip: $(STRIPFILES) touch $@ uninstall_sub: uninstall_always \ - $(make_uninstall_pdfdoc) $(make_uninstall_htmldoc) \ + $(make_uninstall_pdfdoc) $(make_uninstall_shipped_htmldoc) \ $(make_uninstall_examples) uninstall_always: @@ -203,7 +204,7 @@ uninstall_always: uninstall_pdfdoc: uninstall_always # Since that used examples/, it's in uninstall_pdfexamples -uninstall_htmldoc: uninstall_always +uninstall_shipped_htmldoc: uninstall_always -for f in $(HTMLDOCFILES_); do \ $(RM) $(DESTDIR)$(htmldocdir)/mom/$$f; \ done diff --git a/m4/groff.m4 b/m4/groff.m4 index 502e108..10b93d8 100644 --- a/m4/groff.m4 +++ b/m4/groff.m4 @@ -109,6 +109,13 @@ AC_DEFUN([GROFF_DOC_CHECK], AC_MSG_WARN([Invalid `--with-doc' argument:] $i) done fi + if test $docadd_html = yes; then + make_install_shipped_htmldoc=install_shipped_htmldoc + make_uninstall_shipped_htmldoc=uninstall_shipped_htmldoc + else + make_install_shipped_htmldoc= + make_uninstall_shipped_htmldoc= + fi if test $docadd_other = yes; then make_otherdoc=otherdoc make_install_otherdoc=install_otherdoc @@ -128,6 +135,8 @@ AC_DEFUN([GROFF_DOC_CHECK], make_uninstall_examples= fi AC_SUBST([doc_dist_target_ok]) + AC_SUBST([make_install_shipped_htmldoc]) + AC_SUBST([make_uninstall_shipped_htmldoc]) AC_SUBST([make_otherdoc]) AC_SUBST([make_install_otherdoc]) AC_SUBST([make_uninstall_otherdoc]) ___ Groff-commit mailing list Groff-commit@gnu.org https://lists.gnu.org/mailman/listinfo/groff-commit
[groff] 01/02: Add shipped_htmldoc stuff to configure
PTPi pushed a commit to branch master in repository groff. commit 5c011f038148ae521254057179032e69c7c08217 Author: Peter Schaffter pe...@schaffter.ca Date: Sun Oct 19 17:33:28 2014 -0400 Add shipped_htmldoc stuff to configure --- configure |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/configure b/configure index 80d843d..61adbd6 100755 --- a/configure +++ b/configure @@ -687,6 +687,8 @@ make_examples make_uninstall_otherdoc make_install_otherdoc make_otherdoc +make_uninstall_shipped_htmldoc +make_install_shipped_htmldoc doc_dist_target_ok YACC DVIPRINT @@ -6031,6 +6033,13 @@ fi $as_echo $as_me: WARNING: Invalid \`--with-doc' argument: $i 2;} done fi + if test $docadd_html = yes; then + make_install_shipped_htmldoc=install_shipped_htmldoc + make_uninstall_shipped_htmldoc=uninstall_shipped_htmldoc + else + make_install_shipped_htmldoc= + make_uninstall_shipped_htmldoc= + fi if test $docadd_other = yes; then make_otherdoc=otherdoc make_install_otherdoc=install_otherdoc ___ Groff-commit mailing list Groff-commit@gnu.org https://lists.gnu.org/mailman/listinfo/groff-commit
[groff] 02/02: Merge branch 'master' of git.sv.gnu.org:/srv/git/groff
PTPi pushed a commit to branch master in repository groff. commit c9d541e430521ae86b804befe0c95a285b91deea Merge: 5c011f0 1b5af3c Author: Peter Schaffter pe...@schaffter.ca Date: Sun Oct 19 17:35:19 2014 -0400 Merge branch 'master' of git.sv.gnu.org:/srv/git/groff ChangeLog |7 +++ src/preproc/eqn/lex.cpp |5 + src/preproc/pic/lex.cpp |5 + 3 files changed, 17 insertions(+), 0 deletions(-) ___ Groff-commit mailing list Groff-commit@gnu.org https://lists.gnu.org/mailman/listinfo/groff-commit
Re: [Groff] release ready
On Tue, Oct 14, 2014, Werner Lemberg wrote: Thanks. Now waiting for Peter's last changes – I've also contacted Eli Zaretskii, asking him to retry his Win32 port, which probably needs minor modifications here and there. I'll be pushing the changes to om.tmac and some modified doc files to the repo today (2014-10-19). -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] [groff] 01/02: Add shipped_htmldoc stuff to configure
On Mon, Oct 20, 2014, Ingo Schwarze wrote: Peter already committed the edits to the m4 code earlier, but didn't commit the regeneration right afterwards. Now all is back in sync again. :-) Thanks, Ingo. I was about to take care of this when your email came in. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] release ready
Werner -- On Sat, Oct 11, 2014, Werner Lemberg wrote: After Bernd's commits to fix the IPC issue, I can do `make dist' and distribute it. Before doing this, however, I want to wait a few days so that you can test and check whether everything's fine. Please do so! I working on changes to the mom macros that I'd like to go into the release. Getting close to finishing them. Can you hold off until I commit them? Should be in a day or two. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] HDTBL
Yves -- On Sat, Oct 11, 2014, Yves Cloutier wrote: hmmm, I think this is not compatible with Peter's MOM macros? I've never tested mom with hdtbl. Just having a real hard time doing a really simple table one col table with tbl and thought I would try hdtbl... Mom's implementation of .TS requires you to supply the CENTER and BOXED args to TS if your table is centered and boxed. I imagine that's why you're having trouble with tbl(1), mom, and the input you sent. Original: .TS H center box; Correct: .TS H BOXED CENTER center box; -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] /usr/local/share/doc/groff-1.22.2
Hi. I don't know whether this will have an impact on the discussion in this thread, but here's something I just got today from a FreeBSD user. He wanted to use a testing version of om.tmac I'd sent him. The old version of groff installed as part of the base system, namely version 1.19.2, uses the tmac location of /usr/share/tmac. The newly-installed version of 1.22.2 from ports uses the tmac location of /usr/local/share/groff/1.22.2/tmac, undoubtedly through some PATH settings that are not clear to me. That way each version finds its proper set of macros, and each program functions properly. What I tried to do was stuff om.tmac into the location expected by groff 1.19.2. That is the wrong location. When I put it into the location expected by 1.22.2, it works the way it should. This is not obvious from the ports documentation, so others may get bitten by it as well. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] order of PRINTSTYLE and other requests in mom
Ulrich -- On Sun, Oct 05, 2014, Ulrich Lauther wrote: BTW, there are two typos: will not changes mom’s default paper size to A4, nor her default document leading 14 points, whereas should be will not change mom’s default paper size to A4, nor her default document leading of 14 points, whereas Aha! From this little bit, I discovered that a) you're not reading the most up-to-date documentation, and b) I forgot that the PAPER, PAGEWIDTH, and PAGELENGTH order wrt PRINTSTYLE had already been dealt with in 2.0-b! (Yes, as an exception.) I suggest updating your mom installation from the repo (current mom version is 2.0-c) or grabbing the tarball from the mom site: http://www.schaffter.ca/mom/mom-2.0-c.tar.gz BTW2... .PAPER A4 LANDSCAPE would be convenient. I'll add it to the next release. Cheers. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] order of PRINTSTYLE and other requests in mom
Ulrich -- On Sun, Oct 05, 2014, Ulrich Lauther wrote: On Sun, Oct 05, 2014 at 04:37:40PM -0400, Peter Schaffter wrote: I suggest updating your mom installation from the repo (current mom version is 2.0-c) or grabbing the tarball from the mom site: http://www.schaffter.ca/mom/mom-2.0-c.tar.gz o.k., did it. So the mom version in http://ftp.gnu.org/gnu/groff/groff-1.22.2.tar.gz is outdated. Yes. Groff releases contain the version of mom current at the time of the groff release. Mom undergoes regular updates between releases, which is why tarballs are always available. The mom version in the git repo is always up-to-date, too. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] order of PRINTSTYLE and other requests in mom
Ulrich -- On Sat, Oct 04, 2014, Ulrich Lauther wrote: the mom-docu says: As mentioned above, PRINTSTYLE TYPESET must come before any changes to mom’s default typographic settings. For example, .PAPER A4 .LS 14 .PRINTSTYLE TYPESET will not changes mom’s default paper size to A4, nor her default document leading [to] 14 points, whereas .PRINTSTYLE TYPESET .PAPER A4 .LS 14 will. However, my file .\ mom lnd .PAGEWIDTH842p .PAGELENGTH 595p .PRINTSTYLE TYPESET .PT_SIZE 90 .sp 10c Newly painted! prints Newly painted! in big letters and landscape, as intended. However, if I move the .PAGE* requests down, after .PRINTSTYLE, they are ignored and the output looks like Newly painted! So who is wrong? mom, the docu, or my understanding? A bit of all three, and none of the above. :) PRINTSTYLE sets up a complete, default document template. The defaults are overwritten by any macros that come afterwards, hence the need to put PRINTSTYLE first. PAGEWIDTH and PAGELENGTH establish the dimensions of the printer sheet *and do nothing else*. The left margin remains at whatever value was in effect prior to PAGEWIDTH (groff default 1i), as does the line length. If you give a PAGEWIDTH without also giving a line length (either with R_MARGIN or LL), the line length remains at whatever was in effect prior to invoking PAGEWIDTH. That's what causes your correct order of entry to come out wrong. You need to add, e.g. .R_MARGIN 1i after setting the page width. Alternatively, use PAGE to set up everything at once (page dimensions and margins), e.g. .PAGE 842p 595p 2.5c 2.5c 2.5c 2.5c The reason your wrong order of entering things works is because PRINTSTYLE requires page dimensions in order to set the margins, and uses whatever is in effect. PAGEWIDTH, PAGELENGTH and PAPER can, in fact, come before PRINTSTYLE. However, I'm averse to the word except in documentation, so this is not mentioned. I will, however, update the PAGEWIDTH section to mention the possible need for setting a line length. Final note: In the example you sent, PRINTSTYLE is unnecessary and probably shouldn't be there. PRINTSTYLE is required only for document processing, not straightforward typesetting. Hope this clears things up. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Documentation for -mom
Ingo -- On Fri, Sep 19, 2014, Ingo Schwarze wrote: Given that the build systems disables building HTML documentation when some support software is missing on the target system and that the main mom documentation is (very unfortunately, but that's the current state of affairs) HTML, we end up in a situation where some groff installations do not include full mom documentation. The attached patch to /contrib/mom/Makefile.sub should ensure that mom's documentation gets installed (and uninstalled) regardless of whether support software for building HTML documentation is missing. On Sun, Sep 21, 2014, Peter Schaffter wrote: a lot of mom users would disagree that having the documentation in html is unfortunate. :) Well, what i mean is this. In my tutorial on documentation here in Sofia i'm going to list seven quality criteria for software documentation: 1. correctness 2. completeness 3. conciseness 4. ease of access (both regarding searching and regarding the required tools for viewing it); ideally, all documentation should be in one place so you cannot miss it 5. semantic markup 6. ease of reading; ideally, uniform display markup and style 7. ease of writing; ideally, one simple, standard input language HTML flat-out fails on criteria 4-7. Respectfully disagree with flat-out fails, though not because I'm promoting HTML as a documentation standard. Heaven forbid. 5. Well-formed css/xhtml allows for unambiguous semantic markup. 6. For ease of reading, uniform display and style are only achievable when the display and style are well-thought-out and well-rendered; a manpage at the terminal is decidedly sub-optimal in this regard, as my occasionally blurred vision will attest. :) 7. Agreed. HTML is a PITA. Regarding 4, it's not just that people cannot see it in man(1) where documentation is expected to be, but need to install a browser; on top of that, apropos(1) will be completely blind to it. Regarding 4, you omitted ease of navigation. Searching is one thing, but it doesn't include being able to click on internal links to find out what an unfamiliar term means, or how, in the case of mom, to use a macro that's referenced in the description of another macro's usage. Clickable cross-references, IOW. Some programs aren't suited for manpages, esp. those whose documentation benefits from a table of contents, indices, and extensive cross-linking. Remember the bad old days of FVWM, with its humungous, unindexed, un-cross-linked manpage? It was correct, complete, concise (despite its length), easy to access--and pure, off-putting hell to wade through. GNU tried to solve the navigation problem by foisting texinfo on everybody, but after a couple of decades I, and many others, still find info(1) a trial to use. I'd never suggest that HTML should be a standard for Unix documentation. Manpages are essential. However, when they can't furnish easily-navigable information about a program's usage, some other form of documentation is required. Furthermore, the search-only navigation and in-a-nutshell style of manpages can actually have the effect of discouraging program usage if the program is large and complex. What good is documentation that turns people off using a program, or leaves them scratching their heads saying, I'll never make sense of all this? In instances where a manpage is clearly the wrong format for documentation, I believe, as was for so long the case with mom, that a manpage stub pointing to the complete documentation in another format is the way to go since it prevents apropos(1) blindness and tells users correctly, completely, and concisely what they need to know, namely go here for the documentation. As for installing a browser, e.g. w3m(1), is that any more trouble than installing less(1) in order to browse manpages? -- Peter Schaffter http://www.schaffter.ca diff --git a/contrib/mom/Makefile.sub b/contrib/mom/Makefile.sub index 04fc501..6afc2c1 100644 --- a/contrib/mom/Makefile.sub +++ b/contrib/mom/Makefile.sub @@ -139,6 +139,7 @@ install_data: install_always \ install_always: stamp-strip $(NORMALFILES) -test -d $(DESTDIR)$(tmacdir) || $(mkinstalldirs) $(DESTDIR)$(tmacdir) + -test -d $(DESTDIR)$(htmldocdir)/mom || $(mkinstalldirs) $(DESTDIR)$(htmldocdir)/mom for f in $(NORMALFILES); do \ $(RM) $(DESTDIR)$(tmacdir)/$$f; \ $(INSTALL_DATA) $(srcdir)/$$f $(DESTDIR)$(tmacdir)/$$f; \ @@ -147,6 +148,11 @@ install_always: stamp-strip $(NORMALFILES) $(RM) $(DESTDIR)$(tmacdir)/$$f; \ $(INSTALL_DATA) $$f-s $(DESTDIR)$(tmacdir)/$$f; \ done + for f in $(HTMLDOCFILES); do \ + $(RM) $(DESTDIR)$(htmldocdir)/mom/$$f; \ + cp $$f \ + $(DESTDIR)$(htmldocdir)/mom/; \ + done install_pdfdoc: # Since this uses examples/, it's in install_pdfexamples @@ -199,7 +205,12 @@ uninstall_always: -for f in $(NORMALFILES
[groff] 01/01: Fixed ENDNOTES page offset conflict with BLOCKQUOTE.
PTPi pushed a commit to branch master
in repository groff.
commit 7e5d69ea8c7952bdb7e75c6933b954caa898af34
Author: Peter Schaffter pe...@schaffter.ca
Date: Mon Sep 22 12:05:56 2014 -0400
Fixed ENDNOTES page offset conflict with BLOCKQUOTE.
---
contrib/mom/BUGS|6 +-
contrib/mom/om.tmac | 10 +-
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/contrib/mom/BUGS b/contrib/mom/BUGS
index ff2c196..c8e9738 100644
--- a/contrib/mom/BUGS
+++ b/contrib/mom/BUGS
@@ -1,5 +1,5 @@
-*- text -*-
-Copyright (C) 2004-2014 Free Software Foundation, Inc.
+Copyright 2004-2014 Free Software Foundation, Inc.
Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
@@ -25,6 +25,10 @@ Also, please--no html email. That, too, gets nuked.
Version 2.0-c
=
+Endnotes page offset wrong if (BLOCK)QUOTE last macro before
+ENDNOTES.
+---Fixed---
+
Character translation of diacritics from lowercase to caps broken.
---Fixed---
diff --git a/contrib/mom/om.tmac b/contrib/mom/om.tmac
index 9566072..57dd1b7 100644
--- a/contrib/mom/om.tmac
+++ b/contrib/mom/om.tmac
@@ -582,16 +582,16 @@ end
. if '\\n[.sty]'' \{\
. if !F\\n[.fn] \{\
. if !S\\*[$FONT] \{\
-.tm1 [mom]: Font style \\*[$FONT] at line \\n[.c] has not
been registered.\
+.tm1 [mom]: Font style \\*[$FONT] at line \\n[.c] has not
been registered.
.ie \\n[#ABORT_FT_ERRORS]=0 \
-. tm1Continuing to process using fallback font.\
+. tm1Continuing to process using fallback font.
.el .ab Aborting '\\n[.F]' at \\$0, line \\n[.c].
. \}
. if \\n[.f]=0 \{\
.tm1 [mom]: Either font style \\*[$FONT] at line \\n[.c]
does not exist in family \\n[.fam],
.tm1or family \\n[.fam] has not been installed.
.ie \\n[#ABORT_FT_ERRORS]=0 \
-. tm1Continuing to process using fallback font.\
+. tm1Continuing to process using fallback font.
.el .ab Aborting '\\n[.F]' at \\$0, line \\n[.c].
. \}
. \}
@@ -7327,7 +7327,6 @@ $DOC_COVER_TITLE_\\n+[#DOC_COVER_TITLE_NUM]
\\$\\n[#DOC_COVER_TITLE_NUM]
. rm $TOC_AUTHORS
. \}
. \}
-. nop
. sp |\\n[#DOCHEADER_ADVANCE]u-\\n[#DOC_LEAD]u
. PDF_BOOKMARK 1 \\*[$TOC_TITLE_ITEM]
. as $TOC_TITLE_ITEM \|
@@ -9723,6 +9722,7 @@ $DOC_COVER_TITLE_\\n+[#DOC_COVER_TITLE_NUM]
\\$\\n[#DOC_COVER_TITLE_NUM]
.\}
.if !'\\n[.ev]'0' .ev
.rr ref*last
+.po \ Ensure reset to last value
.END
\#
.MAC PRINT_FOOTER END
@@ -21097,7 +21097,7 @@ Macro MN: Warning: Right margin note #\\n[MN-curr] on
page \\n[#P] shifted down.
. chop pdf:clean
. asciify pdf:clean
. ev
-. ds \\*[pdfcleaned] \\*[pdf:clean]\
+. ds \\*[pdfcleaned] \\*[pdf:clean]
. rm pdf:clean
. tr \[em]\[em]
.\}
___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit
[groff] 01/01: Added links to online documentation and mom homepage to SEE ALSO.
PTPi pushed a commit to branch master in repository groff. commit 92f228a85cdf4aa4972dad74d2771ed239db10de Author: Peter Schaffter pe...@schaffter.ca Date: Mon Sep 22 12:36:55 2014 -0400 Added links to online documentation and mom homepage to SEE ALSO. --- contrib/mom/groff_mom.man | 14 -- 1 files changed, 12 insertions(+), 2 deletions(-) diff --git a/contrib/mom/groff_mom.man b/contrib/mom/groff_mom.man index 3fef608..4e787b0 100644 --- a/contrib/mom/groff_mom.man +++ b/contrib/mom/groff_mom.man @@ -22,7 +22,7 @@ You should have received a copy of the GNU General Public License along with groff, see the files COPYING and LICENSE in the top directory of the groff Text source package. -Or read the man-page +Or read the manpage .BR gpl (1). You can also visit http://www.gnu.org/licenses/. .. @@ -293,7 +293,7 @@ begin using an initialized colour inline . .TP .FONT B \[rs]*[BCK I n B ] -move wards in a line +move backwards in a line . . .TP @@ -3373,6 +3373,16 @@ after NEWPAGE, like this: .B \%@HTMLDOCDIR@/\:mom/\:toc.html \[en] entry point to the HTML documentation . +.TP +.UR http://\:www.schaffter.ca/\:mom/\:momdoc/\:toc.html +.UE +\[en] HTML documentation online +. +.TP +.UR http://\:www.schaffter.ca/\:mom/ +.UE +\[en] the mom macros homepage +. . .\ .SH BUGS ___ Groff-commit mailing list Groff-commit@gnu.org https://lists.gnu.org/mailman/listinfo/groff-commit
[groff] 01/01: Doc fixes for PT_SIZE and related inlines.
PTPi pushed a commit to branch master in repository groff. commit cd830d8c7a4ff6ccadce870395e709db2dccc9e4 Author: Peter Schaffter pe...@schaffter.ca Date: Mon Sep 22 13:02:00 2014 -0400 Doc fixes for PT_SIZE and related inlines. --- contrib/mom/momdoc/inlines.html |5 + contrib/mom/momdoc/typesetting.html | 11 +++ 2 files changed, 16 insertions(+), 0 deletions(-) diff --git a/contrib/mom/momdoc/inlines.html b/contrib/mom/momdoc/inlines.html index cf8aab8..18369b9 100644 --- a/contrib/mom/momdoc/inlines.html +++ b/contrib/mom/momdoc/inlines.html @@ -241,6 +241,8 @@ or span class=pre-in-pp \*S[12] /span +Entering either kbd\*[SIZE]/kbd or kbd\*S[]/kbd with no +argument reverts to the former point size. /p p @@ -269,6 +271,9 @@ size of the rest of the line. While she isn't perfect, \*S[+2]mom\*S[-2] isn't half bad. While she isn't perfect, \*[SIZE +2]mom\*[SIZE -2] isn't half bad. /span +Please note that inline size changes do not update the leading if +a href=typesetting.html#autoleadAUTOLEAD/a +is enabled. /p div class=box-notes diff --git a/contrib/mom/momdoc/typesetting.html b/contrib/mom/momdoc/typesetting.html index ad15317..0bda6ea 100644 --- a/contrib/mom/momdoc/typesetting.html +++ b/contrib/mom/momdoc/typesetting.html @@ -1106,6 +1106,13 @@ Point sizes may be fractional (eg 10.25 or 12.5). /p p +If you invoke PT_SIZE without an argument, it reverts to its former +value. For example, if your point size is 10 and you change it to +12 with kbd.PT_SIZEnbsp;12/kbd, entering kbd.PT_SIZE/kbd +(i.e. without an argument) resets the point size to 10. +/p + +p You can prepend a plus or a minus sign to the argument to PT_SIZE, in which case the point size will be changed by + or - the original value. For example, if the point size is 12, and you want 14, you @@ -1118,6 +1125,10 @@ then later reset it to 12 with span class=pre-in-pp .PT_SIZE -2 /span +or, more simply, just +span class=pre-in-pp + .PT_SIZE +/span The size of type can also be changed inline. See a href=inlines.html#inline-size-momInline Escapes, changing point size/a. /p ___ Groff-commit mailing list Groff-commit@gnu.org https://lists.gnu.org/mailman/listinfo/groff-commit
[groff] 01/01: Doc fixes.
PTPi pushed a commit to branch master in repository groff. commit 7d3434e6564e7c5680e6b2775e9eb5cca65974c5 Author: Peter Schaffter pe...@schaffter.ca Date: Tue Sep 23 01:40:09 2014 -0400 Doc fixes. --- contrib/mom/momdoc/inlines.html |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/contrib/mom/momdoc/inlines.html b/contrib/mom/momdoc/inlines.html index 18369b9..c93c54d 100644 --- a/contrib/mom/momdoc/inlines.html +++ b/contrib/mom/momdoc/inlines.html @@ -1005,9 +1005,10 @@ and bpic/b from Both are powerful tools, but they can be nasty to learnmdash;at first, anyway. You may prefer to use a vector drawing program to create diagrams and tables; inserting the results into a -document is easy enough with kbd.PSPIC/kbd (consult -kbdman groff-tmac/kbd for information on this indispensable and -easy-to-use macro). +document is easy enough with +a href=images.html#pdf-imagePDF_IMAGE/a +or +a href=images.html#pspicPSPIC/a. /p /div ___ Groff-commit mailing list Groff-commit@gnu.org https://lists.gnu.org/mailman/listinfo/groff-commit
Re: [Groff] PDFPIC macro
On Mon, Sep 22, 2014, Deri James wrote: On Sun 21 Sep 2014 20:50:37 Keith Marshall wrote: On 21/09/14 20:04, Deri James wrote: I'm glad that Ulrich has answered you, it was not my place to identify the person as they contacted me privately, Sure, but we must strenuously discourage such private communications; how on earth can we expect to effectively co-ordinate development, if potential developers are left in the dark, regarding what each other is doing? but I felt the list should be aware something was in the wind. Right. Not just should; it is imperative. Keith, I hope you agree that what I did was correct. If someone asks to look at my code, it does not mean they are definitely going to write something, so its not my part to announce their definite involvement, since the final decision is theirs. However, I wanted to inform the list in case someone else was working on the same thing. Have I breached etiquette by dealing with the circumstances in this way? I concur with Keith, but there was no breach of etiquette, IMO. Sometimes there are good reasons why list members prefer to discuss things off-list, especially during the exploratory phase of an idea. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] PDFPIC macro
On Thu, Sep 18, 2014, Keith Marshall wrote: On 18/09/14 14:42, Peter Schaffter wrote: Would an addition to the warning emitted by the macro be sufficient to alert users to the potential dangers of -U? Perhaps, but it's so much better if it can be avoided altogether. FWIW, in my former employment I produced a significant volume of PDF documentation -- including the occasional PSPIC image -- using pdfroff on MS-Windows, without ever needing to use -U. pdfinfo isn't the only reason for -U; the macro, as is, also converts pdf images to eps for non-gropdf processing. This is a judgment call on my part. The macro could as easily reject pdfimages entirely when !'\\*[.T]'pdf' -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Documentation for -mom
Sorry not to get back on this right away. I've been away for a couple of days--work and computer free! On Fri, Sep 19, 2014, Ingo Schwarze wrote: I am loking for an easy documentation about -mom. This documentation should discribe how -mom macros are working. Have you seen http://www.schaffter.ca/mom/mom-01.html ? This is the definitive online documentation. The same documentation is also always present in the download tarballs on the mom site. http://www.schaffter.ca/mom/mom-2.0-c.tar.gz Given that the build systems disables building HTML documentation when some support software is missing on the target system and that the main mom documentation is (very unfortunately, but that's the current state of affairs) HTML, we end up in a situation where some groff installations do not include full mom documentation. A lot of mom users would disagree that having the documentation in html is unfortunate. :) However, I'm going to have a look at the situation of disabling building html when support software is missing. The mom docs require no special build tools, hence there's no reason not to include the docs in every installation. To mitigate that situation, i think it would help a bit to include a link to http://www.schaffter.ca/mom/mom-04.html (that file name seems a bit awkward; is it stable?) in contrib/mom/groff_mom.man below SEE ALSO. Yes, that would help. I'll get onto it. The link should probably point to mom-01.html, though, not mom-04.html. And yes, the filename is stable. I own the domain and it's hosted on iPage, so it's not going anywhere soon. :) Something else that would help, too, would be converting the docs to pdf. It's kind of a back-burner project, though. Although they're written in xhtml, which will ease the process, re-organizing the docs for print won't be quite so simple. Cheers. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] PDFPIC macro
On Wed, Sep 17, 2014, Ralph Corderoy wrote:
Can't argue with a post that uses `whence'. Would be nice to see a bit
more `{,t,w}hither'.
:)
. sy pdfinfo @$1 | \
grep Page *size | \
sed -e 's/Page *size: *\\([[:digit:].]*\\) *x *\\([[:digit:].]*\\).*$/\
.nr pdf-wid (p;\\1)\\n\
.nr pdf-ht (p;\\2)/' \
/tmp/pdfpic\n[$$]
sed can do grep's work here. Simplest way would be to drop grep and
pass -n to sed, then append `p' to the trailing slash of the s///.
Thanks, Keith.
--
Peter Schaffter
http://www.schaffter.ca
Re: [Groff] PDFPIC macro
On Thu, Sep 18, 2014, Keith Marshall wrote: On 17/09/14 22:22, Peter Schaffter wrote: Yes. The way groff stands now, I'm uneasy relying on external tools and .sy for anything but local, user-written macros. There's precedent, though, in www.tmac (PIMG), and this seems to be the best solution for PDF images. Do note, however, that this will compromise portability; e.g. pdfinfo is unlikely to be supported on MS-Windows hosts. Also, since .sy is an intrinsically unsafe request, any macro which relies on it *must* be invoked in unsafe mode, and users should rightly be wary of enabling that, for untrusted sources. Are there any tools that can be used in place of pdfinfo that are Windows safe? Sorry, I haven't done Windows since...well...ever. :) Would an addition to the warning emitted by the macro be sufficient to alert users to the potential dangers of -U? -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] broken interaction between line numbering and diversions
Dave -- On Wed, Sep 17, 2014, Dave Kemper wrote: On 9/17/14, Tadziu Hoffmann hoffm...@usm.uni-muenchen.de wrote: I think you're using the diversion wrong. This is, admittedly, an artificial example cooked up to illustrate the behavior. This is clearly a situation where a diversion, or even a macro, would be unnecessary at all. The question I'm posing is whether a user who uses a diversion in this wrong (or, let's say, less than optimal) manner should see output that is so clearly not what was intended, or whether the software should do something intelligent with the user's suboptimal input, producing output that is probably what the user wanted. Subjectively, I find .nm a bit clunky, as if it were implemented as an afterthought. Again, that's purely subjective, based on the difficulty I had implementing a (relatively) sane line numbering strategy for the mom macros. That said, the real issue is the correct way to output your line-numbered diversion, ie by preceding it with .nf. The rules and conventions surrounding diversions are well-documented but not all in one place. Users have to synthesize scattered bits and pieces of information, which is hard to do without reading all of 'info groff' (repeatedly). For example: - there is no mention of .nf in 5.25 Diversions - there is no mention of diversions in 5.7 Manipulating Filling and Adjusting = .nf - there is no mention of diversions in 5.31 Miscellaneous = .nm Getting groff to do something intelligent with suboptimal input isn't intrinsic to its design. The opposite, in fact: groff expects intelligent use of optimal input. It's a harsh and unforgiving taskmaster, and often flouts the principle of least astonishment. Something more lenient and less whimsical-seeming would be great, but it wouldn't be groff. What groff needs, more than anything else, is a new book--a sort of updated, groff-specific UTP--that doesn't just document behaviour but discusses real-world groff usage in depth. Groff for Smart Dummies, IOW. If I could get a contract to write such a book, I'd take it on in a heartbeat. (It's far more work than my free time allows.) Groff is not modern software. But should it make some concessions to the fact that it's still around in 2014? Not so much concessions as accommodations. E.g., the .ul request, recently discussed, shouldn't be altered. Rather, a means to implement no-fault underlining as a new request should be considered. -- Peter Schaffter http://www.schaffter.ca
[Groff] PDFPIC macro
Attached is a proposal for a general use PDFPIC macro. It's
modelled after and takes exactly the same arguments as PSPIC.
Since there's no groff pdf equivalent to .psbb, an external
program is used to get the image dimensions (pdfinfo(1) from the
poppler-utils package). The alternative is to require users to get
the dimensions themselves and make width/height required arguments.
I prefer not to take that approach since my idea is that PSPIC and
PDFPIC should behave identically, making everybody's life easier.
In the case of PDFPIC not being used with gropdf(1), an external
program (pstopdf(1)) is used to convert the pdf file to eps, whence
processing is passed over to PSPIC. This seemed simpler than
re-inventing the wheel.
Comments and suggestions, please.
--
Peter Schaffter
http://www.schaffter.ca
.\ pdfpic.tmac
.\
.\ Define the PDFPIC macro.
.\
.\ When used other than with gropdf, the image is converted to .eps
.\ and processing passed over to PSPIC.
.\
.\ Usage:
.\
.\ .PDFPIC [-L|-R|-C|-I indent] file [width [height]]
.\
.\ Requires the poppler-utils package (for pdfinfo and pdftops).
.\ Requires running groff in unsafe mode.
.
.do if d PDFPIC .nx
.
.nr _C \n[.C]
.cp 0
.
.de @abort
. ab [PDFPIC]: \\$* Aborting.
..
.de PDFPIC
. if !\\n[.U] \
.@abort Use of \\$0 requires giving groff the -U option.
.
. nr convert-pdf 0
. if !'\\*[.T]'pdf' .nr convert-pdf 1
.
. nr pdf-offset-mode 0
.
. \ left-aligned?
. ie '\\$1'-L' \{\
.nr pdf-offset-mode 1
.if \\n[convert-pdf] .ds pspic-args \\$1 \
.shift
. \}
. el \{\
.\ right-aligned?
.ie '\\$1'-R' \{\
. nr pdf-offset-mode 2
. if \\n[convert-pdf] .ds pspic-args \\$1 \
. shift
.\}
.el \{\
. \ indented?
. ie '\\$1'-I' \{\
.nr pdf-offset-mode 3
.nr pdf-offset (m;\\$2)
.if \\n[convert-pdf] .ds pspic-args \\$1 \\$2 \
.shift 2
. \}
. el \{\
.\ centered is the default
.ie '\\$1'-C' \{\
. if \\n[convert-pdf] .ds pspic-args \\$1 \
. shift
.\}
.el .nr pdf-offset-mode 0
. \}
.\}
. \}
. br
.
. ds is-pdf \\$1
. substring is-pdf -3
. if !'\\*[is-pdf]'pdf' \
.@abort \\$1 at line \\n[.c] is not a PDF file, or lacks a .pdf extension.
.
.\ if driver is not gropdf, convert image to .eps
. if \\n[convert-pdf] \{\
.ds img-file \\$1
.substring img-file 0 -5
.
.sy pdftops -eps \\$1
.shift
.
.as pspic-args \\*[img-file].eps \\$*
.
.PSPIC \\*[pspic-args]
.return
. \}
.
.\ get image dimensions
. ec @
. sy pdfinfo @$1 | \
grep Page *size | \
sed -e 's/Page *size: *\\([[:digit:].]*\\) *x *\\([[:digit:].]*\\).*$/\
.nr pdf-wid (p;\\1)\\n\
.nr pdf-ht (p;\\2)/' \
/tmp/pdfpic\n[$$]
. so /tmp/pdfpic\n[$$]
. sy rm /tmp/pdfpic\n[$$]
. ec
.
. \ if we have a width parameter, use it as the final
. \ image width; otherwise we use the image's natural width
. \ or the current line length, whatever is smaller
. ie (\\n[.$] = 2) \
.nr pdf-deswid (i;\\$2)
. el \
.nr pdf-deswid ((\\n[.l] - \\n[.i]) ? \\n[pdf-wid])
.
. \ compute the final image height (with proper rounding),
. \ based on the image's aspect
. nr pdf-desht (\\n[pdf-deswid] * 1000 + (\\n[pdf-wid] / 2) \
/ \\n[pdf-wid] * \\n[pdf-ht] \
+ 500 / 1000)
.
. \ if we have a height parameter, use it as the final
. \ image height in case it is smaller than the height
. \ value we have just computed
. if ((\\n[.$] = 3) (\\n[pdf-desht] (i;0\\$3))) \{\
.nr pdf-desht (i;\\$3)
.\ recompute the final image width since we always
.\ keep the correct image aspect
.nr pdf-deswid (\\n[pdf-desht] * 1000 + (\\n[pdf-ht] / 2) \
/ \\n[pdf-ht] * \\n[pdf-wid] \
+ 500 / 1000)
. \}
.
. \ reserve vertical space for image
. ne (\\n[pdf-desht]u + 1v)
.
. \ compute image offset w.r.t. the current left margin
. if (\\n[pdf-offset-mode] == 0) \
.nr pdf-offset (\\n[.l] - \\n[.i] - \\n[pdf-deswid] / 2)
. if (\\n[pdf-offset-mode] == 1) \
.nr pdf-offset 0
. if (\\n[pdf-offset-mode] == 2) \
.nr pdf-offset (\\n[.l] - \\n[.i] - \\n[pdf-deswid])
.
\h'\\n[pdf-offset]u'\
\X'pdf: pdfpic \\$1 -L \\n[pdf-deswid]z \\n[pdf-desht]z'
..
.
.cp \n[_C]
.
.\ end of pdfpic.tmac
Re: [Groff] PDFPIC macro
On Wed, Sep 17, 2014, Steffen Nurpmeso wrote: I'm not in the position to say something to PDFPIC today (direct support would be pretty cool!), but there should be general tools for sh(1) (perl(1)...) that can be included in a defined way and used. I.e., roff libraries. And the very same is true for generic use of external commands, as is used by you, and what came to my mind immediately when reading: . sy pdfinfo @$1 | \ grep Page *size | \ sed -e 's/Page *size: *\\([[:digit:].]*\\) *x *\\([[:digit:].]*\\).*$/\ .nr pdf-wid (p;\\1)\\n\ .nr pdf-ht (p;\\2)/' \ /tmp/pdfpic\n[$$] For example here. There should be a way to safely generate temporary file names in the temporary directory that is currently used, whatever this is (most likely $TMPDIR). Yes. The way groff stands now, I'm uneasy relying on external tools and .sy for anything but local, user-written macros. There's precedent, though, in www.tmac (PIMG), and this seems to be the best solution for PDF images. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Overview, Sept. 2014
Bertrand -- On Fri, Sep 12, 2014, Bertrand Garrigues wrote: I would not be afraid to dive into the source code. Although my main language is C, not C++, groff's C++ code seems quite understandable for a C programmer, as it was already said in the list. The problem is that I didn't feel I had sufficient general knowledge on groff to participate to the conversation, and other newcomers probably feel the same. I'm not that young but yes, I don't even understand the current behaviour of .ul ! There's a generational aspect to groff development that makes it, if not unique, at least a rarity. From roff to contemporary groff spans many decades. Some list members were there at the Big Bang. Others came in only after GNU/Linux made UNIX widely available. Others are fresh out of school, so to speak. I came to the project as a sort of middle-generation newcomer, and it took a while before I felt like anything more than the brash and annoying new kid on the block. The feeling didn't originate from the list, which is one of the most welcoming and supportive there is; it was the natural response to feeling I might be treading on the toes of my significantly wiser elders. Or, more colourfully, I couldn't help feeling that with people like Eric and Doug and Brian on the list, God was watching. I have often wondered whether this perfectly understandable but entirely self-generated anxiety is a factor in the willingness, or unwillingness, of other new kids on the block to get down and dirty with groff. Just thoughts, folks... -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Introduction
Robert -- On Wed, Sep 10, 2014, Robert Bocchino wrote: As I mentioned to Werner, I'm a professional software engineer, regular groff user, and Unix tool enthusiast, and I'd like to contribute back to groff development. Welcome! -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Overview, Sept. 2014
Ingo -- On Wed, Sep 10, 2014, Ingo Schwarze wrote: Some things work more or less similarly in git: * cvs co module - git clone module Except that it also mirrors the whole repo including history. ... Your table is great. I'm going to print off a copy. It was a lot of typing, so thanks! -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Overview, Sept. 2014
Ingo -- On Wed, Sep 10, 2014, Ingo Schwarze wrote: One of the issues he raised with me off-list is an apparent lack of organization. It's true. I disagree. Lack of reviewable patches is not lack of organization. If you have reviewable patches and people go for each other's throat instead of testing the patches and providing OKs or specific suggestions for improvement, that might be called lack of organization. But that's not at all what we have. Key word: apparent. I meant to convey that the situation might be perceived as lacking organization, not that it does. A suit, for example, would see it that way. He'd be wrong, of course. Vaibhaw suggested that a list of major work that is ongoing in groff would be helpful, too, with some sort of ETA. I'm not sure such a list is even possible (esp. the ETAs), but it's a reasonable thing for any maintainer to want, That's not what a maintainer of a free software project would ask of his fellow developers. That's not even what a team leader would ask of his workforce in a sweatshop. It's what a Senior Vice President of Technology would ask of his Managing Directors in a corporation. Not sure such a thing is that helpful with a handful of part-time free software nerds. ;-) In my experience, ETAs fail more often than not, even in a commercial setting where everybody works full time, where that pesky thing called real life doesn't intervene except when people fall ill, and where even that is smoothened out by the law of large numbers. Total agreement, hence the parenthetical comment about ETAs. :) I presented the matter as it was presented to me; it doesn't reflect my personal opinion. I do like the idea of having a list of who's doing what, etc, though. It's not essential--anybody can enquire about anything on the list and somebody always pops up with an answer--but it would be nice to have, if only to form a cognitive map of the groff terrain, so to speak. Plus, one does sometimes want to contact the expert in a particular area off list, or the person actively working on a specific part of groff. In the latter case, one could, I suppose, use git tools to extrapolate who's working on what, but a simple list is more convenient. Anyway, if others agree, they'll supply what's needed, as you did. Otherwise, it's an idea that didn't take. I don't think there's much need for discussion. It's a trivial matter. -- Peter Schaffter http://www.schaffter.ca
[Groff] Overview, Sept. 2014
Greetings. Traffic and activity on the list got pretty hot over the summer. Good discussions about underlining, Betrand's automake migration nearly completed, and Bernd's Herculean labours tackling manpage updates, licensing, copyrights, and a whole whack of other annoying but essential details. Plus we've garnered Ingo's valuable BSD input, and embraced discussion about Heirloom Troff's revitalized development on the list. Oddly, I have less free time for projects during the summer than during the working months, so I haven't done much more than follow what's been happening. It's September now, and I have time again. The thread on underlining raised a couple of issues. One is whether a long-established request (.ul) should be updated. The rationale is that it's unlikely anyone in 2014+ needs (or, if young enough, even understands) the current behaviour. However, it's evident from list comments that we're mostly in agreement: .ul should be left as is. This reflects an overall feeling about backward compatibility, which is that it should be fully preserved. Out of that discussion came Doug's excellent suggestion for a new primitive, '.decor' or similarly named, that's extensible so various kinds of decoration can be applied to text, not just underlining (which, IMO, groff seriously needs). The addition of useful new requests is part of our mission statement, and Doug's '.decor' fits the bill. Problem is, the thread died, and nothing came of it. I suspect that's in part because we're all leery of mucking about in the sources. It may also point to a dearth of skilled C++ coders on the list, which, if true, is something we're going to have to address. On a similar note, Ulrich Lautner stepped forward to take on implementing a modified version of Knuth-Plass. He produced a prototype showing that the application of dynamic programming to paragraph formatting can be done with a relatively small piece of code and at high speed. I was excited, but interest from others hovered around zero. I'm not sure why: from previous discussions, revamping groff's paragraph formatting is a priority. If Ulrich is to pursue this (provided he's still interested, and I, for one, sincerely hope he is), he needs assistance from the list. Off-list he wrote: I am not yet sure if I should try to integrate the code into groff. The groff code is not that readable, missing comments and common coding conventions, such as - using capitalization for class names - special naming conventions for class members - access to class members by setters / getters - avoidance of global variables So groff could benefit from some refactoring. He's probably right about refactoring, but the more important issue is: who, on the list, feels qualified to point him in the right direction within the code for work on formatting? Myself, I'm not the best person since my involvement with groff has been almost exclusively within user-space. Vaibhaw Pandey stepped forward as a candidate for the role of maintainer, but he's discovering the job is bigger than he imagined. One of the issues he raised with me off-list is an apparent lack of organization. It's true. We have, for a really long time, essentially been self-organizing. It's worked well and reflects an ethos to which most of us, I think, subscribe. However, just now, it's somewhat counterproductive. Something that would help a lot is for everyone actively involved in development to post the components/projects they're working on and where their various expertises and interests lie. This would allow compiling a list of who's interested in what, who's doing what, and whose knowledge can be called upon. (Wouldn't hurt to know who currently has write access to the repo, either). The list could be posted on the groff webpage and serve to let the world know what's going on. I'll get the ball rolling by starting a thread. Vaibhaw suggested that a list of major work that is ongoing in groff would be helpful, too, with some sort of ETA. I'm not sure such a list is even possible (esp. the ETAs), but it's a reasonable thing for any maintainer to want, so we should at consider it. At the very least, it might help us achieve a bit more focus. With respect to Vaibhaw's candidacy as maintainer, I propose leaving the looking for a new maintainer notice on the webpage until the matter is definitively settled. (If everyone's agreeable, I'll take ownership of the webpage.) Lastly, except in the case of developers who own particular projects, let's try to comply with what Werner requested some time ago: that diffs/patches be posted to the list before pushing them to the repo. There've been rather more git undos than I think is healthy, and the reasons for them have been spotted quickly. It makes all kinds of sense to have other eyes inspect changes before they go into the repo. Cheers. -- Peter Schaffter http://www.schaffter.ca
[Groff] Who is doing what
As mentioned, I'm starting this thread to see if we can get together a list of who's doing what currently, where their interests lie, etc. If others follow my lead, we'll end up with a useful snapshot of available human resources within the groff community. Here's what I bring to the table. Peter Schaffter: Projects/components - developer and maintainer of the mom macros (contrib/mom) and all related documentation and examples - maintainer of the groff webpage at gnu.org Competences - shell scripting - sed scripting - html/css Expertises - macro programming - typography - page layout/design - documentation writing Prepared to - assume a non-technical leadership role, including - overseeing the big picture and non-invasively steering the boat (gotta love them mixed metaphors) - resolving debates and striving for consensus on major issues - actively searching for new development blood (I'm wondering if we can harness the power of GSoC) - ensuring that good proposals don't die of attrition - interfacing with developers individually, as necessary, to track the state of projects and contributions - other stuff of a similar nature I can't think of on the spot :) -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Missing text in PDF with Mom
On Sat, Sep 06, 2014, Ted Harding wrote: I wrote the small text file below in Mom, and processed it into pdf using pdfmom 1.22.2, on a Fedora 20 box. Then I moved the pdf to a Windows machine. The generated pdf file doesn't have any paragraphs when viewed by Adobe Reader XI Version 11.00.08 on Windows 8 64-bit. It is nothing but title text. But if I convert the resultant pdf to a PNG using pdftopng 3.04 on Fedora, the title text and the paragraph text appears. snip I'm not a Mommer, so cannot contribute any possible explanation! I can't reproduce this problem. Processing the sample .mom file with pdfmom(1) on my system gives the expected result, ie all the text is there. I don't have Adobe Reader XI v11.00.08--Adobe hasn't released it for Linux and I don't run Windows--but the pdf views cleanly in v9.1.0, as it does in okular (kde) and evince (gnome). I get identically clean results with 'groff -mom -Tpdf file outfile.pdf' and 'groff -mom -Tps file | ps2pdf - outfile.pdf' Mike (the OP, that is, not Bianchi), please test whether you get the missing text problem with pdfmom file.mom | okular - or pdfmom file.mom outfile.pdf evince outfile.pdf If yes, then we may be able to track down where your problem lies. If not, we have to conclude that Adobe Reader 11.xx for Windows is responsible somehow. Cheers. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Missing text in PDF with Mom
On Sat, Sep 06, 2014, Ralph Corderoy wrote: Hi Peter, If not, we have to conclude that Adobe Reader 11.xx for Windows is responsible somehow. It's not Adobe Reader, not unless the PDF attached to the email was somehow re-saved from it. That was line of thinking I was going to explore. Seems the OP figured out what the problem was, though. -- Peter Schaffter http://www.schaffter.ca
Re: [groff] 01/01: contrib/mom: license and Emacs setup; ChangeLog: repair it.
On Thu, Sep 04, 2014, Werner Lemberg wrote: contrib/mom: license and Emacs setup; ChangeLog: repair it. Bernd, I generally applause your efforts on normalizing those issues. However, `mom' is actively maintained by Peter, and your changes are quite substantial, so please contact him in advance whether he likes your modifications. They're fine, if overkill, eg copyrighting BUGS. And yes, please, anyone making changes within contrib/mom should pass them by me before pushing them to the repo. -- Peter Schaffter http://www.schaffter.ca ___ Groff-commit mailing list Groff-commit@gnu.org https://lists.gnu.org/mailman/listinfo/groff-commit
Re: [Groff] .mk/.rt not work across a page?
On Thu, Sep 04, 2014, Anton Shterenlikht wrote: Date: Thu, 4 Sep 2014 12:31:09 +0200 (CEST) From: Carsten Kunze carsten.ku...@arcor.de To: groff@gnu.org You could try .mk A and on the next page .sp |\nA (have not tested that.) In UNIX Text Processing, p. 462, the advice is .mk Q .sp |\nQu Neither your form nor theirs (with u at the end) work. I guess this is because this feature is used to affect vertical position on a single page, not across pages. That's correct. The absolute position indicator means distance from page top. There's no way to .sp or .rt to a previous page. -- Peter Schaffter http://www.schaffter.ca
[Groff] configure issue
I haven't built groff from source for a while. Just tried. ./configure: line 4400: GROFF_CXX_CHECK: command not found ./configure: line 4401: GROFF_EBCDIC: command not found ./configure: line 4402: GROFF_OS390: command not found ./configure: line 4403: GROFF_X11: command not found ./configure: line 4404: GROFF_APPRESDIR_OPTION: command not found ./configure: line 4405: GROFF_APPRESDIR_DEFAULT: command not found ./configure: line 4406: GROFF_LIBPROGRAMDIR_DEFAULT: command not found ./configure: line 4407: GROFF_GROFFERDIR_OPTION: command not found ./configure: line 4408: GROFF_GROFFERDIR_DEFAULT: command not found ./configure: line 4409: GROFF_GLILYPONDDIR_DEFAULT: command not found ./configure: line 4410: GROFF_GPINYINDIR_DEFAULT: command not found ./configure: line 4411: GROFF_GROGDIR_DEFAULT: command not found ./configure: line 4412: GROFF_PERL: command not found ./configure: line 4413: GROFF_PRINT: command not found ./configure: line 4414: GROFF_REFER: command not found ./configure: line 4415: GROFF_REFERDIR_DEFAULT: command not found ./configure: line 4483: GROFF_PROG_YACC: command not found ./configure: line 4484: GROFF_DOC_CHECK: command not found ./configure: line 4485: GROFF_MAKEINFO: command not found ./configure: line 4578: GROFF_INSTALL_SH: command not found ./configure: line 4579: GROFF_INSTALL_INFO: command not found ./configure: line 4716: syntax error near unexpected token `SH_SCRIPT_SED_CMD='1s/.*/:/',' ./configure: line 4716: `GROFF_CSH_HACK(SH_SCRIPT_SED_CMD='1s/.*/:/', SH_SCRIPT_SED_CMD='1s/a/a/')' What gives? -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] [groff] 01/01: contrib/mom: license and Emacs setup; ChangeLog: repair it.
On Thu, Sep 04, 2014, Werner Lemberg wrote: contrib/mom: license and Emacs setup; ChangeLog: repair it. Bernd, I generally applause your efforts on normalizing those issues. However, `mom' is actively maintained by Peter, and your changes are quite substantial, so please contact him in advance whether he likes your modifications. They're fine, if overkill, eg copyrighting BUGS. And yes, please, anyone making changes within contrib/mom should pass them by me before pushing them to the repo. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] configure issue
On Thu, Sep 04, 2014, Colin Watson wrote: On Thu, Sep 04, 2014 at 12:50:29PM -0400, Peter Schaffter wrote: I haven't built groff from source for a while. Just tried. ./configure: line 4400: GROFF_CXX_CHECK: command not found Bernd's commit 9f6f7cf3b0e4d1c615f625eda7c686a483d572a6 appears to have badly damaged configure. Running autoreconf -fi -I m4 fixes it Thanks. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] OT: Fork of the Heirloom Documentation Tools for fixing bugs
On Wed, Aug 27, 2014, Pierre-Jean wrote: Ralph Corderoy wrote: I'd still say give it a try. Perhaps where it is, say, Plan 9-troff specific, mention that in the subject. We've lost the benefits of Usenet readers like trn, but some of us might have mailer's with `kill' files. :-) I'm in complete agreement with Ralph. I'd welcome discussion about all the *roffs out there on the list. Fantastic opportunity for cross-pollination and even code-sharing. As a group, I'm sure we'll be able to deal with volume issues gracefully. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] OT: Fork of the Heirloom Documentation Tools for fixing bugs
On Tue, Aug 26, 2014, Carsten Kunze wrote: For discussing heirloom troff (and other non-groff specific macro packages and tools) a mailing list will be set up to not misuse the groff list and annoy groff-only list members (further ;). Please let us know as soon as the list is set up. I (and others, I imagine) will want to subscribe immediately. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Invalid HTML on groff website
On Tue, Jul 08, 2014, Steffen Nurpmeso wrote: Stumbled over during finding the ultimative underline mail-archive entry, why did i look at the source?, but indeed [1] at least embeds a ul in a p, has a useless /p and keeps a small open over p boundaries. Just in case noone noticed it yet. Finally got around to this. Fixed and updated at the site. The page now validates as fully-compliant HTML5. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Markdown to MOM Using Pandoc
On Fri, Jul 25, 2014, Yves Cloutier wrote: Note that what I am generating are elements as defined by Peter's MOM Macros - not pure troff/groff. So in a sense, the second pass, as you describe (and if I understood it correctly) is automated by the Markdown-MOM writer script. You write plain text, in Markdown, using very minimal tags, which then get replaced by the corresponding MOM macros in the resulting document that it produced. I think Yves is going at this the right way. KISS: choose a macroset (doesn't have to be mom), make markdown parsable into that macroset, and steer clear of low-level groff requests and escapes. Markdown is intended to make sense of a file semantically, not typographically. If you start throwing a lot of bells and whistles at it, you lose the point, which is to keep writing content simple. Myself, I use sed scripts to accomplish exactly what Yves is envisaging. No low-level groff stuff gets added other than pre-pending \ to lines that start with a period or the ' character. My workflow is write, convert, tweak, and it's both efficient and enjoyable. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Markdown to MOM Using Pandoc
On Wed, Jul 23, 2014, James K. Lowden wrote: Do you use stylesheets for documents? I've been writing on a computer since the days of Wordstar, and never felt the need. I think most people rely on the defaults and adjust them as needed, per-document. Which may explain the low-level formatting we've all kvetched about in manpages. :) Seriously, I strongly favour stylesheets, especially in conjuction with simplified markup languages like Markdown. Question of lining up your ducks before you get started typing. In any case, groff already has conditional processing and the .so request. A stylesheet, if that's what's wanted, can be contructed from them. In conjunction with the \V escape, the stylesheet could be included based on the value of an environment variable. .so basically takes care of reading in stylesheets, so the issue isn't how to implement them, it's how to foster their use. A couple of nicely commented stylesheets bundled with Yves' project could prove useful. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Markdown to MOM Using Pandoc
On Wed, Jul 23, 2014, Yves Cloutier wrote: Right now I have hardcoded some default values into the script that generates the MOM code, but the idea will be that all those settings that relate to HOW you want your document to look (like page size, margins, heading styles) would be specified in a separate file, like a stylesheet, which you can specifiy to use when the document being compiled. This would allow for easily changing the look of your document simply by specifying a different stylesheet. This is precisely where mom shines: the ease of creating stylesheets and templates. The actual tag-set is quite small compared to the number of macros that define the style for each tag. You might want to consider designing some useful templates/stylesheets and bundle them into your work. They, in combination with the ease of using Markdown, would make the whole package very attractive to groff newcomers. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Formatting algorithm, an experiment
On Thu, Jun 26, 2014, Ralph Corderoy wrote: When I view Ulrich's email at http://lists.gnu.org/archive/html/groff/2014-06/msg00089.html I see a distribute.tgz link at the end of it to http://lists.gnu.org/archive/html/groff/2014-06/bin14bGZPiUPU.bin which works for me. The .bin extension issue for attachments in archived email has come up before. Does anyone know why lists.gnu.org is doing this and whether there'd be any point trying to get it fixed? -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] [patch] unbreak make install
On Sun, Jun 22, 2014, Werner Lemberg wrote: It's good that we have a watchdog called Ingo :-) Peter, please apply his trivial patch. Seems Bernd's already taken care of it. -- Peter Schaffter http://www.schaffter.ca
[Groff] Pre-commit testing, automake
On Sun, Jun 22, 2014, Ingo Schwarze wrote: However, my impression is that at least part of the problem we are facing here, and probably the more important part, is social in nature rather than technical. Change is in the air. It'll be a while before we adapt to it fully. During Werner's tenure, we had relatively few contributors and God at the helm. After the spate of discussions about groff's future, etc., we're beginning to attract fresh blood. Our situation now is that we have more contributors, or potential contributors, but no longer have the luxury of trusting just one person to spot problems. For the next while, it's important that we go overboard in testing our work before committing--the social aspect Ingo's talking about. It's a pain, I know, submitting patches to the list, but, for now, it's as good a way as any to deal with what Vaibhaw points out: Groff seems to be complex enough for not just one person to get their heads around. Vaibhaw has intimated he will attack the issue of test suites around major packages that can quickly sanitize our checkins or an automated build and test system, and Betrand has submitted a proposal for migrating to automake. My feeling is that both are important (automake perhaps a little less so, see below) now that there are more people wanting to contribute to the project. Groff has been a pretty closed community for the past decade so we haven't had to deal these things; now we do. During this what amounts to transitional period, extra vigilance with respect to changes and commits needs to be practised. On the automake debate, I favour migration but have no strong opinions. I know others do, and I'm wondering if those with objections could post them for discussion so Betrand's work won't be in vain should some compelling reason for leaving things as they are emerge. Vigilance, again. :) -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Three topics related to images
On Sat, Jun 21, 2014, Ralph Corderoy wrote: mom's PDF_IMAGE macro could remain a float with lots of bells and whistles to the user but make use of an underlying macro-set-agnostic macro to do the PDF inclusion as Tadziu suggested; provide a bare-bones PDF image includer à la PSPIC instead. IOW, bits of PDF_IMAGE's functionality are useful elsewhere; can that be factored out and made available? Yes. It's just a question of wrapping \X'pdf: pdfpic ... inside a macro with flags for positioning and scaling. Unlike PSPIC, though, you'd still have to get the bounding box externally since groff doesn't implement a pdf equivalent to .psbb. I'll look into it this week. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] [patch] unbreak make install
On Sat, Jun 21, 2014, Ingo Schwarze wrote: It is certainly nice to see when upstream groff development makes progress. However, i would consider it common practice for upstream committers to test the build before committing, rather than relying on downstream consumers to catch trivial build system bugs... Ingo's right. We need to stick to the policy of posting changes that affect the build system and the core distribution prior to committing. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Three topics related to images
On Thu, Jun 19, 2014, Mikkel wrote: Why PDF_IMAGE This is probably mostly a queston for Peter, in each case it is a specific mom questions. I want to understand why PDF_IMAGE macro. Which problems does ti solv? What is it that PDF_IMAGE can do that PSPIC can not do? It lets you insert pdf images into documents. :) Additionally: - allows scaling by percentage - provides sensible float handling - allows adjustments to vertical placement for better optical centering - can be captioned and labelled - provides the option to put a frame around the image It would be exceptionally nice if groff natively handled images in formats other than ps and pdf, but I don't think that's going to happen any time soon. For now, it's .ps, or .pdf, or nothing. Not a huge issue with 'convert'. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] My way to run preprosessors and to set options
On Thu, Jun 19, 2014, Ulrich Lauther wrote: On Wed, Jun 18, 2014 at 10:48:51AM +0200, Bernd Warken wrote: No, I am not (yet?) a groff contributer. But I could publish my script, if there is general interest. Please publish your script! The implementation in `grog' would be very easy. But `groff.cpp' needs C++, which is still quite hard. It would be useful as well, if the `tmac' name is included as well: man, mdoc, me, mm, me, mom, etc. For it is often hard to discover with `grog' and `groffer' which `tmac' should be there, e.g. the difference of `man' and `ms'. It is attached and might need some adjustments according to individual needs. The mom macros are primarily geared towards producing PDF rather than PostScript, and should be processed with Deri's pdfmom wrapper in order to make full use of the PDF optimizations. The script assumes -Tps for all files and converts them to PDF with ps2pdf, which would fail, for example, in the case of images inserted with the PDF_IMAGE macro. If the script is bundled with groff, mom files need to be handled slightly differently: - processed with pdfmom - a command line flag to invoke pdfmom with -Tps if desired -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Formatting algorithm
On Fri, Apr 25, 2014, Doug McIlroy wrote: Equations and displayed quotations are not a problem for the line-breaking algorithm; they'd all be handled in the macro packages, which would have the duty to delimit the blocks of text that are to be treated unitarily. But that doesn't mean we're home free. Line-length changes within such blocks are still a problem. snip Notionally there could be a phantom copy of groff running for each live partial solution that the dynamic program maintains. snip A straightforward way to pull this off would be to actualize the notional copies of groff by forking. There would be one copy going forward from each line break. That would evaluate the cost of breaking at each word (or hyphenation point) on that line. At each line break the copies would rendezvous to see which process should be cloned to continue. Output of each process, both to standard output and standard error, would be treasured up and only the ultimate winner's output would finally be released. This model is somewhat formidable. No kidding. And I fear it might break one of groff's greatest strengths, which is minimal demand on system resources. So far my imagination has failed to find a clean and efficient alternative that retains classic groff semantics in every way except line-breaking. Who has a better idea? ...that retains classic groff semantics is where the challenge lies. Groff is built from the ground up to use a greedy algorithm, making dynamic programming somewhat alien. I can't help but wonder whether any attempt to implement KP won't ultimately stumble over this issue. A hybrid groff could certainly go off in that direction, but we want to avoid forking the program. In the simplest of terms, KP aims to normalize grey. It does so by minimizing the differences in word spacing from line to line by finding the optimal number of words per line based on an assessment of the whole paragraph. The goal of any new strategy for groff formatting should also be to normalize grey, but that does not necessarily mean KP is the only route. At the risk of sounding like a Johnny-One-Note, I posit that a more sophisticated greedy algorithm, based on what groff already does, stands a higher chance of success. It wouldn't be perfect, but neither is KP. If there's one thing typesetters know, it's that quality typography inevitably involves user intervention. A good typesetting program aims to minimize, not obviate, the need. The principle of least ugly, which so successfully guided lilypond development, might prove a better way of approaching the groff formatting problem. I suspect I'm a voice crying in the wilderness here, but we need to consider that a greedy algorithm is almost always faster than a dynamic programming solution; furthermore, greedy algorithms sometimes lead to optimal solutions. Optimal, in this case, would entail both improved grey *and* preserving groff semantics. Food for thought. -- Peter Schaffter http://www.schaffter.ca
Re: [Groff] Introducing Vaibhaw: new to maintaining groff
Vaibhaw -- On Sun, Apr 27, 2014, Vaibhaw Pandey wrote: I also realize that this group and the extended group of people who care for groff are much more passionate, learned and smarter than I am. We are indeed passionate about groff. As for learned and smarter, your Linkedin profile suggests you're being modest. I hope to make up with perseverance. :) As anyone who's worked with groff for an extended period of time will tell, perseverance--and a healthy dose of ingenuity--are essential. Cheers. -- Peter Schaffter http://www.schaffter.ca
[groff] 01/02: Fixed diacritic lowercase to caps. Moved control of \n[#KERN_UNIT] to macro space. Added COL_MARK.
PTPi pushed a commit to branch master
in repository groff.
commit 33f1287aa537d9f3e632e913c88b70b255212e5c
Author: Peter Schaffter pe...@schaffter.ca
Date: Sun Apr 27 19:19:49 2014 -0400
Fixed diacritic lowercase to caps. Moved control of \n[#KERN_UNIT] to macro
space. Added COL_MARK.
---
contrib/mom/BUGS|3 +
contrib/mom/om.tmac | 290 +++
2 files changed, 157 insertions(+), 136 deletions(-)
diff --git a/contrib/mom/BUGS b/contrib/mom/BUGS
index 165c0d7..014af85 100644
--- a/contrib/mom/BUGS
+++ b/contrib/mom/BUGS
@@ -26,6 +26,9 @@ Also, please--no html email. That, too, gets nuked.
Version 2.0-c
=
+Character translation of diacritics from lowercase to caps broken.
+---Fixed---
+
Spacing not being restored (.ns/.rs) after a HEADING that falls at
the top of the page.
---Fixed---
diff --git a/contrib/mom/om.tmac b/contrib/mom/om.tmac
index af7f8dd..dfed95a 100644
--- a/contrib/mom/om.tmac
+++ b/contrib/mom/om.tmac
@@ -745,17 +745,20 @@ end
\#
\# Inline kerning provides a simple way to adjust the amount of
\# space between any two letters. It's predicated on a unit of
-\# measure U, which is 1/36 of the current point size as returned
-\# by \n[.ps]. E.g., if the current point size is 18, \n[.ps]
-\# returns 18000u, therefore U=500u. Since U remains proportional
-\# relative to the current point size, the amount of kerning
-\# between two letters as expressed in Us remains visually similar
-\# regardless of changes in point size.
-\#
-\# N.B.--the amount of inline kerning supplied by \*[BUn] or
-\# \*[FUn] is added to or subtracted from any kerning that already
-\# takes place between two characters when automatic kerning is
-\# turned on.
+\# measure U, which, by default, is 1/36 of the current point
+\# size as returned by \n[.ps]; e.g., if the current point size is
+\# 18, \n[.ps] returns 18000u, therefore U=500u. Since U remains
+\# proportional relative to the current point size, the amount of
+\# kerning between two letters as expressed in Us remains visually
+\# similar regardless of changes in point size.
+\#
+\# The default value for U may be changed or reset with the
+\# KERN_UNIT macro.
+\#
+.MAC KERN_UNIT END
+.ie '\\$1'DEFAULT' .nr #KERN_UNIT 36
+.el .nr #KERN_UNIT \\$1
+.END
\#
.nr #KERN_UNIT 36
.ds BU \h'-(\En[#PT_SIZE]u/\n[#KERN_UNIT]u*\\$1u)'
@@ -3737,72 +3740,73 @@ end
.MAC CAPS END
.ie '\\$1'' \{\
. tr aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ
-. tr �\[`A]
-. tr �\[^A]
-. tr �\['A]
-. tr �\[:A]
-. tr �\[oA]
-. tr �\[~A]
-. tr �\[AE]
-. tr �\[`E]
-. tr �\[^E]
-. tr �\['E]
-. tr �\[:E]
-. tr �\[`I]
-. tr �\[^I]
-. tr �\['I]
-. tr �\[:I]
-. tr �\[`O]
-. tr �\[^O]
-. tr �\['O]
-. tr �\[:O]
-. tr �\[~O]
-. tr �\[/O]
-. tr �\[`U]
-. tr �\[^U]
-. tr �\['U]
-. tr �\[:U]
-. tr �\[,C]
-. tr �\[-D]
-. tr �\[~N]
-. tr �\[TP]
-. tr �\['Y]
-. tr �\[:Y]
+. tr \[`a]\[`A]
+. tr \[^a]\[^A]
+. tr \['a]\['A]
+. tr \[:a]\[:A]
+. tr \[oa]\[oA]
+. tr \[~a]\[~A]
+. tr \[ae]\[AE]
+. tr \[`e]\[`E]
+. tr \[^e]\[^E]
+. tr \['e]\['E]
+. tr \[:e]\[:E]
+. tr \[`i]\[`I]
+. tr \[^i]\[^I]
+. tr \['i]\['I]
+. tr \[:i]\[:I]
+. tr \[`o]\[`O]
+. tr \[^o]\[^O]
+. tr \['o]\['O]
+. tr \[:o]\[:O]
+. tr \[~o]\[~O]
+. tr \[/o]\[/O]
+. tr \[`u]\[`U]
+. tr \[^u]\[^U]
+. tr \['u]\['U]
+. tr \[:u]\[:U]
+. tr \[,c]\[,C]
+. tr \[-d]\[-D]
+. tr \[~n]\[~N]
+. tr \[Sd]\[-D]
+. tr \[Tp]\[TP]
+. tr \['y]\['Y]
+. tr \[:y]\[:Y]
. nr #CAPS_ON 1
.\}
.el \{\
. tr aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
-. tr �\[`a]
-. tr �\[^a]
-. tr �\['a]
-. tr �\[:a]
-. tr �\[oa]
-. tr �\[~a]
-. tr �\[ae]
-. tr �\[`e]
-. tr �\[^e]
-. tr �\['e]
-. tr �\[:e]
-. tr �\[`i]
-. tr �\[^i]
-. tr �\['i]
-. tr �\[:i]
-. tr �\[`o]
-. tr �\[^o]
-. tr �\['o]
-. tr �\[:o]
-. tr �\[~o]
-. tr �\[/o]
-. tr �\[`u]
-. tr �\[^u]
-. tr �\['u]
-. tr �\[:u]
-. tr �\[,c]
-. tr �\[Sd]
-. tr �\[~n]
-. tr �\[Tp]
-. tr �\['y]
-. tr �\[:y]
+. tr \[`a]\[`a]
+. tr \[^a]\[^a]
+. tr \['a]\['a]
+. tr \[:a]\[:a]
+. tr \[oa]\[oa]
+. tr \[~a]\[~a]
+. tr \[ae]\[ae]
+. tr \[`e]\[`e]
+. tr \[^e]\[^e]
+. tr \['e]\['e]
+. tr \[:e]\[:e]
+. tr \[`i]\[`i]
+. tr \[^i]\[^i]
+. tr \['i]\['i]
+. tr \[:i]\[:i]
+. tr \[`o]\[`o]
+. tr \[^o]\[^o]
+. tr \['o]\['o]
+. tr \[:o]\[:o
Re: [Groff] Using non-ASCII characters in mom
Per -- On Sat, Apr 26, 2014, Per Edin wrote: The problem is that any lower-case non-ASCII letters, such as å, in my .TITLE are not converted into an upper-case letters in my page headers. I'll provide you with a small sample file demonstrating the problem ASAP. Ah. This is unrelated to the error messages you've been seeing, ie, noname.mom:60: can't translate character code 229 to special character `oa' in transparent throughput I've fixed the problem and will be committing the updated om.tmac to the git repo and to mom's website in an hour or so. -- Peter Schaffter http://www.schaffter.ca
