First of all, thanks for your comments. On Sat, Dec 27, 2014 at 10:34:22AM +1000, Lex Trotman wrote: > [...] > >> You could try producing the cover page in something like Libreoffice, > >> printing it to pdf and then I believe there are tools that can glue > >> PDFs together (maybe even directly in libreoffice, see > >> http://en.wikipedia.org/wiki/List_of_PDF_software) so you can glue it > >> to the start of the PDF of the book contents you made conveniently > >> with a2x. > > > > That is not what I meant with "easy". > > > > My aim is to _automate_ the pdf compilation, that was the main reason to > > escape from ODF format. > > Well you have to edit the cover page in something, be it asciidoc, xml > or a WYSIWYG editor. After that combining them can be automated by a > script.
Right. Not beautiful but functional. > >> > With rest + Sphinx I am able to produce an almost perfect pdf, epub and > >> > html. I would like to do it with Asciidoc too, because I personally like > >> > much more asciidoc syntax than rest, this without having to study too > >> > much docbook and xslt transformations. > >> > > >> > Is it feasible? Is it better to buy a good docbook + xslt manual and > >> > start studing seriously? > >> > >> See http://sagehill.net/docbookxsl/CustomizingPart.html (referenced by > >> Asciidoc FAQ #3), it covers book covers :) > > > > Yes, sadly it is not comprehensive, or I am not so "smart" (probably) or > > it simply does _not_ work at all (also probably)... > > > > IMHO that FAQ item should be expanded with some working examples. For > > istance I never succeded to produce a pdf of a "book" type document with > > an index and a cover page, not to mention the logo image on the cover... > > > > For my test I am evaluating all aspects of the format choice. > > Please note that asciidoc is the tool that generates the docbook and > the a2x script just runs several toolchains after that. Those > toolchains are separate projects with their own faqs and helpful > people. It is beyond the scope of asciidoc to support using the > toolchains themselves, although if you ask here, anyone who can help > will, but the more likely place to get the answers is the toolchains > own support. ok > > These comprehend: > > > > * responsiveness of the doc tools experts (ok you were responsive and > > kind enough, thanks! :-) > > > > * easiness to circunvent problems .. (so and so... with asciidoc due > > to a2x docbook dependencies). Messing around witha hacks in latex > > / xslt / pdftk or so is definitely not the way to do these things... > > Couldn't agree more, would love a toolchain that used CSS for styling > or created the styles in a visual editor. For the former there are > commercial docbook processors that use CSS but nobody made an open > source version. For the latter there was an experiment that created > ODF from asciidoc so it could pick up styles from Libreoffice, but it > got to a point that supported the originator's purpose and then nobody > else contributed, so I guess nobody really wanted that capability > after all. Thats open source. And the name / site of the project is? > > * completeness of the document sistem. For example, sphinx is able to > > produce an (almost) complete makefile that takes care of all the > > documentation production details. This together with being the tool > > chain able to create the best pdf / ebook right out-of-the-box without > > messing with pdftk (keep in mind that there is no epubtk able to do > > the same...) make it the clear tool winner... > > As I have said before, Asciidoc and Asciidoctor are not in > competition, they are simply two tools that transform the Asciidoc > markup to various presentation formats. > > Asciidoctor is new and so incomplete, but it is in active development, > so it is where new things like toolchainless PDF might be added. > > > > > Having said so asciidoctor seems the (actually incomplete) tool more > > promising. Asciidoctor-pdf promise to produce (in the future) pdf without > > the docbook toolchain and if there will be something similar for epub > > that could be veeeeery interesting. If asciidoctor will incorporate > > support for .po file to gurantee easy i18n features that will definitely > > put it ahead of the pack. > > > > For now I am stuck between a powerful tool (sphinx) with ostic sintax > > (rest) and a powerful sintax (asciidoc) with a poor tool (a2x). > > > > Personally I hate rest (I have to use it on other projects I > contribute to) and so I don't find out what sphinx can do, so I can't > comment. I used sphinx, like it and still hate rest too... > > I am wrong? Please let me know your thoughts > > > > If not, now I have all the elements to make a (not easy) decision... > > > > Anyway many thanks for your help in clarifying me the things out... > > Hope you find a happy solution, its good that people help with > translating manuals, and that needs encouraging. Thanks. > But I have to ask, > would those projects not prefer you to use the same format as their > original (presumably English) manual so it uses the same tools? Original manuals are ODT. For translation I find that format simply intractable. [Asciidoc|rest|markdown] + po are really nice for translation. I decided to contribute in form of translation only for a manageable format (= [*] + po). So I just have to choose between those upper three. -- Marco Ciampa I know a joke about UDP, but you might not get it. +--------------------+ | Linux User #78271 | | FSFE fellow #364 | +--------------------+ -- You received this message because you are subscribed to the Google Groups "asciidoc" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/asciidoc. For more options, visit https://groups.google.com/d/optout.
