groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [groff] Modern Groff


From: Ingo Schwarze
Subject: Re: [groff] Modern Groff
Date: Sat, 25 May 2019 22:36:53 +0200
User-agent: Mutt/1.8.0 (2017-02-23)

Hi John,

address@hidden wrote on Sat, May 25, 2019 at 10:20:46AM -0700:

> Maybe it's dumb for you, but I have suggestion to extend groff to
> export ebooks.

The idea is not necessarily dumb, but there are many different file
formats for ebooks.  If somebody wants to work on that, they first
need to decide which format they want to support.  See e.g.

  https://en.wikipedia.org/wiki/Comparison_of_e-book_formats

As a matter of fact, two of the ebook formats listed on that page
are already fully supported (PDF and PostScript); for now, i'd say
simply use PDF as your ebook format of choice, and you get a very
high quality ebook straight out of groff.

Another ebook format listed on that page is half-supported: HTML.
HTML output quality from groff is poor, though.

> I know that you're mainly interested in typesetting that could be
> printed.

That is true for some groff developers, but not for all.
For example, i'm very interested in ASCII and UTF-8 plain text
output.

> But this could short the way of many publishers, whose have to
> publish their books in two faces today. And should make your program
> more general purpouse.
> 
> For me it isn't hard to imagine. I think mom should be good for
> formatting since they have document structure macros.  The work is
> only to format macros to xhtml request, make toc's and put it into
> epub container.

You are kind of right.  *If* somebody picks an XML-based format to
implement, the right approach is almost certainly to only support
one specific macro set (and mom would indeed seem a good choice)
and not use the groff program at all, but translate directly from
macros to XML, thus preserving all the structural and semantic
markup, which would be destroyed if the input were first run through
groff(1).  Just like it was done with mandoc(1) for mdoc(7), man(7),
tbl(7), and eqn(7).

It would be a big task, though.  For comparison, when two people
worked on mandoc, it was ready for production after about two years,
and right now, after ten years of development, there are still
things to do.  What you are asking for is significantly more work
than that because mom is a larger and more complicated macro set
than mdoc.

> It could be done by grohtml with/or some other tool (grohtml have
> some problems with mom.)

Grohtml is a failure on the most basic architectural level.
Making that work is probably almost impossible.

> I know that much of this work I can make by hand.  If you aren't
> interested in the idea please write to me.

I can't speak for the other developers, but i very much doubt that
any of them will pick up such a large task right now.  Basically,
regular maintenance work is what groff developers have time for
nowadays, but not much more.

> Also you can add it to yours plan and wait for somebody who would
> start it.

The idea is not specific enough for that, nor would it make sense
to make it more specific before somebody speaks up who actually
wants to do it.

> I think that you could find many interested programmers in Project
> Gutenberg or Mobile Read community.

It would be nice if it were easy to find people to take on open
source programming projects, but the reality is it isn't easy.
Those who are qualified and interested typically already have their
own ideas what they want to do, and those who aren't even able to
make up their own minds (such that they resort to asking others
what to work on) typically aren't capable of doing anything serious
in the first place.

Yours,
  Ingo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]