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?"
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.
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