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).
> '.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 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
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
> 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, 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
I came in late. Apologies, I didn't realize there was discussion of the
longer-term future going on under "space width". :-)
Peter Schaffter :
> Mine, too. My impression is that, under Werner's leadership, groff
> has been brought as far as it can be without crumbling under the
> weight of histor
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
> [...] I think the entire presentation-centric model within
> which groff lives just about run its course. The future
> belongs to structural markup and stylesheets, because of the
> requirement for rendering in multiple output media including
> the Web.
Point 1: I think we're talking about the
On Tue, 4 Feb 2014 15:43:11 -0500
"Eric S. Raymond" wrote:
> I have to say, unfortunately, that I think the entire
> presentation-centric model within which groff lives just about run
> its course. The future belongs to structural markup and stylesheets,
> because of the requirement for renderin
On 02/04/2014 07:42 PM, James K. Lowden wrote:
On Tue, 4 Feb 2014 15:43:11 -0500
"Eric S. Raymond" wrote:
I have to say, unfortunately, that I think the entire
presentation-centric model within which groff lives just about run
its course. The future belongs to structural markup and styleshe
James K. Lowden :
> Hmm, seems to me every document is presentation-centric, depending on
> what that means. Are you suggesting Postscript and PDF are not long
> for this world? Are we doomed to the eyesores produced by
> lousy-browser ebook readers?
Oh, no. I think Postscript/PDF have a *lon
On Tue, 4 Feb 2014 23:08:02 -0500
"Eric S. Raymond" wrote:
> > I wonder what presentation-centric -- I think you mean
> > "paper-centric"
> > -- features troff is beholden to. What is different about nonpaper
> > devices, that prevents troff by design from producing documents for
> > them?
>
13 matches
Mail list logo
