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/
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
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
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
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
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
> 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
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
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
> '.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
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).
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
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
>> 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-
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
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
>> [...] 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
> [...] 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
> 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
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
> 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
>> 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
>> 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
> 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
>
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
> 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
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
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?
28 matches
Mail list logo