tags:

views:

904

answers:

3

I have written extensive JavaDoc documentation on my application, and added lots of useful info at overview.html and package.html files (including links on the former to illustrations in doc-files/). Maven's Javadoc plugin nicely uses the standard javadoc tool to generate the classic JavaDoc frameset, but now I need to generate a PDF with the whole documentation.

AurigaDoclet generates very pretty PDFs, and I was able to make DocFlex work also. However, both ignore my overview.html and package.html files (tried both inside and outside Maven - the PDF will be a once-only thing, since I'd rather have the HTMLs on the long run).

Does anyone know how to make AurigaDoclet recoginze my non-Java files? Or, alternatively, another to generate a decent-looking PDF from either the source code or the JavaDoc-generated HTML?

Thank you!

A: 

According to the Sun JavaDoc FAQ, there's a couple of options -- mostly free, with one or two commercial offerings as well. Check it out at http://java.sun.com/j2se/javadoc/faq/index.html#print.

MCory
From that page I've tried the MIF Doclet (not compatible with annotations), html2ps (near impossible to make work on Windows, which is what I'm stuck with overseas right now) and HTMLDOC (which requires either purchasing or a build that did not succeed on my first try).Still have to check PDFDoclet, but decided to ask here first just to be sure (after all, two doclets not doing precisely the same thing may spot something obvious I may be missing, parameter/setup-wise).Have you (or anyone) used it before in such conditions? Thanks!
chester
Unfortunately, no, I haven't -- I'm working with a small enough team at the moment that there isn't much benefit to printing the docs out, and the code is still new enough to where a hard copy of the docs would be outdated in a couple of weeks anyways.
MCory
Yes, I totally agree: the real value of most JavaDocs are their "live" characteristic. But this was an external request... :-/
chester
Something else you may want to consider is the iText java library and roling your own PDF generator. I'm adding this from my phone, so its difficult for me to get the link at the moment, but its a fairly popular library -- just google iText java pdf. It'll be a bit more difficult than just running a tool, but you can always release it to the public for anyone else who has this problem. Unfortunately, you'll probably need another library to parse th HTML files - maybe not, but most likely, since I think iText is just PDF.
MCory
And no luck with PDFDoclet also - it generates nice-looking PDFs, but ignores the overview.html (at least it prints package descriptions, which AurigaDoclet ignores). Tried using the -overview parameter (for which PDFDoclet reports an error, regardless of what I set as the overview file, suggesting it's refusing the parameter right away, and AurigaDoclet is just swalloing) and also adding the default package as "." (which javadoc refuses). Stuck :-(
chester
MCory, thank you for the suggestion. I ended up using HTMLDOC (see my own answer).
chester
+4  A: 

Nailed it. After trying all the possible tools to generate straight from the source, I returned to HTMLDOC. It is not JavaDoc-aware, but it is so well built that a few tweaks are enough to make it generate a pretty usable PDF.

Here goes a step-by-step description of how I did it:

  1. Download a free build of the software (the official site version requires a license, but it's GPL-ed, so you can find free binaries such as this one, which is a simple and functional installer for Windows);

  2. Generate your traditional HTML docs in your preferred way (Ant, Maven, command-line javadoc - your choice);

  3. The GUI is nice, but adding all files manually can be cumbersome, so just create a .book file with Document Type set to "Web Page", add one of the HTML files from your generated javadoc's root folder (e.g., overview-summary.html, anyone will do, it's just for reference on step 5). On the Output tab select the PDF format and set a name for it, and add other options to your heart's content (logos, colors, lots of cool stuff here). Save this project (say, myjavadocpdf.book) and close the GUI

  4. Generate a list of all HTML files in your javadoc. I did it with Cygwin's find command (my DOS/cmd shell days are long over), but you can do anything you want, as long as you get a file list. In my case a find . | grep html$ | sort -r > files.txt did the trick;

  5. Open the .book file generated on step 3 in your favorite pure text editor (as a programmer you should have strong opinions on that, so will keep my opinions to myself - NOT ;-) ) and append the list generated on step 4 to this .book file (it keeps the list of files at the end, making life really easy). Don't forget to fix the relative paths, if needed with a global search/replace (that's why you needed at least one file added on step 3 - to see which file path pattern htmldoc expects);

  6. Now you should sort the files in a convenient order. I put my overview first, then package descriptions and each class, then the full index, and everything else at the end. Remember that any file you delete will become an external (hence broken) link, so choose wisely;

  7. Save your .book file and re-open it on HTMLDOC. Voila: all files added and sorted. Click on generate. That's it!

You may want to fiddle with images (hint: use HTML width/height, not style/css). In the end, the resulting file is surprisingly good: nice looking and fully navigable for internal and external links. Impressive when you consider that the tool is not Java(Doc) aware at all...

chester
A: 

@chester wrote:

AurigaDoclet generates very pretty PDFs, and I was able to make DocFlex work also. However, both ignore my overview.html and package.html files (tried both inside and outside Maven - the PDF will be a once-only thing, since I'd rather have the HTMLs on the long run).

In fact, neither overview.html nor package.html files are ever processed specifically by any Javadoc doclet! Rather those files are picked up automatically by the Javadoc core itself. Javadoc reads, parses and pre-processes the content of those files. Only after that that content is fed to a doclet. The doclet does not even know where all those descriptions come from.

So, you should not blame AurigaDoclet or DocFlex/Javadoc for your failure. They are just Javadoc doclets, that is Javadoc plug-ins.

Instead, you should know how to specify the overview.html and package.html files to Javadoc in general. That will work the same with any doclets you use (so long as Javadoc itself is involved).

The overview.html should be specified using -overview Javadoc command-line option. Read about this here: "http://java.sun.com/javase/6/docs/technotes/tools/windows/javadoc.html#overview"

The package.html should be placed simply in the corresponding package directory of your Java sources. It will be picked up there by Javadoc automatically. No specific command-line options/settings are needed for this!

Regards,

Leonid Rudy

www.docflex.com

Leonid Rudy
Leonid, you can check the comment on the answer above and notice that I *have* used the -overview parameter. I also have the package.html files at the right places (if I didn't, running Javadoc with the standard doclet wouldn't have worked out with them, for starters), and the doclets behaved in different ways under the very same input from Javadoc. For the record, I *do* understand how the doclet mechanism works, and neither I recognize a "failure", nor I "blame" any software for it. But thank you for the willingness to help.
chester
@chester - On the other hand, I am not particularly happy to see that somebody publicly dismisses some important functionality of our product when it is actually very much present and works!I've just checked everything myself. Both overview.html and package.html files are processed just fine by our product. In fact, you don't need to go far away. Simply download DocFlex/Doclet from our site (http://www.filigris.com/downloads/) and run demo with RTF output selected. The full content of package.html will be exactly in the generated RTF file!
Leonid Rudy
I believe, here is either some gross misunderstanding of what you are talking about (I mean your specific problem) or you are trying to run our tool in a very unusual environment/settings so that you discovered some rare bug or problem (perhaps even of Javadoc as a whole).In any case, rather than writing here, it would be much better first to report us directly about that problem or bug (if you think you have found one) and send us a little example/description of what exactly is wrong and how exactly it should be right in your view.
Leonid Rudy
Yes, Leonid, if I worked for the company, I might feel that way. I might even desire direct contact and/or more info. But... "rather than writing here, it would be much better first to report us directly"? Come on! What sort of customer relationship do you expect to build by dismissing the role of a developer forum in problem-solving? Yes, I may have done/assumed something wrong. I could post detailed, reproducible steps (just as I did with the final use of HTMLDOC) if asked nicely, but after that, I'd rather avoid any further contact with the company or the product. Have a nice day.
chester
@chester - Absolutely right! We do need a forum. Equally, we need to write tons of documentations to describe our technology (as well as lots of visual tutorial). We need to do lots of other very important things to have everything right. For instance, we really need to promote our products and technology, to make Internet buzz about it. Some statistics show that lots of people are searching Google right now for what everybody says about our "docflex". And alomost nobody says a thing (although we do have more than 100 commercial customers). [continued..]
Leonid Rudy
Only occasionally the guys like you mention something, and even them tend to distort the real things (like you did). To make buzz, you need to pay, assign people for doing this. Alternatively, there are lots of companies who do it: create opinion in the heads of the guys like you. In short, we need something 20-50 people to do this everything. And to pay those people, taxes and other expenses, we would need some 5-10 millions EUR of start-up capital. That's how it works! Everything costs money. For instance, this very site 'stackoverflow' is that kind of business. Be sure about it!
Leonid Rudy
Somebody needed to invest as little as at least 1 million to let us write those nice texts here. Nobody moves a finger without being paid! (If you think there is Open Source, I can say, any serious open like Eclipse, Apache, Linux is bluff created and financed by big corporations. Basically, it a marketing trick.) I am about 20 years in this business, worked for two big software multinationals... and I think I know a thing or two about how it works. [continued...]
Leonid Rudy
We are a very small company right now. We don't have those big resources. We assign our priority to most important (vital) things, as we perceive them. A support forum was not on the top of the list so far. Right now, it is much easier to communicate with the customers via e-mail. But the forum is coming, definitely!
Leonid Rudy
As to this "I could post detailed, reproducible steps [..] if asked nicely" - OK. Maybe you could. But I didn't know about your problem. I came across your article two months later since it was posted. I didn't even know if you track this thread any more. But it was my job to react on your posting because it distorted facts... and react strongly. After all, this concerns our business. Note that lots of people may read it!
Leonid Rudy
"but after that, I'd rather avoid any further contact with the company or the product." -- It is up to you. Typically people use what they really need. I hate some companies too. Anyway I use their tools and even have to pay for their licenses.
Leonid Rudy
We also have seen various customers. Some ask lots of questions. Sometimes we even need to do something for them in advance... only to seem them vanishing after that without any reply or thanks. Some of those guys may even surface in a year or two. We are happy to everyone! It is our job.
Leonid Rudy