Re: Proposed: Rename "scaled points" + Rationale behind "scaled points"

> AT&T troff stores font size in points. This means it > converts the argument to .ps from whatever unit it's in > (default is points) to basic units and then divides that > by the size of 1 point. Did AT&T troff actually allow the argument to .ps to be in anything other than points? The Manual

Re: a multilingual hyphenation challenge

> > But French would allow hyphenation of "commonplaces". > Would it? Funnily yes, and this had me initially confused. Try: .hla fr .hpf hyphen.fr .hla en .hpf hyphen.us .sp .ev epigram .hla fr .rj 1 L'homme c'est rien\[em]l'\[oe]uvre c'est tout. .ev .sp My life is spe

Re: a multilingual hyphenation challenge

> Notably, this design doesn't _prevent_ anyone changing hyphenation > language when they switch environments -- it just doesn't do it > automatically. That is, it covers the common case, but gives the user > flexibility to handle other cases. With the scope of both hyphenation > mode and hyphe

Re: a multilingual hyphenation challenge

> In other words, hyphenation language setting is not local > to the environment... But French would allow hyphenation of "commonplaces".

Re: a multilingual hyphenation challenge

> [...] explain why the word "commonplaces" hyphenates in the > second exhibit but not the first. Interesting! It's not clear from the documentation why it behaves this way (or even, once you know how to fix it, what specifically the solution changes in the internal state to make it work and w

Re: ripgrep author seems happy with groff_man_style(7)

> when designing a markup language, permitting the inclusion > of chunks written in a different markup language is usually > terrible language design. Isn't that what tbl, pic, chem, and all the rest are? So far the idea has worked quite well over the years.

Re: Proposed: QS/QE macros for quotation in man(7)

> > Attached is a PDF showing the differences. If you zoom > > in, you can see that the \[lq] in IBM Courier, which is > > bottom-heavy (like the \[lq] in Times), is not the same > > as \[rq] in Adobe Courier, which is top-heavy. > > I get that, but by using \[lq] and \[rq] you end up with a >

Re: Proposed: QS/QE macros for quotation in man(7)

> From that message I get the impression that your claim of > \[Bq] and \[lq] being "terrible advice" was quite overstated; > it seems to come down to a small number of bad typefaces. Are they, though? Even in English, there exist different styles of quote characters, as exemplified by IBM's vs

Re: Proposed: QS/QE macros for quotation in man(7)

> In any case, as far as I know, \[Bq] and \[lq] is the way to > obtain German-style quotes in groff. If you know of a better > way, tell me, please. We had a discussion on this topic some time ago on this list, see https://lists.gnu.org/archive/html/groff/2007-08/msg00115.html The problem

Re: Proposed: QS/QE macros for quotation in man(7)

> so that English users get \[lq] and \[rq] while German users > get \[Bq] and \[lq] etc. That is terrible advice. While the "English left quote" in Times is identical to the "German right quote" in Times, this is not true for Courier. It would be much better to define "German left quote" and

Re: Novel use of .char

> I wrote "pdf: pdfpic" to mimic the behaviour of .PSPIC, > render image down from current point, [...] > The above difference means this works for pdf:- > > .char \[gnu] \v'-9p'\X'pdf: pdfpic GNU-head-small.pdf -L 10p'\h'10p' > A GNU head \[gnu] image. Thanks for the feedback! This solut

Re: Novel use of .char

> Putting the motions in the diversion was how I went about it first. > When that didn't pan out, I went the string route, which was when I > discovered the diversion needed an actual glyph in it in order to > work as I hoped. Just out of curiosity, was displaying the image the only purpose of t

Re: Novel use of .char

> Wrapping a diversion inside a character definition is indeed a > novel thing to do. At first blush, I admire the creativity. > At second blush, the prescriptivist and black-gloved input > validator in me recoils. ("Why isn't this banned?" he roars.) > My third reaction is as a system designer

Re: [PATCH groff] tmac/hyphenex.en: add patterns for sequestrate & its derivates

> With that said, not being a native speaker, if I had to turn "sequestration" > into a verb, I would say "sequestrate" too and it would sound right to me... There are a few other words that don't follow the pattern. "filtrate" is the fluid that has been filtered, but I don't think "to filtrate"

Re: Differences in `ne` and `bp` line-breaking behavior

> `sp` has a noteworthy limitation. > > .sp dist [...] > dist is ignored inside a diversion. This is not true. (See below.) > Check the final sentence. `ne` inherits this limitation. In > a diversion, you can ask `ne` for tons of space, but you'll > only get 1v at a time. Eve

Re: Differences in `ne` and `bp` line-breaking behavior

> Also .ne is effective in the absence of traps, a fact > that groff(7) misses, too. In groff at least, the page bottom acts like a trap, consistent with register .t (distance to the next trap) showing the distance to the page bottom in the absence of any other (nearer) traps.

Re: Differences in `ne` and `bp` line-breaking behavior

> Later in the same page we have this: > [...] > Does that cover the base in question? The request synopses are > supposed to be really terse, following the CSTR #54 model and > serve as a refresher for the experienced. The basic fact that > moving the drawing position to (or past) a vertical

Re: Differences in `ne` and `bp` line-breaking behavior

>.ne Advance drawing position to the next vertical position > trap if it is nearer than one vee. >.ne d Advance drawing position to the next vertical position > trap if it is nearer than distance d (default scaling > uni

Re: Differences in `ne` and `bp` line-breaking behavior

> > I have discovered recently that `ne` and `bp` behave differently in > > regards to pending input lines. `bp` breaks such lines, while `ne` > > does not. In practice this means that `ne` does not behave like a > > conditional `bp` as one would reasonably expect. > > I invented .ne 55 years ag

Re: [HTML] Command Missing

> I get an error "sh: line 1: missing: command not found" > And then: > Calling 'echo showpage | missing -q -dBATCH -dSAFER -dDEVICEHEIGHTPOINTS=792 > -dDEVICEWIDTHPOINTS=700 -dFIXEDMEDIA=true -sDEVICE=pnmraw -r100 > -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -sOutputFile=/tmp/groff-page-p9UCo9

Re: removing the .IX macro from the ms package in 1.23 breaks old documents

> > Of course the macro also needs to be upgraded to properly format > > multi-line TOC entries, but that's a different problem. > Anyone want to volunteer? :) I just realized it is not necessary. The TOC mechanism in ms is very general. It requires the user to provide content for the TOC bet

Re: removing the .IX macro from the ms package in 1.23 breaks old documents

> If we establish that this is a bug [...] > But I need evidence of that, and as yet I don't have it. I don't have any evidence other than a) empirically, it fixes Joerg's problem. b) logically, it is necessary, as the leaders and the pagenumber are attached to the end of the line, so

Re: removing the .IX macro from the ms package in 1.23 breaks old documents

> the most serious one is misalignment of page number column > for entries which are long but seemingly fail to line > break early enough. there are also instances where the line > break just occurs too late w/o causing page number column > misalignment (this seems to be the case when no further

Re: How \c works (was: removing the .IX macro from the ms package in 1.23 breaks old documents)

> we already have a means of input line continuation [...] Not in the sense that the input line can be interrupted by some other processing and then continued. But we do have a workaround for this situation: append material to a string until the full line has been assembled, and then feed it in

Re: removing the .IX macro from the ms package in 1.23 breaks old documents

> . I must have been blissfully unaware of this discussion. However, I want to caution against the idea that "\c" continues an *input* line. "\c" is something that concerns the *output*. I.e., foo\c bar is *two* input lines

Re: opposite of \c?

> but i can't figure out how to inhibit the space for > the end quote inside the macro, so it ends up like > > 'wow wow the text is quoted ' > > is there an escape or a request that allows for this? Many times have I wished for such a feature to exist, but there is no equivalent to "\c" that ca

Re: drawing requests following the line

> (Should we raise this issue again? Nothing ever seems to > get done no matter how much we discuss it.) I think this is because it's not really something that many users badly require. (I certainly don't.) Continuous underlining can probably only be done well by treating it as a character a

Re: .CW usage by a new user

> I am translating to Spanish the book "Introduction to the command line" > Attached is an image showing that I made it. In your case you are intending those double quotes to directly become characters in the output (as opposed to them being used internally as delimiters for macro arguments). I

Re: .CW usage by a new user

> .CW "this phrase is spicy with \[lq]Courier\[rq] powder" . Also, within a double-quoted request or macro argument, you can use a double double-quote to get a single double-quote in the argument: .CW "| ` ' \[aq] \[lq] \[rq] \[dq] "" |" but you'll only need this if you're typesetting comput

Re: groff Digest, Vol 239, Issue 2

> Unfortunately pic chops broken lines into separate segments, > so it can't directly fill general polygons. But then again, the nice thing about pic doing this is that its dashed lines always begin and end with a stroked segment. Many programs don't get this right. And the nice thing about usi

Re: a boundary-pushing challenge for drawing commands

> How does the formatter know which parts to fill? In the case of groff (I can't say anything about the original troff), I don't think the formatter actually knows or cares, but simply passes the path on to the device postprocessor, which just incorporates it into the device-dependent output, to

Re: a question of hyphenation policy

> > I believe distorting the shapes of letters is even more frowned > > upon in typesetting circles than consecutive hyphenation is. > > Tadziu, were you referring to your language (where I *think* > hyphenation would always be necessary)? Sorry if my wording was a bit vague. I was referring t

Re: a question of hyphenation policy

> \s[-X]\H[+X]text to be kerned goes here\H[0]\s0 I believe distorting the shapes of letters is even more frowned upon in typesetting circles than consecutive hyphenation is. As a practical approach to manually optimizing the line breaks in a paragraph, I have found that twiddling the space siz

Re: a question of hyphenation policy

> .hlm nSet the consecutive automatically hyphenated line limit >to to n. A negative value means "no limit". What happens after that count is reached is that the next line is stretched wide, simply to avoid hyphenation (unless .na is used, in which case the line is simply broke

Re: Rendering the em dash on the terminal

I suspect conventions might be strongly regionally dependent. > - Em-dashes are represented by two hyphens with no space > either side--visually easy to understand. > > - En-dashes are represented by a single hyphen > surrounded by spaces (e.g. 2 - 3 minutes). I believe this should be rever

Re: magazine style end marks

> For a small fanzine project I want to typeset magazine > style end marks [1]. Particularly I want to include the > authors handle or name in the end mark, like seen for > instance in some articles like in this issue of the > Space Gamer Magazine [2]. How about this (see attachment)? It prints

Re: vim :hardcopy equivalent

> I will defend my formulation. `sp` _does_ position the > text baseline, period. I concur. It positions every part of the line. I simply did not want anyone to get the impression that ".sp |3c" would put the _baseline_ at 3 cm from the top. Also, in this case the baseline will only _normall

Re: vim :hardcopy equivalent

> > a "margin" measures an extent of whitespace (or "negative space"), > > whereas the `sp` request positions the _text baseline_, The first is correct and the second incorrect for [g]troff. In troff (and nroff), if you say .sp |0 then this does not mean "put the baseline at the top of the pa

Re: Oversized Tables - how to produce non-truncated PDF?

> some of the huge tables which in my original sources spread > over two book pages, appear truncated by the PDF, no matter > what papersize I try to set (e.g. like A3). The default column separation is 3 ens. We can make the table a bit narrower by reducing this to 2 ens, lb2 s2 s2 s2 s2 s2

Re: vertical spacing trivia challenge

[Spoilers ahead.] > A Question: is the `vs` request (which sets the vertical spacing) > honored in nroff mode? Yes. > B. In nroff (or nroff mode in groff), what _units_ is the argument > to the `vs` request reckoned in? I remember .vs always being given in points, with a default v

Re: On the term "justification"

> [2] Maybe introducing a replacement term, "rotated"--which is > unused in the GNU pic manual except to define "aligned"--would > be a good idea [...] I don't think this is a good idea. "aligned" in pic means the direction of the text is aligned with the direction of the object: .PS arro

Re: Draft v2: London and Reiser's UNIX/32V paper, reconstructed

> More precisely, you get the Death Star, not the Wehrmacht helmet. > The latter is what appears in 32vscan.pdf. > > Be nice to include that. Wikipedia has an SVG of the logo, but it's a bit asymmetric. Instead of trying to fix it I decided to draw a new one, based on a bitmap image I found on

Re: *roff hyphenation trivia challenge

> Which would be better? > > 1. Change GNU troff to not write out a hyphen if the > hyphenation control escape sequence is at the end > of the word. > > 2. Change GNU troff to not reënable automatic > hyphenation after encountering a non-initial > hyphenation control escape se

Re: *roff hyphenation trivia challenge

> $ printf '.ll 8n\n\\%%antidisestablishmen\\%%tarianism\\%%\n' \ > | nroff -Wbreak | cat -s > antidisestablishmen- > tarianism- > > I don't think we can tolerate that trailing hyphen. Yes, that's why we have to use "\&\%" at the end.

Re: *roff hyphenation trivia challenge

> Groff already *does* ignore correct hyphenation points, > namely before the first "\%" (but allows them afterward). > > My concern is that if "\%" only allows specifying > *additional* hyphenation points, then we have no method > of forbidding hyphenation points that the patterns > incorrectly

Re: *roff hyphenation trivia challenge

> I prefer groff's behaviour because I don't ever want correct > hyphenation points to be ignored. Using \% is almost always a > correction to the hyphenation logic. Groff's current behavior is weirdly inconsistent. It already *does* ignore correct hyphenation points, namely before the first "\%

Re: *roff hyphenation trivia challenge

> > Also interesting to see that in this word, the hyphenation > > patterns don't suggest a hyphenation opportunity after "anti". > The leading `\%` prevents that. Sorry, I meant even without "\%". With a line length of 1 en, and without any "\%" at all, groff prints an- tidis- es- t

Re: *roff hyphenation trivia challenge

> Predict the output of the following *roff input. > [...] I guessed wrong. And Heirloom nroff behaves differently from groff. Some more unexpected behavior can be seen by shortening the line length to just 1 en. I also tried the same thing in TeX and learned that by default TeX doesn't hyphe

Re: the Courier font family and nroff history

> (I use a bitmap font because it's substantially more readable > for long periods of time than any TrueType font I've found at > equivalent sizes, but using a bitmap font disables some of > xterm's font family support.) The xterm source can be hacked to provide italics using the classic bitmap f

Re: Accent mystery

> However, pdfmom is supposed to accept all the same > options as groff. Here, it does not, since "-Kutf8 -k" is > acceptable to groff. > > groff -Tpdf -Kutf8 -k -mom timeline.mom > timeline.pdf > > works but > > pdfmom -Kutf8 -k timeline.mom > timeline.pdf > > fails. In the perl script

Re: Accent mystery

> Processed with > pdfmom -Kutf8 -k timeline.mom > timeline.pdf > the é is garbage. If I swap the order of the options: pdfmom -k -Kutf8 timeline.mom >timeline.pdf or leave out the "-k" entirely (since it is implied by "-K"): pdfmom -Kutf8 timeline.mom >timeline.pdf it works on my mac

Re: Proposed: make \X read its argument in copy mode

> > \fB\s(12\m[red]\X'ps: big bold red text in my device command'\fP > \X'ps: exec 1.0 0 0 setrgbcolor /Times-Bold findfont \n[.s] scalefont setfont > (Text) show' This assumes you know both the desired font and the desired color, which might be defined at other places in the document and not u

Re: the 'SS' (slanted symbol) font (was: Original print of V7 manual? / My own version of troff)

> For people producing greek documents who wish to use eqn, > I did some testing, using the Tinos family of fonts (R, I, > B, BI) which include greek glyphs and SS font for gropdf. > The attached pdf shows the results with the different > fonts colour coded. Nice! How did you do the color coding

Re: the 'SS' (slanted symbol) font (was: Original print of V7 manual? / My own version of troff)

> The ordering of the S and SS fonts is immaterial here because > the C/A/T _had_ no SS font. > Nor do I see any of evidence of an "SS" font for _any_ device > in Documenter's Workbench 3.3 troff. > Barring evidence of pre-groff usage, then, I submit that the > slanted symbol font must be a groff

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

> Note that there is no SS for 'devpdf'. So, from where does > -Tpdf find (or construct) the slanted versions of the Greek > letters if the standard symbol font has upright Greek letters? > Or are the two 'S' fonts different for -Tpdf and -Tps? In the current groff release, the slanted Greek cha

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

[Redirected to the list, since I believe it is of general interest.] > > Which character (slanted or upright) groff uses simply depends > > on the mounting order of the fonts S and SS. > > > > [...] > I never knew this. Where is the reference please? > I would like to mention this in my new

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

> AT&T troff was engineered around the assumption that the > lowercase Greek letters typically used for mathematical and > scientific typesetting are slanted/italic rather than upright. > This assumption is baked into the semantics of special > character names *a, *b, *g, and so forth. > [...] >

Re: gpic and 8-bit characters (was: Proposed GNU troff behavior change: require end-of-input macros to exit)

> > So because both being above ASCII (8 bit area), > ASCII is not an 8-bit code. It is a 7-bit code, [...] Latin-1 is a superset of ASCII, with ASCII occupying the lower half, so technically I would argue that the above statement "being above ASCII" (namely, being in the area where the eighth

Re: Regarding groff, soelim, and macros

> Can we create documents that have chapters, sections, > that are in separate files? How can we do this? Use the method you already described that works: source the files directly from the main document, not from within a macro. > Now if I run this main file using > (cat main.tr | groff -p -

Re: inconsistent behavior of eqn bar operator

> If you put a bar over a string of As, the length of the bar increases > by the same amount for every A you add, but that amount is not the > length of a bar over a lone A. > This nonuniformity is unfortunate. This appears to be by design. The manual page says: accent_widthWhen bar or

Re: Leaders

> The example was enormously helpful. There's light at the end > of my TOC multi-line entry tunnel. Happy to be of help! Note that the example was simplified to illustrate the principle, and would need some (minor) aesthetic tweaks for practical application. Most importantly, you will want the

Re: Leaders

> Rare? Maybe. But not so rare that a macro package need not > be prepared for it. I think leaders are meant to be used in conjunction with diversions. When they are used in already formatted text, all required dimensions are known, allowing n/troff to compute the number of leader character re

Re: Footer trap in a A4 PDF

> A slight change and you can colour the margins with pure troff > so it works for both postscript and pdf:- Very good! Your example also demonstrates how setting the vertical spacing to zero allows directly positioning the baseline (which is the reference position for "\D" drawing commands) wi

Re: Footer trap in a A4 PDF

> How should I proceed to achieve precise margin sizes? There's two things to consider here. One: the trap is sprung when a line is output that reaches OR SWEEPS PAST the trap position. If you set your trap at -2 cm, then an output line may nevertheless still intrude into the bottom margin of 2

Re: Footer trap in a A4 PDF

> I would expect the word "footer" to pop up at -2c from the page bottom, > then a page break. Footer does pop up, and there's the page break too, > however it does not show up at -2c from the bottom. It's lower. It is working as intended. When you say ".sp |0c" in troff, that does not mean tha

Re: Weird in-line trivial EQN issue with 1.22.4 - bad font number

> > It's an issue with eqn material inside a macro definition. > > To avoid expanding eqn-generated escapes at macro definition > > time, bracket the macro definition with ".ec #" (or some other > > unused character) and ".ec" (to restore backslash as the escape > > character after the macro defi

Re: Weird in-line trivial EQN issue with 1.22.4 - bad font number

It's an issue with eqn material inside a macro definition. To avoid expanding eqn-generated escapes at macro definition time, bracket the macro definition with ".ec #" (or some other unused character) and ".ec" (to restore backslash as the escape character after the macro definition). This way,

Re: Weird in-line trivial EQN issue with 1.22.4 - bad font number

> .EQ > delim ## > .EN > [] which will not fit into the #p# bits > > which breaks 'groff' with 'bad font number' messages. I can't reproduce this, it works as intended on my machine. Are you running any other preprocessors, and if yes, in which order? What does the

Re: Help wanted: just run gxditview on your system and click

> gxditview from 1.22.4 freshly compiled on Opensuse 15.4 works > (all menu items). Also, this is straight X11, no Wayland involved.

Re: Help wanted: just run gxditview on your system and click

> Just run "gxditview", left-click in the big yellow canvas area, > and try to select _any_ menu item. gxditview from 1.22.4 freshly compiled on Opensuse 15.4 works (all menu items).

Re: widows vs orphans

> What do our resident typographers regard as a widow and an orphan? Not an expert, but I thought the mnemonic was that orphans become isolated at the beginning of their lives, and widows at the end of their lives. Correspondingly, an orphan is the first line of a paragraph that gets separated

Re: Using -Tpdf rather than -Tps and then ps2pdf

> I think the likeliest site to fix PDF output is the `pdf:SS` > macro in pdf.tmac. You are right. This works: .de pdf:SS .char \\$1 \s'n[.ps]u*89u/100u'\S'15'\\$1\S'0'\s'0' .. .pdf:SS \[*a] .pdf:SS \[*b] (etc.)

Re: Using -Tpdf rather than -Tps and then ps2pdf

> I tried two different methods of getting it to adjust the > font height, and neither worked at all. For me, the following works: .fzoom S 890 .EQ i iota .EN Unfortunately, this also scales the uppercase Greek letters and other mathematical symbols, which we don't want. In grops, we

Re: Using -Tpdf rather than -Tps and then ps2pdf

> But, the output direct to PDF from 'groff' does not match that of > going to Postscript and then converting that to PDF using 'ps2pdf'. The main difference that I can see is that in p8ps.pdf the symbol font has been scaled to match the x-height of the text font. In p8pdf.pdf the Greek letters

Re: Explanations with an EQN User Guide

> The tab is passed to groff as \t\, man 7 groff says \t is > "uninterpreted", yet the tab skips to a tab stop set by .ta. > This leaves me totally confused, because groff apparently > ignores \t when it doesn't come from eqn. If, as i believe, > eqn doesn't know about .ta and groff doesn't know

Re: Truncate the last lines of a diversion to another diversion

Since you're already diverting into TEXT when you expect the overflow to occur, you have to use a diversion trap instead of a page trap: .ll 20m .de CUT .di \" stop diverting into TEXT... .di TEXT2 \" ...and divert into TEXT2. .. .di TEXT .dt 1v CUT \" 1v into the diversion,

Re: Unexpected behaviour when using linenumbering and tbl

> What can be done to resolve this issue? One possible way would be to put .nr ln 0 after ".nm". Explanation: if you look at the output of tbl, you can see that tbl will issue ".nm" requests under certain circumstances, but apparently only if the line number register is nonzero.

Re: 3-word compound adjectives; the return of the '-'

> a) block device-based filesystems > b) block-device-based filesystems > c) block- device-based filesystems > d) block device\[en]based filesystems > > Which form would you recommend me to use? I would go with "block-device\[en]based filesystems", with the reasoning that a dash binds strong

Re: Fwd: Re: suspected `eqn' bug.

> This appears to be because "PI" is a magic token in eqn(1), > preferentially interpreted even in this context as a shorthand > for the capital Greek pi symbol; it is therefore replaced with > a special character escape sequence to access the > corresponding glyph, which is `\(*P`. warning: can

Re: Parallel Typesetting

> With a little more macro magic, I would assume it wouldn't be > too much trouble for both pages to have the same content for a > portion of it, such as with an illustration, say, or a math > equation. Indeed, that should be possible without much work. In the simplest case, one could just dupl

Re: Parallel Typesetting

> > I'm trying to see how much trouble it would be to typeset > > a bilingual text parallel by pages, as in, one language on > > the recto page, the other on the verso page, synchronized > > somehow by paragraph, preferably more or less automagically. > I would say you could do this with a numbe

Re: Parallel Typesetting

> I'm trying to see how much trouble it would be to typeset > a bilingual text parallel by pages, as in, one language on > the recto page, the other on the verso page, synchronized > somehow by paragraph, preferably more or less automagically. I would say you could do this with a number of custo

Re: Five glyphs: a minor PostScript challenge

> [...] glyph coverage of the special characters listed in > groff_char(7) for the PostScript output device. > As I understand it, the PostScript language has operators or > built-in functions for performing basic transformations like > reflection and skew. Just as a general note, I wanted to p

Re: Five glyphs: a minor PostScript challenge

> > A. \[-+]: The minus-plus. We should be able to dynamically generate > > this from \[+-] by reflecting the latter about a horizontal axis. If > > the glyph is flipped within its bounding box, I guess the result > > would need to be vertically shifted to align it on the baseline. > > T

Re: Equation Label wrongly positioned in indented '-mm' (MM) display

> This is a bug in groff's MM. Irrespective of the type of display, the > Equation number argument to .EQ should display on the right margin. You are right, it is a bug in groff's MM. Your fix does look reasonable. The real problem is that groff's MM's treatment of displayed equations is messe

Re: Equation Label wrongly positioned in indented '-mm' (MM) display

> If anybody wants to tell me a better way to fix the problem, > I would love to know. What about defining a new display style that only indents on the left, not on the right? I.e., add the following two lines to m.tmac at the appropriate places: .nr ds*format!6 6\" indent only on the lef

Re: Multiline Subject as PDF metadata

> .pdfinfo /Subject line 1\\nline\\n line 2 > does not work It seems the argument is reprocessed several times, so you need escape the backslashes accordingly. This appears to work: .pdfinfo /Subject line 1nline 2nline 3

Re: Multiline Subject as PDF metadata

> This metadata is held in the "document information dictionary" > of the pdf. In the pdf 1.4 standard the items > Title/Author/Keywords/Subject are all defined as text strings, > so I believe that precludes them from being multiline. You can embed \n into the strings, but not all programs will

Re: Is there any way to make alternate rows of a table have a light gray background?

> The problem occurs when your table spans pages. Since you > are creating the gray line _after_ the current line, > sometimes you get an extra gray line on the first page, and > other times you get a double gray line on the second page. Indeed. Just to clarify, filling the *next* line ahea

Re: How to align filled output line with tab stop?

> However, I want the output to be like this: I want the "Right" content > of the second input line to be aligned with the second tab stop. I also > want the long "Middle" content of the second input line to be filled > between the two tab stops. Like this: > > Left Middle...

Re: Should vertical motions be in vees or ems? Where does the baseline go?

> - General typographic convention is to measure vertical > motions in v's, not m's. CSTR #54's definitions of \u, \d, > and \r do not align with this common expectation. I think this depends on what you consider the purpose of \d and \u to be. Obviously they are not needed: everything they do

Re: weird behaviour of .sp| with expression

You are getting an overflow. The request > .sp |(\n[t1]+\n[t2])u does not do what you think it does. Section 1.4 "Numerical expressions" of the Troff User's Manual says In the presence of default scaling, the desired scale indicator must be attached to *every* number in an expression fo

Re: The 3-faces problem

> - It's all a single identifier, so breaking it into multiple > lines to avoid using \f would hurt readability. I think it's a matter of debate whether .RB [ U ] INT \fIN\fP _WIDTH or .RB [ U ] INT\c .IB N _WIDTH is more readable. In the latter at least it's obvious in which typeface

Re: pic doesn't center when i use a macro

> I can do something more manual but i really would like to take advantage > of the expressivity of pic. Any other comment is also warmly welcome. It looks like pic has no string variables, and the "if" works at the statement level, not expression level. To provide a somewhat constructive answe

Re: SEE ALSO fails

> If the proposal is to remove See Also's that aren't installed, I > could not be more against that idea. That just makes the system > harder to learn. I agree. Also, some of the manual pages reference Bell Labs Technical Reports or other papers that are hardly ever installed on any system. N

Re: Problems with .PDFPIC caused by pdfinfo

> grep: (standard input): binary file matches > you see, the \0 chars are already there. > What can I do? Is there a reason you need grep in there? You can work around the issue by removing the grep completely and do the filtering with sed: add the "-n" (no default output) command-line option w

Re: Align top of text blocks

> I noticed you removed the overlapping email domain, that was > an extreme example, but how do I go in order to define a > column width, i.e. when roff has to wrap the text? In this case you could use tbl (convenient) or do manually what tbl would do internally (gives you more freedom to fiddle

Re: Align top of text blocks

> I have three blocks of text on a line and I would like to align them > on top rather than on the baseline. > 1. Is there a "proper" way to achieve this? Since letters are not perfect rectangles, and you're mainly concerned with the aesthetic appeal of the end result rather than some "ideal" ma

Re: Man page quibble about .wh

> .wh N trap > Set condition trap; negative means from page bottom. I think it should say "set position trap", to distinguish it from other traps (e.g., input line count traps).

Re: "Can't break line warning"

> The horizontal line output by the \l escape is 6 inches, the same as the > declared line length. > troff: letterhead-demo.mm:31: warning [p 1, 0.5i]: can't break line You have a tab after the "\l'6i'", which counts as part of the line. Remove it, and the error disappears. \s+5World Reknown

  1   2   3   4   5   6   7   >