Slashdot Mirror
Electronic Publishing Using Free Software?
Arkaein asks: "I am planning on electronically self publishing a book that I want to write, typeset, and create diagrams for on my Linux PC. Most of the diagrams for the book will be generated through scripted custom software, and I want the final product to be as compact as possible. I would like some advice from Slashdot on what Free Software tools I should use, with an emphasis on scripting efficiency.
I am planning on using hyperlinked PDF
for the final book format. To date I have used LateX for writing basic papers and have created vector images using Xfig and raster images edited using The GIMP. I used dvipdfm to convert my results into PDF. What I haven't done is create a hyperlinked PDF document, or generated xfig, postscript or any other vector image format through software, or worked on any document project of this magnitude before. I have thought about using raster images, my current software used for web content similar to what will go into the book creates raster images which I convert to PNG, this works well because the images are fairly simple diagrams with few colors and compress very well. I estimate that the 200 or so images I need for my book would require about 10K each as high-res PNGs for a total of 2 MB. This sounds acceptable, but would probably be smaller with higher image quality in vector format. Are LaTeX, Xfig and dvipdfm the answers, or do I need to look in other directions?"
This is slightly off-topic, but I just know someone's going to chime in here with "Why does it have to be Free Software? Communist hippies!" Much as I'd like to write off as trolls the people who say such things, I know they often mean it. So for those of you who think this way, read on. This cogent article on the subject may change your mind.
Why Software Should Be Free
by Richard Stallman
(Version of April 24, 1992)
Introduction
The existence of software inevitably raises the question of how decisions about its use should be made. For example, suppose one individual who has a copy of a program meets another who would like a copy. It is possible for them to copy the program; who should decide whether this is done? The individuals involved? Or another party, called the ``owner''?
Software developers typically consider these questions on the assumption that the criterion for the answer is to maximize developers' profits. The political power of business has led to the government adoption of both this criterion and the answer proposed by the developers: that the program has an owner, typically a corporation associated with its development.
I would like to consider the same question using a different criterion: the prosperity and freedom of the public in general.
This answer cannot be decided by current law--the law should conform to ethics, not the other way around. Nor does current practice decide this question, although it may suggest possible answers. The only way to judge is to see who is helped and who is hurt by recognizing owners of software, why, and how much. In other words, we should perform a cost-benefit analysis on behalf of society as a whole, taking account of individual freedom as well as production of material goods.
In this essay, I will describe the effects of having owners, and show that the results are detrimental. My conclusion is that programmers have the duty to encourage others to share, redistribute, study, and improve the software we write: in other words, to write ``free'' software.(1)
How Owners Justify Their Power
Those who benefit from the current system where programs are property offer two arguments in support of their claims to own programs: the emotional argument and the economic argument.
The emotional argument goes like this: ``I put my sweat, my heart, my soul into this program. It comes from me, it's mine!''
This argument does not require serious refutation. The feeling of attachment is one that programmers can cultivate when it suits them; it is not inevitable. Consider, for example, how willingly the same programmers usually sign over all rights to a large corporation for a salary; the emotional attachment mysteriously vanishes. By contrast, consider the great artists and artisans of medieval times, who didn't even sign their names to their work. To them, the name of the artist was not important. What mattered was that the work was done--and the purpose it would serve. This view prevailed for hundreds of years.
The economic argument goes like this: ``I want to get rich (usually described inaccurately as `making a living'), and if you don't allow me to get rich by programming, then I won't program. Everyone else is like me, so nobody will ever program. And then you'll be stuck with no programs at all!'' This threat is usually veiled as friendly advice from the wise.
I'll explain later why this threat is a bluff. First I want to address an implicit assumption that is more visible in another formulation of the argument.
This formulation starts by comparing the social utility of a proprietary program with that of no program, and then concludes that proprietary software development is, on the whole, beneficial, and should be encouraged. The fallacy here is in comparing only two outcomes--proprietary software vs. no software--and assuming there are no other possibilities.
Given a system of software copyright, software development is usua
Docbook generates neat and professional HTML and PDF documents cross referenced as you require. It also does PostScript suitable for most professional printers.
http://www.docbook.org/
Like HTML, it supports embedding all media types, including images, videos, sounds, and Java Applets.
The world will not get better through technology. We must seek to be better people.
That's "GNU/Linux PC", you capitalist running pig dog!
Forward, retransmit, or republish anything I say here. Just don't misquote me.
dvipdfm is quite capable of generating most everything you could want in PDF; it can do hyperlinks and thumbnails and so on.
the xfig format has several different vector-based software designers -- as in, there are several programs on CTAN that'll convert specially formatted commands into xfig format.
my personal opinion is that you have everything you need with those three tools.
Look mom, I even got the funky capitalization right!
I know a guy who had a good experience using PDFLaTeX with pretty much the same method you are using. I think he did some of his figures as eps and others as png. PDFLaTeX allowed for the hyperlinks that the LaTeX -> ps -> pdf method won't get you. I found a pretty good summary here. Might be good if you're already familiar with LaTeX.
Powered by Web3.5 RC 2
Around here even the experienced latex-ers use Lyx for editing their tex documents.
Xfig sounds a scary and rather masochistic way to go... how about Graphviz for flow charts and other similar graphics, and Sodipodi for your vector graphics?
I would use pdfLaTeX to produce pdf directly from LaTeX source. It can generate hyperlinks automatically when it creates the table of contents and the index. Also, I would use the Memoir class to provide layout macros. This offers much more flexibility in layout than the generic LaTeX classes, and the first part of the manual is a great reference for typesetting in general.
They're both in CTAN, which I assume you know about since you already use LaTeX.
LyX is a nice frontend to LaTeX. There are several packages for LaTeX hyperlinked PDFs, like Prosper and hyperref. You should be able to do pretty well with a combination of those.
The LaTeX that LyX creates is neat and readable, so it shouldn't be a problem to hand tweak it if you need to.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Check out lout. I found it easier to work with than LaTeX. YMMV.
If you can wait, you may also consider using Jeff's followup to lout, Nonpareil. The specs are done, but he's still working on a compiler.
The problem is that the people behind DocBook don't seem to want to have anything to do with the tool chain that takes the source file and turns it into something you can actually publish. This means that putting all the programs together to get DocBook XML to, say, PDF and then getting it looking the way you want can be a royal pain in the ass even if your distributor has included and configured the important stuff for you.
Then, there are two types of DocBook - XML and SGML, so at any given time, you are bound to be looking at the wrong documentation for the wrong tool when trying to get to your target format. DocBook SGML is less of a problem, if you have a choice, use it. Getting from DocBook XML to anything but HTML/XHTML seems to still be rather non-trivial.
Again, if you don't have to deal with any of that (for example, if you are submitting stuff to the Linux Documentation Project) it is pretty neat. If the DocBook people had gone whole hog and provided a comprehensive tool set along with the standard, it would rock big time.
As it is, I'd think twice before recommending it to somebody who just wants to get ink on paper.
SGML/XML was designed to be the mother-of-all information distribution and typesetting formats, so it gives you considerable power and flexibility--particularly with your vector graphics query: SVG . Output to LaTeX, Docbook, PDF, HTML, PS, etc.
If you intend to generate many diagrams using "custom scripts", you might consider making your scripts either write PostScript directly or even write scripts themselves in PostScript (the language) and have your diagram and its source be one and the same. Actually learning PostScript is not that hard (after one gets past its RPN/stack nature), you code a set of macros you intend to use (or you can draw their images in, say, Xfig, export to PS and copy/paste into your PostScript program as function), then in your code you just instantiate them where you need them, connect with lines, etc.
.ps file itself, like making all lines thicker or getting rid of color. ;-)
t .html .signature which generated a nice fractal tree in PostScript, saw it, like, 10 years ago on Usenet, but could not find right now.)
Adobe actually provides pretty good documentation on PostScript (this explains the popularity of the format), and GhostScript, of course, does great job in interpreting the language.
A good way to get a feeling for the language, try looking through PostScript code generated by any of cad/figure drawing tools, Xfig itself, gnuplot, etc. If nothing else, you'd learn how to make quick and dirty mods to
Just for fun, have a look: http://www.pvv.ntnu.no/~andersr/fractal/PostScrip
(actually I tried to find a very cool someone's 4-line
Hope this helps.
Paul B.
I can't comment on TeX because I don't really use it. The easiest tool I've found to do what you describe is HTMLDOC, if it supports the features you need. www.easysw.com writes it. You have to compile it yourself from the GPL source, or you can buy a copy for $100 from the company with support.
It takes HTML source files and turns them into a "book" with a table of contents and next/previous links. Just like DocBook or InfoTeX but without having to learn how to use them. You do have to learn some psuedotags placed in HTML comments to mark sections and pages though, but it's very easy. Last I checked it supports HTML single file, HTML directory of files, PostScript, and PDF as output formats.
The program has a mac-like GUI using FLTK, but you can use it from the command line too. The mailing list also has a pretty reasonable crowd, including the author.
Democracy. Whiskey. Sexy. Pick any two.
I highly recommend examining the ConTeXt macro package for TeX. It is perhaps more difficult to use than LaTeX, but it is much easier to get it to look like what you want. Also, it is very much pdfTeX aware, and part of the purpose seems to be the creating of screen documents, hyperlinked pdfs, etc. Take a look here
Adobe FrameMaker.
Some good suggestions in this thread. I'd definitely stick with LaTeX. I sometimes got better results making pdfs with ps2pdf, and sometimes better with pdflatex, so tweak 'em both.
.out, .lof, .toc, and other files, but I suspect that if you have problems with hyperlinks, twiddling with those would solve your problems.
I never quite understood the machinations of
Also, comp.text.tex is your friend, through Google Groups or a newsreader near you.
good luck,
cbd.
I'd recommend DocBook/XML. It gives you flexibility -- you can translate to HTML, PDF, etc. Yes, dealing with translating to other formats can be a pain. But it's been done before. There are lots of projects using it, and they all have templates, scripts, and stylesheets: TLDP, KDE, GNOME, FreeBSD.
For WYSIWYG editing, I recommend Morphon, which is now free (as in beer). You'll need to have a working Java VM.
For PDF output, there's FOP. Again, you'll need a JVM.
For structured graphics, I recommend SVG. However, I'm not sure what tools are good for generating it. And I'm not sure if FOP can handle it. I do highly recommend the O'Reilly book on SVG. Their DocBook book is somewhat out of date, but they've got some good articles on Oreillynet.com.
Software sucks. Open Source sucks less.
There's a fabulous little tool called Metapost, which is basically TeX's usual Metafont adapted slightly to produce .eps outputs and with a few extra helpful macros, things like drawing arrows rather than just lines.
It's not for everyone, or every type of graphic, but if you want diagrams in a PostScript format that is easy to insert into LaTeX documents... I'm not aware of any flashy editors, but it's awesomely powerful, and very easy to get good results after a little study up front.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Yea, yea. You're going to write this book. I've said that about ten times and I only followed through on one beyond the second chapter. You, me and most everyone else, start out with good intentions and grand ideas but, we rarely follow through, no do we?
My recommendation would be to write the book first. Use anything at all, even pen and paper. For diagrams, definitely use pen and paper. If/when the book is completely written you can then worry about type setting and diagrams and such and which tools to use.
The fact of the matter is that the odds are against this book even being started, let alone finished, so worrying about the word processor/type setter now is just premature ejaculation for your brain.
My last 800 page tome turned out to be a two page how-to. How's your magnum opus coming?
If your book is for on-screen consumption only, or the images are photographic in nature, raster images may be acceptable.
Otherwise - if they're diagrams or charts or whatever - they'll look embarassingly pathetic and entirely unprofessional when printed out, unless you store them at 300dpi or above, in which case the files will be gigantic.
You really need to use vector drawing software (or programmatic processes) to generate EPS files, which can then be folded into your production process.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
(Forgive a Linux newbie if I've got the wrong end of the stick...) but have you played with Scribus yet?
:) )
http://www.atlantictechsolutions.com/scribusdocs/
I must admit that I haven't tried it out with any really huge documents yet...
The friends that I know who do serious DTP tend to stick with PDF formats and transfer to EPS at a later stage (if at all). (That isn't to say that I don't respect TeX - I just prefer more 'visual' tools