On Tue, Feb 25, 2014 at 01:24:15PM -0500, Eric S. Raymond wrote: > Walter Alejandro Iglesias <e...@roquesor.com>: >> Assuming you have not enough time to do it yourself, what I would do >> in your place is to pay someone to write the html of your site and >> replace DocBook with PHP scripting. > > There are about fourteen million reasons that would be a terrible idea. > I'm not going to argue them here; this discussion is about how to fix groff, > not my website.
I mentioned your site because "A good workman doesn't blame the tools". Don't take if for bad but from my honest point of view Groff doesn't need to be fixed; a lot of things in your website does. I visited your site in several occasions. (Just to compensate, I love fetchmail :-)). >> Other point. Why the need to convert to html? Why not to use pdf >> online? Today you can read pdf comfortably from internet. Web bots >> (like google) read them. No lose. > > No, no, *no*. PDF on the Web is evil and must die. > > Here's why. It breaks the flatness of URL-space. HTML documents can point > at PDFs, but not *into* PDFs. Conversely, the ability of URLs to point out > of PDFs is damaged in two ways: (1) by inadequate PDF-reading software that > doesn't integrate properly with your browser, (2) by the lack of a > standardized > construct in PDFs for masking URLs behind informative link text. Well PDF is what PDF is. Do you want more features for PDF too? That's the reason I've ranted here and in some other mailing lists and forums, I am sick exactly of that, the today's anti Unix "adding features" illness. That's the human today illness, more and more and more. You end up with a watch that tells you Japan's climate, your blood pressure, your location with a GPS, but it isn't able to tell you what time is it. > Another drop-dead problem is that PDF wants its presentation container to > be rigid and breaks reflow when the browser size changes. I use max-width in CSS on my site because more than 70 columns are not comfortable to read. The reflow feature is relatively useful. Most web sites today use a static width. And worse, some idiots use static width of 200 columns! > Also, PDF on mobile devices is still pretty screwed up. That could be fixed > relatively easily, though. The above problems are more difficult. That's the evil! Mobile devices. Unfortunately I have not the power to exterminate them :). All that I like of Unix is being screwed because that stupid fashion (i.e. systemd). Do you use your phone to read a book? Well you're not using the right tool (ls is for list, cp is for copy). The monitor of your desktop neither, friends of mine have asked me always a printed copy of my novels because reading from the computer burns their eyes. The device that is nice to read books are electronic books, my wife has one. There you can read comfortably a PDF. Look. This is the output of a latex to xhtml converter I've wrote years ago: http://roquesor.com/Downloads/html/noe.html Take a look to the html source. Note that if you resize your browser window to a smartphone size you will see that the text gets adapted but it doesn't grow more than ~70 columns in full screen (the effect of CSS max-width). The script: http://roquesor.com/Downloads/lx2xl (I will delete them later) I shared that bash script in my site for years till I discussed with a debian TeXLive mantainer/developer because the same subject, the more is better illness. Don't you see anything wrong in the size of TeXLive? I could have written my script for Groff input. The point is I combined the tools I have in my machine, like I've learn to do with Unix, and the result is good. Like I said in other post here my script isn't useful for everybody in all scenarios, just do one thing and do it right. You should know better than me what I mean (human brain has a little defect, what is near during a long time becomes invisible). In resume. If tomorrow someone makes a clone form some Steve Jobs cell, and that Jobs android decides to sell a rectal device for browsing internet. Will you want to fix Groff again? > -- > <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> Walter
