Hi John, 4...@secmail.pro 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
