Re: hyphenating non-english characters

> Unfortunately, I got stuck at this point, as the hyphenation file > that I used is encoded in latin1. Sorry for not including it, this > is the place I got the file from: > https://ctan.org/tex-archive/language/hungarian/hyphenation These patterns are very outdated. The current version of the

Re: an observation and proposal about hyphenation codes

> A fact I found noteworthy about how GNU troff actually sets up > hyphenation codes is that the equivalence classes it is designed to > support _are almost never used_ beyond lettercase coalescence.[1] Yes. As originally intended in TeX (and groff closely follows), the `.hcode` mechanism is use

Re: a morsel of groff 1.23.0 status

>> May I be excused some pride in our delivery of over 400 bug >> fixes and 150 automated tests? > > Fully justified. I'm glad it's finally out in the world. Thank you > for your tireless work in making groff more featureful, more > portable, better documented, and less buggy. Yeah, c

Re: wrong URW font directory used by gropdf

> Here's what I've worked up. [...] > > Comments? Unless someone convinces me that I've gone round the > bend, something like this will probably be in my next push. Looks good, thanks. Werner

Re: installed 'gropdf' incorrectly used for compilation

>> This inconsistency of gs on my GNU/Linux is of no importance, but >> it clearly shows that there is a bug while compiling groff: It uses >> `gropdf` from my system instead of using the just compiled >> `gropdf`! > > Are you sure? I cannot verify this hypothesis; whether I build > inside the

important Texinfo changes

Folks, the current git version of `texinfo.tex` (which will eventually become part of the next Texinfo version) has some important changes that heavily influence the layout of `@def*` commands. Since groff needs a lot of macro trickery to get good results I strongly suggest that you test the c

Re: Savannah bug->email gateway problems affecting groff

>> In the past couple days I've made several updates to groff Savannah >> tickets, which have always generated an immediate email to me and, >> not too long after, one in the lists.gnu.org archive of the >> bug-groff email list. Neither of these has been getting the emails >> since August 12. (

Re: installed 'gropdf' incorrectly used for compilation

>> Perhaps it makes sense to execute >> >> ``` >> strace -f make &> strace.log >> ``` >> >> and check the resulting logfile for all file accesses outside of the >> source and build directory, and whether they are expected. > > That's a good idea, if somewhat monstrous in its implications. > Ther

Re: installed 'gropdf' incorrectly used for compilation

> I think the correct fix for this is to update the Automake files to > set $GROFF_BIN_PATH to the build directory before running groff to > generate our own artifacts. There are only a few directories that > require this, all of which I think Ingo and/or I touched recently. > > Does that sound

Re: git-version-gen not working with Savannah/cgit snapshots

>> > I think that if GNU doesn't have the infrastructure or personnel >> > to support these, then, yes, the Savannah administrators should >> > fork (or just patch) cgit to the extent necessary to suppress the >> > exposure of these snapshot download links. I had no idea they >> > weren't truly s

Re: traveling for a few days

> I see one new warning in bootstrap output: > > +Notice from module non-recursive-gnulib-prefix-hack: > + This module is deprecated. Instead, > +- use the gnulib-tool option '--automake-subdir', > +- remove the explicit invocation of build-aux/prefix-gnulib-mk > + from y

Re: Portability to Mac OS X

>> > 6. Some time ago I bumped our minimum required Texinfo version to >> >5.0 (for a few reasons[5]), and this is too new for stock Mac >> >OS X (makeinfo 4.8). However, it should be possible to make >> >generated *.info files part of the distribution archive and >> >thereby red

Re: Git, where zombie branches shamble again

>> You absolutely _did_ rewrite history ... not just once, but twice! >> You deleted an _entire branch_ of published development history, >> then after my subsequent push had reinstated it, you deleted it >> once again! If that isn't rewriting history, then I'd like to know >> what you would call

Re: Portability to Mac OS X

> 6. Some time ago I bumped our minimum required Texinfo version to >5.0 (for a few reasons[5]), and this is too new for stock Mac OS >X (makeinfo 4.8). However, it should be possible to make >generated *.info files part of the distribution archive and >thereby reduce the depende

Re: Two trivial questions

>> I strongly discourage using any locale other than the C locale >> in your source code. > > I would never do such a thing. Heaven forfend! The question was > prompted by a mom user off list wondering about groff input files, > not macro programming. I suggest that numbers are input with `.`

Re: [groff] 02/11: doc/groff.texi: Fix style nits.

> * Use "e.g." and "i.e." correctly; that is, with a trailing > comma. Well, a lot of people from England would strongly disagree that this is 'correct', since those abbreviations are used there *without* a trailing comma... Of course, were the groff manual following an English writin

Re: Wanted: an HP TFM file to test hpftodit with

> Does anyone have one they can share, or, better yet, know of a > freely-licensed example HP TFM file? Sent something offline. Werner

Re: Modernising UNIX manpages.

>> I would like to investigate the possibility of using Markdown as an >> alternate format for UNIX man-pages. > > You picked the worst possible markup imaginable. Not just for man > pages, but for any technical documentation, *period*. If you're > interested in "modernising", I suggest rewriti

Re: Suggestions needed how to deal with tbl material in html output

> - Eric Raymond's doclifter. I failed because I could not construct > a minimal .ms document which would not be rejected by doclifter, and > every time I try the error message relates to "internal errors". I > fail at making doclifter accept documents as simple as the following > one: [...] N

Re: Hdtbl proposal to add separte vertical , horizontal cell spacing.

Nice! Note that there is a typo. > +. tm \\n[.F]:\\n[.c]: Invalid verctical cell spacing value '\\*[cspb]'. ^ Werner

Re: Huge Filesize of PS file 12M

> So thank you for the tip. I disabled the fonts in the /devps/download file > and it went from 12MB to 92K so that is already a big step forward. > Is there a better way to disable the embedding of fonts ? Not that I'm aware of. > Because I still see a lot of this : > " > grops begin/DEFS 1 di

Re: Huge Filesize of PS file 12M

Wim, > I'm generating my postscript file with my own macros for writing > company letters. But the generated filesize is 12MB for the PS > filesize. please, PLEASE, don't send such huuuge e-mails to a mailing list! Instead, upload it to a place temporarily where interested people can download

Re: End-of-sentence spacing

> I'm not completely sure it's true for all modern applications, but I > hope you're right that it doesn't hurt in general to explicitly type > two spaces after a sentence. As a dinosaur, that's what I used to > do, but trained myself out of it after reading a high-profile tirade > scolding me (at

Re: Current location of fixmp?

> Is there a recent version of the script 'fixmp' mentioned in the > MetaPost documentation? (It allows groff to accept MP-generated PS > files.) Sorry, no. Additionally, it seems that the current version of MetaPost (i.e., TeXLive 2020) is broken: it inserts unwanted '%' characters. > Google

Re: [groff] 03/09: tmac/an-old.tmac: Stop remapping ` and '.

There's a Linux version too, if you're interested: https://github.com/talamus/solarize-12x29-psf >>> >>> A pity there’s no OpenType version. >> >> Attached :-) > > Bitmap font embedded in a TTF? Yep. This should be portable, contrary to the PSF version. No idea whether a real outli

Re: [groff] 03/09: tmac/an-old.tmac: Stop remapping ` and '.

>> There's a Linux version too, if you're interested: >> https://github.com/talamus/solarize-12x29-psf > > A pity there’s no OpenType version. Attached :-) I converted the font using `psf2bdf.pl` and `fontforge` (followed by a normalization run using `ttx` twice to disassemble and reassemble th

Re: [groff] 03/09: tmac/an-old.tmac: Stop remapping ` and '.

>> To summarize: It seems that there is only a single platform left >> today that by default uses a bitmap font for terminals with >> symmetric ` and ' characters. This sort-of proves my point, >> doesn't it? > > What matters is that large numbers of manual pages use unescaped ' > and ` to repres

Re: [groff] 03/09: tmac/an-old.tmac: Stop remapping ` and '.

> It's called Sun Gallant Demi Thanks. > (or simply "Gallant", as no other weights or variations of it > exist). It's the default console font of SPARC workstations and > SunOS/Solaris; OK. > OpenBSD used to use it, until they switched to a much blander > console font

Re: [groff] 03/09: tmac/an-old.tmac: Stop remapping ` and '.

>> However, there exist virtually *zero* fonts that display ` as an >> acceptable left quote in a typographical way > > I'll just leave this here… > > [image: oUMj9e74.jpg] Nice! Which font is this? Werner

Re: [groff] 03/09: tmac/an-old.tmac: Stop remapping ` and '.

>> > Having `this' in a manpage is perfectly good typography, No, it's not – unfortunately. Today, this is only the TeX way to enter left and right single quotes. However, there exist virtually *zero* fonts that display ` as an acceptable left quote in a typographical way. Previously, ` and '

Re: Learning troff - where to start?

> Admittedly, it would be better to also credit the original authors, > not only the authors of the GNU reimplementation, as it is done > here, for example: > > https://mandoc.bsd.lv/man/man.7.html Mhmm, my name is missing... Anyway, there are some serious typos on that page, for example M

Re: Releasing groff 1.22.5?

> I think one of us who has sufficient privilege on Savannah should > grant the "Manager" role in the bugtracker to Dave. No problem. To do that, however, I need his account name on Savannah... Werner

Re: Releasing groff 1.22.5?

> The code in > > gnulib/lib/vasnprintf.c > > line 4879 puts a format string containing a %n directive into > writeable memory and subsequently passes that memory as a first > argument to printf(3). > > Using %n at all is insecure programming practice. [...] Please contact bug-gnu...@gnu.org

Re: Releasing groff 1.22.5?

> Just a question on the version though: We are talking about 1.23 and > not 1.23.0, and I see that we also had a 1.22 version (not a > 1.22.0), is there a particular reason to omit the patch number if it > is equal to 0? It looked nicer then for me, and I think I saw that for other GNU packages,

Re: Releasing groff 1.22.5?

> My main argument against that is a selfish one. Somebody would have > to go through all the Savannah tickets that are marked as fixed in > 1.22.5 and change them. Simply change the name of the label, and you are done. Internally, an ID gets used that is independent of the label name. W

Re: (off topic?) Docbook? Re: manlint?

>> This is similar in spirit to what Werner Lemberg started with >> devtag.tmac, [...] It was rather Gaius Mulley who started work on that. Werner

Re: [groff] 04/28: groff_char(7): Revise glyph descriptions.

>> > > -\[char223] \[char223] 223 germandbls u00DF German double s (sharp s) >> > > +\[char223] \[char223] 223 germandbls u00DF lowercase sharp s >> >> [there is no uppercase Eszett] >> >> Au contraire! It's U+1E9E, added in Unicode 5.0.[1] > > Also adopted by the Council for German Orthograph

Re: ATTN groff Savannah administrators: category request

> I'm either looking in the wrong place or we've found the source of the > trouble. I get no "Select Fields" item. Attaching screenshot. Your administrator bit was missing. Please try again. Werner

Re: ATTN groff Savannah administrators: category request

> Sorry for the somewhat loud subject line, but we don't often see > Werner or Bertrand on this list anymore and to my recollection, I've > never seen Vaibhaw[1]. I still read the list. > Can we have a Savannah bug category for "Macro - me", please? Added. > I'd do it myself, but even as a "ma

Re: problem with groff.texi: @ref{} in PDF and HTML fomats

> HTML output: > > A complete listing of all built-in registers can be found in see > Register Index. > > Here, the "see" is superfluous. This could be attributed to misuse > of the @ref macro in the source, Yes. > but then we have... > > PDF output: > > A complete listing

Re: [groff] 02/02: src/roff/troff/input.cpp: Update comments.

> Also bump copyright year; significant* non-cosmetic changes to > this file were made in 2019 and this year. (I know that a > script can be directed to come around and bump the copyright > year on this file even if, say, only whitespace changes were > made, or no changes at

Re: eqn sqrt and pdf?

> After producing the file with -P-e and -Tpdf, if you wish to reduce > the size of the pdf, use ps2pdf to process the pdf again, this will > subset the fonts. An alternative to that which compresses even better might be the `pdfsizeopt` script. https://github.com/pts/pdfsizeopt Werner

Re: man Macro Package and pdfmark

>> The info stuff alienates anyone who is not an emacs fan > > The standalone info(1) program, though? Please. I'm not going to > learn a second set of keybindings just to navigate online help. ??? Have you actually used stand-alone `info` recently? In its standard configuration, you only n

Re: man Macro Package and pdfmark

> And at this point, the man(7) language is better maintained and > appears to have more of a future than texinfo, which has been a lame > duck now for at least half a decade, probably longer: > Uh, oh, no idea why you bash texinfo from time to time. Currently, it receives more active developme

Re: GNUism in groff tests, was: pic anomalies

> A framework helps with none of that. But a framework can easily be > so heavy that it distracts from the actual job. Certainly, we don't > need a framework without content. I think the proper way for testing groff would be to make it run with a fuzzer, using some very simple and small input

Re: [groff] 02/04: grotty.1.man: Make editorial fixes.

> I have never used grotty. Reading the man page I wondered why one > would use it rather than nroff (which is absent from the SEE ALSO > list). You won't use grotty directly (except if you are going to construct the groff pipeline manually). It's the TTY backend of groff. In other words, if

Re: [groff] [patch] modernize -T ascii rendering of opening single quote

> I've always found the rendering of the asymetrical single quotes > like `this' quite odd, so I vote for. Many years ago, in the age of bitmap fonts, they *were* symmetric. However, the symbols are *intentionally* asymmetric today to avoid confusion with real quote characters. That I still use

Re: [groff] GNU troff version 1.22.4

>> I just need to make a few update on the groff website. >> >> Many thanks to everyone who contributed, tested and reported bugs. > > Congratulations are in order. I can't recall the last time there > was so much activity prior to a release. I add my voice to > Bertrand's thanks. Yeah, good

Re: [groff] Regularize (sub)section cross references.

>> > +.ie \\$1 .tr aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ >> > +.el .tr aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz >> >> The problem with this, is that it ignores all but english languages. > > Yup. I'm aware of that, which is why I did not propose it as an > actual

Re: [groff] "make doc" warnings on Debian buster

>> > For me, the doc build has been pretty noisy with TeX warnings, >> >> Which one? I've just pushed minor fixes, and now `groff.pdf' builds >> without warnings for me on the TeX side... > > I've been getting the attached warnings since I first started doing > "make doc" (by hand) months ago.

Re: [groff] [PATCH] man page patches for 1.22.4.rc5/final

> For me, the doc build has been pretty noisy with TeX warnings, Which one? I've just pushed minor fixes, and now `groff.pdf' builds without warnings for me on the TeX side... Werner

Re: [groff] 1.22.4.rc4 - Final RC before official 1.22.4

>> Cf. this message on the TeXLive mailing list. >> >> https://tug.org/pipermail/tex-live/2018-November/042697.html > > I only mention this because it's an error that has crept into our > documentation before (and which I've fixed). > > "Cf." means "compare" (Latin: "confere"). People seem t

Re: [groff] 1.22.4.rc4 - Final RC before official 1.22.4

> On Solaris 9, installation still fails because of the "for f in ; > do" we discussed earlier, and the test suite still fails as shown at > the end (no change in that respect), but i see no regressions from > your patch. I really see no reason to not fix this single spot that prevents installat

Re: [groff] 1.22.4.rc4 - Final RC before official 1.22.4

>> As soon as they are fixed I suggest we contact Nelson Beebe[*] to >> build and install the next RC on his (really impressive) zoo of >> operating systems. > > Sounds interesting, but what is it exactly? I've skimmed through > his home page (https://www.math.utah.edu/~beebe/) but haven't seen

Re: [groff] 1.22.4.rc4 - Final RC before official 1.22.4

> Anything in particular you want me to have a closer look at on > OpenBSD, Debian Jessie, or Solaris 9, 10, or 11? Thanks for checking the issues! As soon as they are fixed I suggest we contact Nelson Beebe[*] to build and install the next RC on his (really impressive) zoo of operating systems

Re: [groff] 04/04: tmac/sv.tmac: Set hyphenation flags to 48.

> and Ian Hinchliffe, Routledge 2013, section 12.4.1.1 (page 674): > > "Compound words may be divided into their separate > elements...Prefixes and suffixes may be treated the same way: > > an‐befall‐a juster‐bar o‐vän‐lig" > > Note the first and last examples. While

Re: [groff] problem with umlaut in string

> I use > > .ds BLD \f3\\$*\fP > > and > > this text is partly \*[BLD in bold face] > > to switch to bold face and back within a line of text. > > This works fine as long as there is no german umlaut in the argument > to BLD. > > With an umlaut, I get > > groff -Tps -k -t -mom -P-pa4 - >

Re: [groff] Bold v Italics: Dawn of Justice

Thanks, Brandon, for that list! > [how I present the difficult issue to the reader] > Because font styles are presentational rather than semantic, > conflicting traditions have arisen regarding which font styles should be > used to mark file or path names, > environment variables, > in-line lite

Re: [groff] 01/04: nroff(1): Fix style and content issues.

>> I agree with Ingo. Since ages such items have been tagged with >> boldface in most manpages. > > Oh, bummer. Vetoes from 2 committers is more of a fight than I > want. :-) It's definitely no fight – we are tremendously grateful for your work! >> Other man page readers like the one in the Mi

Re: [groff] 01/04: nroff(1): Fix style and content issues.

+ Set "@g@nroff", "groff", "grotty", and "locale"(1) in italics, not bold or roman. >>> [...] >>> > -.B @g@nroff >>> > +.I @g@nroff >>> >>> I think these particular B -> I changes are wrong and ought to be >>> reverted. I agree with Ingo. Since ages such items have been tagged with

Re: [groff] bug-groff autoresponder?

>> Dave, do you want to become admistrator of the `groff' and >> `bug-groff' mailing lists? > > I'm willing to, though if they frequently need prompt administrative > intervention, I may not be best suited for it (as the tardiness of > this reply illustrates). No problem! Most actions (like appr

Re: [groff] 01/04: grn(1): Make options discussion a section.

>> Also consistently double-quote multi-word arguments to the .SH >> macro, for consistency with the rest of the page and (most) other >> groff man pages. > > That's both useless and harmless - in a word, cargo cult. I disagree. Just imagine that you have a title with more than nine words: To be

Re: [groff] How to show all hyphenation points?

> [...] with the help of a few diversions and traps, as in the > attached example macros. It's somewhat hackish and perhaps not the > most compact code possible, but at least it's reasonably easy to > understand and to modify. Very nice! Werner

Re: [groff] How to show all hyphenation points?

>> a request that would print its argument with all hyphenation points >> visible I think this is not necessary. > What I see as the typical use is a nonce question about a > single word. That is trivially handled by > groff -a > .ll 1u > recapitulation > The result is marrred

Re: [groff] bug-groff autoresponder?

> Is it possible to configure bug-groff to autorespond to any email > that doesn't come from the Savannah bug tracker, telling the sender > that the tracker is the preferred place to report groff bugs? Probably yes. Dave, do you want to become admistrator of the `groff' and `bug-groff' mailing

Re: [groff] page location traps

> Since this behavior is (1) undocumented, (2) inconsistent across > historic roffs, and (3) arguably undesirable, is it accurate to call > it a bug and open a bug report on it? It's certainly worth to open a report so that the behaviour can either be fixed or accurately documented (whatever is

Re: [groff] Maintainer out of bounds

[Bjarni, please don't write one-sentence paragraphs all the time. This makes it very hard to read your posts.] I haven't followed this closely so sorry for reacting late. > 1) My contributions to "bug-groff" have been marked as "spam" from > 15th August 2018 (a comment to bug #54475). Indeed

Re: [groff] improve a few terminal renderings of special characters

> \[u2661] uni2661 u2661 white heart suit > \[u2662] uni2662 u2662 white diamond suit > > [...] Should these two characters be removed from the manual page? I don't object. > They were added by wl@ in the monster commit 48615a444 on > 2003-02-23, but the commit messag

Re: [groff] improve a few terminal renderings of special characters

> some time ago, we already improved the terminal renderings of many > characters, in particular mathematical ones. Having another look > at groff_char(7) and how it renders with groff versus mandoc, i > just fixed some issues in mandoc, but for the following cases, i > think it would be better to

Re: [groff] groff build problem

> using for the first time now OpenSuse Thumbleweed. Installed all tools (I > hope) > ./configure runs without problems. Had to do: > sudo ln -sf /usr/bin/aclocal /usr/bin/aclocal-1.13 If you install from git, please read `INSTALL.REPO'. The first step is to call ./bootstrap which should

Re: [groff] Accented Cyrillic characters

> There appears to be specific code in groff to explicitly *BREAK* the > return value of wcwidth(3). Actually, egregious mishandling of > wcwidth(3) is a quite common error in application programs, so groff > is certainly not alone here. Well... :-) > I'm not familiar with groff internals eith

Re: [groff] Accented Cyrillic characters

> I tried adding a line like > > u0301 0 0 0xCC81 > > to the R font for devutf8. But it doesn't work. Right idea, wrong code point :-) See my other e-mail. Werner

Re: [groff] Accented Cyrillic characters

> It boils down to persuading `\w', used by tbl(1), that the U+0301 takes > no space. > > $ groff -Tutf8 >/dev/null > .nr w \w'A' > .tm \nw > 24 > .nr w \w'\[u0435]' > .tm \nw > 24 > .nr w \w'\[u0435]\[u0301]' > .tm \nw > 48 > $ I

Re: [groff] man -Tdvi replaces $ by £

> https://savannah.gnu.org/bugs/index.php?54214 > https://savannah.gnu.org/bugs/index.php?54213 Thanks! Werner

Re: [groff] man -Tdvi replaces $ by £

> Hi! Now I found out that there is standard Knuth's font which > provides slanted dollar sign. It is however slanted, not real > italic. But still better then upright roman variant. > > It is in font cmbxsl10 at position 36 (ASCII $). Ah, ok. >> I don't have sufficient time to fix those two b

Re: [groff] vertical resolution

>> I agree that the explanation of \n[.H] and \n[.V] is a bit sparse. > > Based on your and Tadziu's explanations, I wrote this possible > addition to the info file to explain these registers more > thoroughly. Suggestions for improvements are welcome. > > "Although groff's basic unit is device

Re: [groff] vertical resolution and page location traps

>> > Reason is that traps are not recursive, IIRC: Traps are not >> > handled while another trap is active (this seems to be missing in >> > the info file). > > But they are handled sequentially when a `.sp' passes more than one in a > single bound. Yes. >> > In other words, while your first tr

Re: [groff] vertical resolution and page location traps

>> The actual numbers returned under various conditions add only more >> confusion. >> >> $ groff -Tascii <<< '.tm \n(.V' > /dev/null >> 40 >> $ groff -Tps <<< '.tm \n(.V' > /dev/null >> 1 >> $ groff -Tpdf <<< '.tm \n(.V' > /dev/null >> 1 >> >> I don't see how the vertical resolution of the asc

Re: [groff] vertical resolution and page location traps

> I'm having trouble understanding the .V register and how it > interacts with page location traps. > > The info manual's sole phrase describing this register is "Vertical > resolution in basic units." This is less than illuminating because > it doesn't address: basic units per what? A resolut

Re: [groff] man -Tdvi replaces $ by £

> grodvi invoked by man -Tdvi replaces all occurrences of dollar > character ($) by pound sterling character (£). Indeed. > .TH test 1 > .BI "perl example: " "$str =~ m/^[a-z]$/;" This example tries to use `$' within bold italic. However, the TeX CM font `cmbi10' doesn't provide this character

Re: [groff] hyphenation issues (PATCH)

> Here is, I think, the third iteration of the patch, taking into > account Ralph's feedback on the length and overworked nature of the > previous iteration's diagnostic messages. LGTM, thanks! Werner

Re: [groff] hyphenation issues

> @Example > .ll 1 > .hy 48 > @endExample > > It seems the word "splitting" should be on a third input line (after > the .hy request). Fixed, thanks. Werner

Re: [groff] hyphenation issues

>> > + static int n_max = (HYPHEN_NOT_LAST_LINE | HYPHEN_NOT_LAST_CHARS >> > +| HYPHEN_NOT_FIRST_CHARS | HYPHEN_LAST_CHAR >> > +| HYPHEN_FIRST_CHAR); >> >> s/static int/int const/? Please use `const int' – there is no single instance of `int const' in the groff code. >> Given the enum,

Re: [groff] hyphenation issues

> Going forward, should groff generate a warning if a document > contains an undefined value of .hy, so that this problem will not > recur with any future changes? This makes sense. I currently can't remember whether other, similar flag registers exhibit similar behaviour. Werner

Re: [groff] \n[.Y] in release candidates

> Or even simpler > > .ds Ystring \n[.Y] > .while (\B'\*[Ystring]' = 0) .chop Ystring > . > .if (\n[.g] \ >& ((\n[.x] > 1) \ > : ((\n[.x] == 1) & (\n[.y] > 20)) \ > : ((\n[.x] == 1) & (\n[.y] == 20) & (\*[Ystring] >= 2 \{\ > . warn (\n[.warn] - (\n[.warn

Re: [groff] \n[.Y] in release candidates

> Here it is. > > .ds Ystring \n[.Y] > .while (\B'\*[Ystring]' = 0) .chop Ystring > .nr Ynumber \*[Ystring] > . > .if (\n[.g] \ >& ((\n[.x] > 1) \ > : ((\n[.x] == 1) & (\n[.y] > 20)) \ > : ((\n[.x] == 1) & (\n[.y] == 20) & (\n[Ynumber] >= 2 \{\ > . warn

Re: [groff] \n[.Y] in release candidates

> In groff 1.22.4.rc2: > > $ echo '\n[.Y]' | nroff | grep . > 4.rc2 > > I can see why this happens, of course; but it seems odd for a number > register to contain non-numeric data. Not at all. There are many number registers that return strings. > Failing that, can anyone suggest an improv

Re: [groff] groff@gnu.org

>> Adding more invalid hyphenation points only happens if you use an >> incorrect (i.e., a too small) value for lefthyphenmin and/or >> righthyphenmin. > > I do not profess to know anything about the hyphenation algorithm, > but this statement suggests to me that inconsistent ("incorrect") > comb

Re: [groff] The hyphenation algorithm produces wrong results

>> > .ll 1n >> > .hy 48 >> >> You *must not* use such values if the patterns don't allow it! >> From groff.texi: >> > I may. That is what testing is about. And I must, otherwise it > is an insufficient testing. Well, yes, for testing. And you have to expect incorrect results. >> instead o

Re: [groff] I hate git-version-gen

>>> I doubt that nowadays, anybody still uses the native build system >>> to install self-compiled software directly into the operating >>> system, >> >> I do this all the time. > > O really? Surprising. Everybody else i talked to about such things > during the last years said they don't do it

Re: [groff] I hate git-version-gen

> My usual procedure is to git pull, build a distribution tarball in > the standard way described in INSTALL.REPO, then build an > installable package from that with the standard OpenBSD packaging > system, which, in a nutshell > > 1. extracts the tarball > 2. applies distribution patches (mino

Re: [groff] I hate git-version-gen

> git-version-gen is a very serious nuisance. Actually, I like it. > It efficiently prevents any kind of reliable testing. What do you mean with `reliable testing'? I've never encountered such issues, so please elaborate on your setup. Werner

Re: [groff] Release Candidate 1.22.3.rc1

> Would it be possible to include these simple fixes in 1.22.4? > > https://lists.gnu.org/archive/html/groff/2017-02/msg00015.html > https://lists.gnu.org/archive/html/groff/2017-02/msg00017.html LGTM. > And maybe also this one; [...] > > https://lists.gnu.org/archive/html/groff/2017-02/

Re: [groff] hyphenation issues

> Just one remark on the 'NEWS' file: you added new entries in the > 1.22.3 version, shouldn't these belong to a new 1.22.4 paragraph? Oops, yes. Thanks for noticing, fixed in git now. Werner

Re: [groff] The hyphenation algorithm produces wrong results

>> As mentioned above, the hyphenation patterns are constructed with >> certain \lefthyphenmin and \righthyphenmin values. However, those >> values are *not* present in the hyphenation patterns – you have to >> know them (I consider this a design bug in TeX). In other words, >> only the user kno

Re: [groff] The hyphenation algorithm produces wrong results

> .ll 1n > .hy 48 You *must not* use such values if the patterns don't allow it! From groff.texi: For historical reasons the default value of the @code{hy} request doesn't fit the American English hyphenation patterns that are used by groff as the default. These patterns expect that neit

[groff] hyphenation issues

Folks, I've just fixed some hyphenation issues. o The `.hy' request should now work as documented (again). Additionally, I've added values 16 and 32 to hyphenate before the last and after the first character, respectively. There exist languages (most notably Greek) that indeed allow (and

Re: [groff] Merge conflict for "gnulib"

> From git://git.savannah.gnu.org/groff > * branch master -> FETCH_HEAD > warning: Failed to merge submodule gnulib (commits don't follow merge-base) > Auto-merging gnulib > CONFLICT (submodule): Merge conflict in gnulib > Auto-merging contrib/mom/om.tmac-u > Removing VERSION > R

Re: [groff] version and revision management

> In order to track more finely the version used when people report an > issue, I propose to use gnulib's script 'git-version-gen' to > generate a unique version. Yes! > Note: the full version is propagated in the various executables > generated by the build system (for example 'groff --verrsion

Re: [groff] A typo on fsf groff wiki page, and question about releasing

>> Also, groff code is quite old and looks more like 'C with class' >> and doesn't use templates > > Yes, that's in it's favour, as you say. Indeed! Today, I would vote for introducing templates in a very light way, but in general I like the groff coding style. Werner

  1   2   3   4   5   6   7   8   9   10   >