Re: a question of hyphenation policy
Hi again Branden, I'll let others respond regarding the morality of dangling hyphens on the last line. :-) On 30/8/24 16:38, G. Branden Robinson wrote: At 2024-08-30T16:29:03+1000, Robert Thorsby wrote: I wouldn't call myself a typographer but I refuse to allow hyphens to break, usually via '.hy 0' or by using '\%'. I then kern the tripe out of any offending line, often using Ted Harding's "poor man's kerning" trick. Ooh, that sounds like something good to remind the youngsters of. Have a link handy? I've used Ted's "solution" for so long I have forgotten when he posted it. It is spectacularly simple, but finicky, to implement. With justified text you take a new line in your input, then \s[-X]\H[+X]text to be kerned goes here\H[0]\s0 Note, the value of X given to the opening pair of escapes must be equal but opposite in sign and must include a scaling unit. I always use "u" as the unit. Thus \s[+167u]\H[-167u] It works simply by reducing/increasing the pointsize by the stated amount and then immediately stretching/shrinking the vertical height of the type by an opposite amount. The right bookends simply reverse the effect. You can fiddle with the value of X in basic units until you get it "exact" or you can get it within a character or two of end-of-line and just add "\p". You may have to add a "\p" to the line before you start playing around. I have found that using values of X that bear some relationship with the pointsize you happen to be using is easier to work with. In the example 167u seems to be a good starting point for 12pt type, rather than (say) 150u. I have never been able to tell the difference on the printed page between the "unkerned" lines above and below and the intermediate "kerned" line(s). Of course, the difference is beyond any monitor's capabilities. Robert Thorsby
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 broken short). To me it sounds like this "solution" is worse than the problem. Without an optimizing paragraph-at-a-time algorithm like TeX has, which can retry the entire paragraph with different breakpoints, with roff's line-at-a-time approach only human intervention can really help. > \n[.hlc] Count of immediately preceding consecutive >hyphenated lines in environment. > > My question is: should a page break reset this count? If the register is made writable, this can be decided by the macro package, by writing a zero to the register when a new page is begun.
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 size using .ss often leads to acceptable results. Also, using \p (or .brp) to break-and-stretch a line earlier in a paragraph can sometimes lead to nicer line breaks later on in the paragraph.
[no subject]
> However, no matter what you do, you simply *cannot* end the last line > of a column or page with a hyphen.predicting Alas, it happens regularly in real life. The groff line-filling algorithm would have a hard time predicting a page break, for the break is usually the result of a yet-unseen .br, typically hidden in the text of a macro invoked by a line trap. Back to Branden's original question. I woulld expect the hyphenation count to be zero at the top of a column or page. Doug
Re: a question of hyphenation policy
On 30/8/24 20:54, Tadziu Hoffmann wrote: \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. I agree that if the distortion becomes visible then it was the wrong tool for the job. But I stand by my claim that reasonable distortions are totally invisible on the printed page. Tadziu, were you referring to your language (where I *think* hyphenation would always be necessary)? As a practical approach to manually optimizing the line breaks in a paragraph, I have found that twiddling the space size using .ss often leads to acceptable results. Also, using \p (or .brp) to break-and-stretch a line earlier in a paragraph can sometimes lead to nicer line breaks later on in the paragraph. Again, I agree that in the absence of whole-of-paragraph manipulation we are stuck with line-by-line manipulation. And this requires a lot of manual intervention, using every tool at hand. Remember, often this has to be done to resolve issues other than hyphenation (e.g., widows and orphans. In the final analysis, typesetting is an art not a science, and we will never be able to eliminate the requirement for human intervention. Scientific tools will assist us but they won't replace us. Robert Thorsby
Re:
On Fri, Aug 30, 2024, Douglas McIlroy wrote: > > However, no matter what you do, you simply *cannot* end the last line > > of a column or page with a hyphen.predicting > > Alas, it happens regularly in real life. > ... > Back to Branden's original question. I woulld expect the hyphenation count > to be zero at the top of a column or page. I concur with Doug on both points. As to squishing type to avoid hyphens (pseudo condensing), it is a strategy to be used at the utmost end of need. Small adjustments to letter- and word-spacing are always preferable. mom has macros to facilitate both (plus letter-pair kerning). Not sure about the other macro packages. That said, no matter how you tighten or loosen a line, it must not be noticeable. -- Peter Schaffter https://www.schaffter.ca
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 to hyphenation on multiple consecutive lines, which is sometimes stated as something to avoid. The point I was trying to make is that multiple consecutive hyphenated lines is still often the lesser evil compared to some of the proposed solutions. Personally, I have no problems with consecutive hyphenated lines at all, or even with hyphenating the last line of a page. What I find much more jarring is letterspacing words just to avoid larger interword spaces. I find the latter acceptable, but the former disruptive even at fairly small amounts.
"transparent" output and throughput, demystified
Hi folks,
Those of us who worked with groff 1.22.4 may remember a couple of
diagnostic messages that gobsmacked one with their incomprehensibility.
Here's the source code that produced them.
error("can't transparently output node at top level");
error("can't translate %1 to special character '%2'"
" in transparent throughput",
input_char_description(cc),
ci->nm.contents());
For groff 1.23.0, I silenced them with a blunt instrument, since I
concluded that they weren't entirely spurious, but nobody seemed to have
any idea what, exactly, anyone was supposed to do about them. In
general usage scenarios, a diagnostic that the user cannot address is a
diagnostic that should not be issued.
In a recent thread, Peter noted the resurrection of these messages.[1]
At that time, I promised an explanation of these long-vexing problems.
In the course of documenting my fix for Savannah #63074[2]--a process
that is fairly involved and not yet complete--I ended up writing a
change to the groff_diff(7) man page that seems to cover the bases.
Here's some language that I have queued up for my next push. First, a
comment from the man page source that summarizes where we (I) still have
work to do.
.\" TODO: When we get this giant headache generalized and adapted to the
.\" `\!` escape sequence and `device`, `output`, `cf`, and `trf`
.\" requests, move this discussion into a dedicated subsection above.
And now, the explanation.
groff_diff(7):
\X'contents' GNU troff transforms the argument to the device
control escape sequence to avoid leaking to device‐
independent output data that are unrepresentable in
that format, and to address the problem of expressing
character code points outside of the Unicode basic
Latin range in an output file format that restricts
itself to that range. (See subsection “Basic Latin”
of groff_char(7).) The typesetting of such
characters is a problem long‐solved in device‐
independent troff by the “C” command; see
groff_out(5). The expression of such characters in
other contexts, such as device extension commands,
was not addressed by the same design. Where
possible, GNU troff represents such characters in
device‐independent but non‐typesetting contexts using
its notation for Unicode special character escape
sequences; see subsection “Special character escape
forms” of groff_char(7).
GNU troff converts several ordinary characters that
typeset as non‐basic Latin code points to code points
outside that range to avoid confusion when these
characters are used in ways that are ultimately
visible, as in tag names for PDF bookmarks, which can
appear in a viewer’s navigation pane. These ordinary
characters are “'”, “-”, “^”, “`”, and “~”; others
are written as‐is.
Special characters that typeset as Unicode basic
Latin characters are translated to basic Latin
characters accordingly. For this transformation,
character translations and definitions are ignored.
So that any Unicode code point can be represented in
device extension commands, for example in an author’s
name in document metadata or as a usefully named
bookmark or hyperlink anchor, GNU troff translates
other special characters into their Unicode special
character notation. Special characters without a
Unicode representation, and escape sequences that do
not interpolate a sequence of ordinary and/or special
characters, produce warnings in category “char”.
I hope to boil some fat off of that.
I want to emphasize that error and warning diagnostics will remain
possible. But they should not occur when a document or macro package
attempts to do things that are "sane", like storing accented letters
appearing in an author's name or a section heading into a string and
that interpolating that string in a device extension/control escape
sequence.
Peter's mom(7) package is more muscular even than that; I've noticed
that in his example documents he is not shy even of including vertical
motions in author names.
contrib/mom/examples/mom-pdf.mom:.AUTHOR "Deri James" "\*[UP .5p]and" "Peter
Schaffter"
Inside the formatter, a vertical motion becomes a "node" and has no
possible representation in a device extension/control escape sequence.
In the future, I want the formatter to complain about such
imposs
Re: GNU maintainership update
Congrats, Branden! [1] https://xkcd.com/149/ Fixed that for you: [image: sandwich.png] On Sat, 31 Aug 2024 at 08:26, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > Hi folks, > > Bertrand and I have heard back from the GNU maintainers team. As of > yesterday, they have offered me the maintainer role for groff and I have > communicated my acceptance. > > I haven't received notification of any changed "permission bits" or > anything else, and don't expect to immediately, so for now I do not > regard anything as having logistically changed; if we needed to tag and > push groff 1.24.0.rc1 tomorrow, Bertrand would have to do it. > > Nevertheless we seem to be into the procedural, rather than the social, > part of the handover process, so I thought I'd let the community know. > > I don't expect to update the groff web page with my changed status until > I can "exercise maintainerly powers", as it were.[1] > > Regards, > Branden > > [1] https://xkcd.com/149/ > > I had a more apropos cartoon in mind, involving a ghost flying out > of a computer monitor and a caption reading "rootly powers", that is > at least 20 years old (a co-worker used to have it on his office > door), but I could not find it in a web search. Oh well. > > Maybe it was from Nemeth et al.'s Unix sysadmin book... >
GNU maintainership update
Hi folks, Bertrand and I have heard back from the GNU maintainers team. As of yesterday, they have offered me the maintainer role for groff and I have communicated my acceptance. I haven't received notification of any changed "permission bits" or anything else, and don't expect to immediately, so for now I do not regard anything as having logistically changed; if we needed to tag and push groff 1.24.0.rc1 tomorrow, Bertrand would have to do it. Nevertheless we seem to be into the procedural, rather than the social, part of the handover process, so I thought I'd let the community know. I don't expect to update the groff web page with my changed status until I can "exercise maintainerly powers", as it were.[1] Regards, Branden [1] https://xkcd.com/149/ I had a more apropos cartoon in mind, involving a ghost flying out of a computer monitor and a caption reading "rootly powers", that is at least 20 years old (a co-worker used to have it on his office door), but I could not find it in a web search. Oh well. Maybe it was from Nemeth et al.'s Unix sysadmin book... signature.asc Description: PGP signature
