Re: [Groff] space width

2014-02-18 Thread James K. Lowden
On Sat, 25 Jan 2014 16:15:28 -0700 Dave Kemper wrote: > On 11/18/13, Tadziu Hoffmann wrote: > > In the original troff (according to the Troff User's Manual) > > a space was nominally 1/3 em and a thinspace was 1/6 em, > > thus half a normal space. In groff's TR font, a space > > is nominally 1/

Re: [Groff] space width

2014-02-06 Thread hohe72
Peter Schaffter wrote (Tue, 4 Feb 2014 11:32:00 -0500): > On Tue, Feb 04, 2014, Dave Kemper wrote: > > I understand the need for backwards compatibility, but I more and > > more find myself wishing groff had a global option to choose > > between "follow historical usage" and "be sane." For som

Re: [Groff] space width

2014-02-06 Thread Pierre-Jean
Peter Schaffter wrote: > I have to say I completely agree. Backward compatibility is > essential, but more and more, I wonder about future compatibility. > As far as I know, I'm the only person actively developing > a macro set for groff. I should claim here that I am also actively developping

Re: [Groff] space width

2014-02-06 Thread hohe72
Peter Schaffter wrote (Sun, 2 Feb 2014 00:03:58 -0500): > On Sat, Feb 01, 2014, hoh...@arcor.de wrote: > > > > Werner LEMBERG wrote (Wed, 29 Jan 2014 06:37:05 +0100 > > (CET)): > > > Given today's memory abundance and the high velocity of CPUs, the > > > ideal route would be to implement a do

Re: [Groff] space width

2014-02-04 Thread Walter Alejandro Iglesias
On Tue, Feb 04, 2014 at 11:32:00AM -0500, Peter Schaffter wrote: > On Tue, Feb 04, 2014, Dave Kemper wrote: >> I understand the need for backwards compatibility, but I more and more >> find myself wishing groff had a global option to choose between "follow >> historical usage" and "be sane." For s

Re: [Groff] space width

2014-02-04 Thread Peter Schaffter
On Tue, Feb 04, 2014, Tadziu Hoffmann wrote: > > > But that is no reason why a groff2 could not come into being. > > That also gets my vote as the best approach. Mine, too. My impression is that, under Werner's leadership, groff has been brought as far as it can be without crumbling under the w

Re: [Groff] space width

2014-02-04 Thread Tadziu Hoffmann
> But that is no reason why a groff2 could not come into being. That also gets my vote as the best approach. Take what we've learned working with groff and build a new formatter from scratch without the historical ballast. (Unfortunately, this will need a charismatic leader willing to spend muc

Re: [Groff] space width

2014-02-04 Thread Mike Bianchi
On Tue, Feb 04, 2014 at 11:32:00AM -0500, Peter Schaffter wrote: > ... What of > future macro programmers, though? How many who might contribute to > groff are going to shake their heads over what to them will seem > absurd anachronisms and simply move onto programming for something > unemcumbered

Re: [Groff] space width

2014-02-04 Thread Peter Schaffter
On Tue, Feb 04, 2014, Dave Kemper wrote: > I understand the need for backwards compatibility, but I more and more > find myself wishing groff had a global option to choose between "follow > historical usage" and "be sane." For someone in 2014 writing a new groff > document, there is zero advantage

Re: [Groff] space width

2014-02-04 Thread Dave Kemper
> '.cu' doesn't do what any sane person > would expect it to do for PostScript output I understand the need for backwards compatibility, but I more and more find myself wishing groff had a global option to choose between "follow historical usage" and "be sane." For someone in 2014 writing a new g

Re: [Groff] space width

2014-02-04 Thread Dave Kemper
On 2/1/14, Walter Alejandro Iglesias wrote: >> On Wed, Jan 29, 2014, Werner Lemberg wrote: >>> Given today's memory abundance and the high velocity of CPUs, the >>> ideal route would be to implement a document-wide algorithm for >>> typesetting a document (in contrast to TeX's page-wide approach).

Re: [Groff] space width

2014-02-01 Thread Peter Schaffter
On Sat, Feb 01, 2014, hoh...@arcor.de wrote: > > Werner LEMBERG wrote (Wed, 29 Jan 2014 06:37:05 +0100 > (CET)): > > Given today's memory abundance and the high velocity of CPUs, the > > ideal route would be to implement a document-wide algorithm for > > typesetting a document (in contrast to TeX

Re: [Groff] space width

2014-02-01 Thread hohe72
Werner LEMBERG wrote (Wed, 29 Jan 2014 06:37:05 +0100 (CET)): > Given today's memory abundance and the high velocity of CPUs, the > ideal route would be to implement a document-wide algorithm for > typesetting a document (in contrast to TeX's page-wide approach). I think, that an author can prev

Re: [Groff] space width

2014-02-01 Thread Werner LEMBERG
>> Letter-spacing is bad in general. > > I find this statement a bit too broad, especially in the context of > groff, whose only means of justifying lines presently is through the > expansion of wordspace, often with ghastly results. Well, even if it is the only possible solution in groff, letter-

Re: [Groff] space width

2014-02-01 Thread Walter Alejandro Iglesias
On Fri, Jan 31, 2014 at 08:06:11PM -0500, Peter Schaffter wrote: > On Wed, Jan 29, 2014, Werner Lemberg wrote: >> Given today's memory abundance and the high velocity of CPUs, the >> ideal route would be to implement a document-wide algorithm for >> typesetting a document (in contrast to TeX's page

Re: [Groff] space width

2014-01-31 Thread Peter Schaffter
On Wed, Jan 29, 2014, Werner Lemberg wrote: > Letter-spacing is bad in general. I find this statement a bit too broad, especially in the context of groff, whose only means of justifying lines presently is through the expansion of wordspace, often with ghastly results. Have a look at the first pag

Re: [Groff] space width

2014-01-29 Thread Werner LEMBERG
>> [...] since a width axis to expand or compress glyphs horizontally >> without modifying the counter width would be exactly the right >> thing for making the HZ algorithm work perfectly. > > I'm confused. I thought the useful thing about appropriately > designed MM fonts was that they allowed e

Re: [Groff] space width

2014-01-29 Thread Tadziu Hoffmann
> [...] since a width axis to expand or compress glyphs > horizontally without modifying the counter width would be > exactly the right thing for making the HZ algorithm work > perfectly. I'm confused. I thought the useful thing about appropriately designed MM fonts was that they allowed expansi

Re: [Groff] space width

2014-01-28 Thread Werner LEMBERG
> Back in the day of standalone phototypesetters, eg. the mighty > Linotronic or CompuGraphic's 8400, everything was line-at-a-time yet > the results were almost always better than what can be achieved with > groff. The reason was that both word- and letter-spacing (track > kerning) were used to

Re: [Groff] space width

2014-01-28 Thread Peter Schaffter
On Mon, Jan 27, 2014, Tadziu Hoffmann wrote: > If I may hazard a guess, it is possible that the notion of > *doubling* the space did indeed come from typewriters, where > spaces came in one size only. This is almost certainly the case. And one does wish that writers of text destined to be read at

Re: [Groff] space width

2014-01-27 Thread Tadziu Hoffmann
> http://www.heracliteanriver.com/?p=324 Many thanks for pointing out that article! This reminds me of a similar discussion on typophile (http://typophile.com/node/56108) in which one of the participants (near the end of the thread) shows an interesting visual experiment with sentence space, bas

Re: [Groff] space width

2014-01-26 Thread Werner LEMBERG
>> The only real solution is to completely redesign the layout engine, >> switching to a TeX-like paragraph handling algorithm. > > I admit to not knowing the internals of the formatting algorithm, > but I don't see why solving this problem requires the algorithm to > change. To solve it, interna

Re: [Groff] space width

2014-01-26 Thread Dave Kemper
>> I think it's [.tfk] a poorly implemented request. > > Well, it's a cheap implementation. Yes, that's a better way to put it. (-: >> Since the documentation states one of the problems -- "the track >> kerning amount is added even to the rightmost glyph in a line" -- I >> suppose this can't tech

Re: [Groff] space width

2014-01-25 Thread Werner LEMBERG
> I think it's [.tfk] a poorly implemented request. Well, it's a cheap implementation. > Since the documentation states one of the problems -- "the track > kerning amount is added even to the rightmost glyph in a line" -- I > suppose this can't technically be called a bug, but there would seem >

Re: [Groff] space width

2014-01-25 Thread Clarke Echols
Thanks for the tip. I think that's exactly what I need, given the situations where I usually encounter the need. Clarke On 01/25/2014 08:43 PM, Dave Kemper wrote: There are some situations where I'd like to be able to adjust spacing between letters (mainly in titles and headlines for commercia

Re: [Groff] space width

2014-01-25 Thread Dave Kemper
> There are some situations where I'd like to be able to adjust spacing > between letters (mainly in titles and headlines for commercial copy) > for special effects. I suppose I could force it by putting \h'...' > between characters, but that's a pain. I use .tkf for this. The description for th

Re: [Groff] space width

2014-01-25 Thread Clarke Echols
I prefer the wider spacing between sentences because it's easier to read. You can see the wider spacing and make fewer errors from not realizing there was an end-of-sentence, thus helping comprehension. There are some situations where I'd like to be able to adjust spacing between letters (mainly

[Groff] space width

2014-01-25 Thread Dave Kemper
On 11/18/13, Tadziu Hoffmann wrote: > In the original troff (according to the Troff User's Manual) > a space was nominally 1/3 em and a thinspace was 1/6 em, > thus half a normal space. In groff's TR font, a space > is nominally 1/4 em, but a thinspace is still only 1/6 em. > Isn't that strange?