hpr-knowledge-base/hpr_transcripts/hpr0866.txt

Episode: 866
Title: HPR0866: Publican, the user-friendly Perl frontend to Docbook XML
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0866/hpr0866.mp3
Transcribed: 2025-10-08 03:47:19

---

You are listening to Hacker Public Radio and my name is Clat 2, I'll be your host today,
and I'll be talking about Public Inn.
So Public Inn is a really cool publication system as they call it,
that the Fedora Linux project and probably Red Hat and that group over there is responsible for.
And it's a really cool system as it turns out, I'm really enjoying using it,
and I've been asked a couple of times by people how to use it,
and I pitched it as a talk at one or two Linux festivals,
but they just haven't really been interested in it,
and admittedly it's not the sexiest sounding thing in the world.
I know that two writers, it's actually really, really sexy.
Two people in documentation, it's really, really sexy,
and I'll tell you why in a little while, but yeah, it's just, it's a way to write.
It's a way to get your written word down into a text document,
and then to get it back out into a variety of formats.
So yes, it is the mythical solution to the right once,
distribute everywhere problem for for writers.
And I've heard this from a couple of people, they'll be like,
look, Clat 2, I want to get involved with the documentation project,
because I feel like that's something that I can do or that I can contribute to,
but this thing, they use Doc Book, and I have no idea what that is,
I don't know what that is, or they use Public Inn,
and I can't even imagine what that is.
And admittedly, most of the documentation projects, I think,
use some kind of versioning control.
So if you don't know Git or SVN or something like that,
then even if you did know Doc Book or Public Inn,
but didn't know the versioning control stuff,
then you'd still have a learning curve to get involved.
On the other hand, all of this stuff is very attainable,
and frankly, all of that stuff is good to learn anyway.
Even if it's not just because, oh, you want to give back to the free software community,
and you want to contribute, and you feel like you could at least write a chapter about,
you know, this or that subject in this or that application,
and be a document for it for a change.
Even aside from that noble cause,
it's just a great way to learn how to organize your own projects,
and to keep track of your own data with versioning control,
and write in a very structured way,
or have some kind of structure to it.
It's a good disciplinary kind of thing,
plus it just saves you a lot of headache in the end,
because the way that most writers are taught to write,
usually doesn't really include any kind of organizational skill anyway,
but I mean, the way that they're kind of taught to write,
at all, is usually very disorganized.
It's very kind of haphazard and slap-dash,
and there's no sense of this data that you've just committed
into this horrible word processor that you're trying to use.
This is the source code for your work of art,
or for your essay, or for your thesis, or whatever,
and should anything ever happen to that word processor file,
or should that word processor stop being supported for any reason?
Or some of that excess bloat metadata
that that word processor stuffs into the file format
that they're forcing you to use becomes corrupted,
your work will be lost.
That's a horrible idea, and it's just not something that's really discussed about,
you know, in the little art circles that you go around to
and hang out with writers.
They just don't know about this stuff.
I'm going to venture to say that
public and slash doc book, because public and uses
underneath every, all of its glitzy and glamour,
pearl stuff that it uses, doc book.
So I'm going to venture to say that public and doc book
take no more effort to learn than HTML.
And HTML is so ubiquitous now
that I think most of us kind of could hack together a web page.
It might not be very pretty,
but it would be something that a web browser could see
and serve to the world pretty easily.
Public and in doc book are really like that,
but it still takes a little bit of time to get a custom to.
But it's not a big learning curve.
I've talked about things that have big learning curves before.
This isn't one of them.
If you sit down and really look at it
like a couple of sample doc book sources
and then listen to this and learn how it's all put together,
then you'll be up and running in no time.
I don't know how about you, but when I first learned HTML,
I was still, I mean, I had no idea about FTP
and even what was happening when I clicked the little upload button
to get the index page onto the server.
I didn't understand any of that stuff.
So even though I reverse engineered the HTML tags
that I had to put in by taking an HTML page
that existed and stripping out all the content
and putting my own content into it,
suddenly I learned HTML,
but I still had to figure out how to get it to other people
and that sort of thing.
So there is that learning curve,
but once you understand the process
and understand what's going on,
it's no longer at all puzzling.
So that's the level we're talking about here.
And we're going to cover it pretty completely, actually.
So let's start out with what publicant is.
Like I say, it's a publication system.
Really, when it boils down to it,
it's a bunch of Perl scripts.
And I'm talking about a lot of Perl scripts.
The Perl scripts in publicant
are basically front-end for a set of other tools
that process a certain kind of document
and that kind of document is Docbook.
So this is a Perl front-end
to an XML schema called Docbook.
And in order to process the Docbook pages,
we need a bunch of other stuff like FOP
and various XML tools.
The dependency list is mind-boggling for publicant.
If you're in front of Fedora,
which I'm sure everyone is just type in
young, space-deplist, space-publicant,
space-pipe, space-grep dependency,
pipe-wc-l.
And that'll give you, if you're rude,
that'll give you a dependency list
of everything that publicant requires.
We'll just grab for the word dependency
because we don't want the answers to what provides it.
And then we're piping it through word count.
And we're just asking for a line count.
You'll get 145 dependencies.
Granted, some of those you already have
on your computer probably, like the Liberation Font
and CVS, I mean, okay, that's probably
on your Linux distribution.
Image magic may or may not be there.
But a lot of that stuff is like pearl modules
that you need for this thing to work.
There's, of course, FOP in there,
to actually, that's by Apache,
to process the XML into, for instance,
PDF for HTML or plaintext or RTF,
whatever you want to export it to.
The cool thing about publicant is
that all that stuff you don't really have to worry about.
Once you install publicant,
you basically reduce your workload
to really about two commands.
So that's an upshot of learning public.
And if you don't want to think about the XML,
if you don't want to think about how all this stuff works
and gets strung together, you don't have to.
You can run publicant and create
and publicant build a couple of flags in there
that I'll tell you about in a minute.
And you're done.
You're finished.
If you would rather do it the hard way,
I do have a certain system that I used to use
before finding the more elegant solution of publicant.
There's a system that I use.
It is actually pretty good and pretty effective.
I call it Circulate,
because I wanted to brand it with something,
some catchy word.
So it's like you're circulating your work around
to all the people.
So if you go to slackerimedia.info-circulate,
you will find an explanation of my shell scripted
and XML2 and FOP.
And I think those are, oh yeah, a text to docbook.
A bunch of little scripts that other people have written
and that I just kind of string together into a way
that you can write in plain text, pipe it back.
I mean, get exported into some pre-made script
that will dump out some pretty ugly doc book
and then pipe that through XML2,
send that over to FOP,
and you end up with an HTML and a PDF version
of whatever you've written.
It works quite well actually.
It's fine.
But publicant, you literally publicant create
and then publicant build and you're done.
We have to write stuff in between those two steps.
You wouldn't want to just go straight from one to the other,
but we'll get to that in a minute.
Okay, so if you want to try out publicant on Fedora,
it's yum install publicant on a Debian-based thing.
It's apt to chewed install publicant
on Slackware.
It doesn't really exist,
but I have written a shell script that will make it exist.
So if you go to clatu.fedorapeople.org,
you will find the horribly, horribly, ugly hacked together
embarrassingly gross, overblown, bloated shell script
that I used to pull down publicant to my Slackware machines.
It's pretty ugly, I have to say,
but it does work.
So it's just over at clatu.fedorapeople.org.
You'll see it. There's only like three things on there.
One of which is publicant.tar.beasy2.
You can download that. It's a really simple little shell script
and I think there's probably a reading file in there.
If you're going to try this,
I mean, first of all, you should only be trying it on Slackware
because I can't think of any other distribution that you need to do this on.
But if you try it read through it because it's a really ugly script,
it just does, it brute forces publicant onto your system.
Basically, it pulls down all kinds of pearl modules from wherever it can find it,
whether it's the Fedora repositories or from Slackbuilds.org or from C-PAN itself.
And then it grabs a bunch of fonts from Fedora Repos.
It's just, it's really horrible, but it does work.
And honestly, it works pretty well. It's just really embarrassing.
But you should read through it and make sure that I'm not, you know,
I didn't turn evil and I'm not hacking your system or something.
You're turning you into a botnet dedicated to processing all of my XML or something.
So yeah, there's the build script.
Otherwise, you can just do a repository install publicant.
That will pull everything down. It's a good size install.
But it's all very useful stuff. I'm sure.
And then you'll be ready to write some XML.
The cool thing about publicant is that you don't have to worry about all the headers and stuff like that.
It's going to generate and even the structure of all the XML pages.
It's going to generate that all for you.
And the way to get it to generate that for you is a simple command.
It is publicant create. That's publicant space create.
Space dash dash name equals. And then you want to put in some project name.
I like to use camel casing. I don't like to use spaces.
So just do a public in is fun.
Space dash dash version equals. I'll give it a 1.0.
And space dash dash type.
And you have a couple of choices here. There's type. There's a book.
There's an article. And I think there's like a set or something like that.
I've only done books and articles myself.
So we'll make this a book just because that's a pretty common one.
The other one is article. I've used that before.
But it's a little bit almost too simple, I think, for a good example.
That generates a folder called publicant is fun.
And if you see the end of that, you'll see three objects in there or possibly two.
One is EN dash US. That's because the default language on your system is English.
So you're starting with the default language on whatever system you're using.
You can add more folders actually if you get translations of your work.
And you can build all kinds of different language versions of your work using all of the same resources.
I think maybe you're starting to see why publicant and even dock book in general is so powerful.
If you're doing a complex user manual for your favorite project and you want to have English text with all these pictures that you've carefully selected and done screenshots for,
suddenly you realize, well, I really should have an Esperanto version as well.
So you translate the whole thing into Esperanto.
Would you want to really go back out and find all those images and place them where they should go and all this other stuff?
No, of course not. And that's what you'd have to do if you were doing it in open office or scribe this or something like that.
Yes, it's meant for writing stuff and yes, it lets you insert images, but you can only do it once per language set.
So dock book is brilliant for that kind of thing.
So anyway, we've got EN dash US. That's the folder with our English version in there.
And then there's publicant.cfg. That's our default public and configuration.
And then I think there might be a temp folder in there. I don't know. I built this folder a few minutes ago.
And I might have added that temp file in there by accident myself.
So either way, if you go into CD, I mean EN dash US and do an LS, you'll see a couple of, again, pre-built XML files.
This is really one of the places that publicant just makes it really easy for you.
Because otherwise you kind of have to understand the structure of a smart dock book project.
And I guess it's okay to mention at this point that dock book itself for writing is one of the most brilliant, I think, maybe possibly revolutionary ideas I've seen in my entire training as a writer.
So I've written for a long time. So I've had the whole, you know, indoctrination into kind of, you have to do writing this way, if the outline, if you do all this junk.
You know, everyone's got like these things that you have to do to write different kinds of papers, you know, if it's a paper for school versus if it's creative writing.
And they all seem to have like this structure that you're supposed to follow.
And all of it's nonsense, but dock book is like, here's how to do it smart.
And here's how you can do it so that when you make a change to your file, you can just diff the thing and then merge the changes.
You can patch your creative writing. You don't have to go in and do fancy rearrangements of paragraphs and stuff like that.
I mean, you can if you want, but you can also just patch the thing because if you write it with dock book and you actually think about, my battery is dying, if you actually think about the fact that you've got lines, you know, a hundred lines in this document and the line begins here and ends there.
It becomes very, very code like it becomes basically source code, dock book treats all kinds of writing as source code.
So it's really, really easy to, well, like I said, you can diff it. You can merge different documents.
So this is powerful for the individual artist or the individual person, just writer writing for magazines and stuff like that, articles, as well as for collaboration, obviously, because this way someone's working on their writing.
They're working on their own get branch of the documentation, someone else is writing a chapter that that follows up or that integrates into that somehow.
Suddenly you can do a merge of those two branches and you've got one big dock book document, lots of different authors and it works really, really smoothly.
So this is the kind of stuff that I don't even think writing workshops and stuff like that even have any clue about. This is beyond them.
They're often some other world making their little outlines in open office or whatever and people using dock book and public and are getting stuff done, writing manuals, writing books, writing articles.
So yeah, big fan of public and I digress again. So the structure, the structure is predetermined for you by public and which is really helpful.
All it takes is looking at the files in this folder to see how it all is supposed to work together.
The really important file is the one called whatever you've titled your book dot XML. So I called mine, public and is fun.
So if I do them, public and is fun dot XML, it launches. This is a pretty modest looking file, but it's actually the most important file.
This is the sort of the thing that's going, it's not the make file. It's the, it's kind of like a make file. Basically what it's doing is see all these lines in here.
It's got, well, first of all, what you'll see is when you look at it was like five lines of header stuff that you don't have to worry about because public and just took care of it for you.
You know, XML version 1.0 encoding, UTF-8, doc book, doc type book, public equals, Oasis DDT, doc book, XML version 4.5, all that other stuff, you know, the scary stuff that you don't even want to ever have to deal with.
But then it's got very important tag. One is book, that's the opening tag, and then it's got a bunch of xi includes, xi colon include, and that includes the different parts of your book into this larger entity called the book.
So whenever you make your doc book into to your, your public and thing, whenever you go to publish it, this is actually the file that the processor is going to be looking at, and it's just a document full of links.
So you're just linking all the components of your book in order right here. So again, this is just such a smart way of doing things.
I've seen so many writers open up open office or whatever, and they'll just write their book one big long 200 page, or if it's an article or a paper, thesis paper, whatever, really long big monolithic thing.
And then they go through and they realize that they have to switch some chapters around, or they really needed the insert chapter, and suddenly that throws everything else off, right?
Doesn't happen here. This is source code. This is modular. You can say, okay, I want you to first put the book underscore info.xml file, and then I want you to put the preface, and then chapter one, and then chapter two, and then chapter three.
Change. I want chapter three to become chapter one. So you just go down to chapter three, dd, for delete the line, up to above chapter one, shift p to insert above, and suddenly we've just rearranged our work without even having to think about it.
It's just that simple, or we could, if I guess we could have moved chapter one.xml to become chapter three.a.xml, and then done it in the command line, or in the file manager, and just kind of switch them around, but even better is not using chapter one, chapter two.
You know, just name them the name of the chapter, and then just put them in your book.xml in whatever order you want them to appear. Very, very powerful feature already, and we've only looked at one file.
The other files in here are just, it's the skeleton structure. There's the author group. If you look at that, author group, author, first name, surname, affiliation, email, just enter the author's name in there.
The book underscore info. This is information that is sort of like a title page. So there's the title right now. It's by default set to our little camel cased.
Public and is fun, but we could have done, we could change that to public and space is fun. And then the short description, so you can put a subtitle in a product name and a product version, 1.0, addition, if it's the third edition, the first edition, whatever.
And a little abstract because that's what the publishing industry likes are those little blurbs about the book. Just random stuff like that. You can give it an image object, you know, kind of a logo or something like that. All kinds of stuff that you can throw in there.
The next one just going through it alphabetically is the chapter.xml. If you look at that, it's got a sample chapter essentially. It spells it out for you. It's really nice that way.
So public and just like HTML has a hierarchy of tags, the topmost tag, again, after all the header stuff, like the xml version, you know, that kind of stuff. But the top level tag is the book tag in this case. It would be an article tag if we were writing an article.
So that's kind of like your HTML tag in a web document. And then you would put under that a chapter, chapter ID equals. You could even give them like, you can give them properties, you know, like CSS kinds of properties. So chapter ID and you can give it an ID. And that way you can refer to it later on if you want to link back to that ID or you can CSS, CSS layout, the whole thing.
Or XSLT proc of a whole thing and really come up with your own layouts if you're into that sort of thing. I'm not. That's why I'm using public. So under chapter, you get to do a title. And then you do a para. And then you could do like a section if you wanted to. And a section is just like a numbered section of a chapter.
So you've got your big chapter heading. You could think of that almost as an h1. And then you'd have your paragraphs in there. And then maybe you want to break something fairly significant, but you don't want to make a new chapter. So that would be section. And then you can give your section a title. And that would get like 1.1. So it's in chapter 1, but it's section 1. And you can obviously nest these things as much as you want. Chapter section, subsection, back out to subsection.
Back out to section, back in the chapter. And then finally into the chapter.
At the most basic, that's really all you need to know about public. And I've just you've you've learned doc book now.
It's book, which as you as you probably noticed is in the public and is fun.XML. That's the that's the book tag right there. So book and then all those Zion clues. So we're basically just linking all of the chapter documents that we're writing.
We're linking that into the big book file with these little Zion clues, which are like a h refs or maybe more like, no, I guess they'd be like a h refs or something like that.
Because they're just you're saying, or they're almost like includes like in source code, you know, where you say, hey, I want you to include this thing in order to run.
That's what this is. This is like, I want you to build the book. And to do that, I want you to grab the preface and then chapter one and then chapter three and then chapter two and then chapter eight and then chapter five, six, seven, and so on.
That's it. Those are the those are the most important tags that you need to know for doc book book chapter title, para and then optionally section title.
Just be sure to close all your tags. It's just like HTML except a little bit more strict. Okay. Well, that brings us to the inevitable topic of what shall you write in.
As you probably know, if you've heard my recent series on Emax, or I don't know, I guess maybe the Emax one hasn't aired yet. So anyway, you will find out or you already know, I write a lot of my human readable stuff like my creative writing or my technical writing in Emax.
I use them a lot for technical for for config files and random changes like that. But Emax is the one that I got taught doc book in. So I've kind of associated doc book with Emax.
And I just so happened to know of a bunch of nice little tools in Emax that you can use to kind of help you write in doc book.
So there are two different plugins or modules, whatever they're called in Emax that I use. One is called in in XML mode. And that is the lowercase in an XML dot dash mode in XML mode can be gotten from a place called Thai open source.
I think I'll include the link on in the show notes. And it's just a set. It's a fairly extensive set of plugins of of E list files that you can use obviously inside of of Emax.
It's easy to install. All you do is you place it in your in your Emax directory, wherever that is. I put it in my home directory, my E list directory and dump the in XML mode stuff into that.
And then I throw some little things into my dot Emax file that simply tells it to, you know, to load that in XML mode.
That's a really nice tool. Really comes in handy because what it gives you is on the fly validation, which is really, really nice.
If you've ever used XML and you've ever suffered through multiple validation errors as you try to build the thing into something else, you will know how wonderful on the fly validation would be.
So it gives you on the fly validation, running validation as you type. It's really nice. It also gives you tag completion. So if you're typing a tag, so if I've got a title, that's obviously opening the tag with what less than and then the word title and then a greater than symbol.
And then I type my title, public can is still fun. And then if I type in the less than slash, it picks up that less than slash and completes the title tag for me.
So that's it's really quite nice. It also really helps you from typos because I don't know if you've ever tried to do, like XML without any kind of completion.
But the times I've done, you know, opening tag of type toll, properly spelled, T-I-T-L-E, and then a closing tag of, you know, T-T-I-L-E or T-I-T-E-L or something like that, you know, suddenly you're no longer typing in a valid XML document.
And you don't find out until it errors out when you're building a thing and then you have to go back and find it. It's not very fun.
So in XML mode is great. The other great thing about it that you can get for EMAX is a doc book menu. It actually puts in the window of EMAX when you're running in your XML mode or in XML mode, puts a doc book menu.
And the doc book menu is just a drop down menu and it's got all of the elements, all the possible elements listed both alphabetically as well as logically.
So if you know that you want to do a list, then you can look in the logical menu for block elements, lists, and then you get all the different tags associated with lists, which of course wouldn't start with L.
So if you went to the alphabetical when you wouldn't be able to find it there, you start out with things like call out list, itemized list, ordered list, segmented list, simple list, variable list, list item. You'd never find that in alphabetical.
But on the other hand, if you know the alphabetical, you know it's got something to do with error. You just can't remember if it's error or error code. You can go to the alphabetical, look it up. It's really handy.
So that's kind of the one that I generally use, but I do just as much honestly with like either HTML or XML in VIM.
And so there's a little plug in for that as well. It's not quite as fancy as in XML mode, although I haven't really looked all that much for something to equal in XML mode because the bulk of what I do is in EMAX in XML.
But for VIM, you can go to VIM.org slash scripts slash download underscore script dot PHP question mark.
SRC underscore ID equals 4965. If you double you get that and send it out, you know, dash capital O XML underscore completion dot tar dot gz.
You'll download a little VIM script and then you can untar it tar space dash XF space XML underscore completion dot tar dot gz.
That spits out a folder called XML completion. So CD into, well, you actually don't even have to CD into it, just move in the space dot slash XML underscore completion slash VIM slash asterisk.
So we're grabbing everything inside of the little VIM folder in this script folder and we're moving it to tilde slash dot VIM slash.
And that's going to move about, I think, three folders that this script needs to run over to your dot VIM folder.
And then there's another file in there. I forget what it's used for. It's something and you so you can move dot slash XML underscore completion slash XML asterisk c.
I forget what it's, I think it's XML dash something something dot c and move that over to tilde slash dot VIM slash.
And now you've got your dot VIM folder configured so that it has access to this script. And then it's really cool because you can simply VIM, let's see sample dot XML.
Now you're in an XML document so it's got, it's got that script going for it so you can open up a tag. Again, just do like title, for instance. Hit return. Yes, it makes sure that you're indented. So you're automatically indented just so you have good, you know, tag flow, put in a title.
Again, it's fun. Return again and then do the lower case slash, actually that's how I do it. I don't even know if you have to do the less than slash, but control J.
And that completes that tag that the most, you know, the most recent tag for you. Now if you've got a bunch of tags going on and it doesn't know what you want to complete.
It's really cool. It will actually bring up a pop up window of pop up like text menu that you can arrow through and decide which tag you were asking it to complete. It is really, really slick.
It doesn't do like on the fly validation. It, you know, it's not quite as, for me, it's not quite as smooth as just typing in the less than slash and having an auto complete for me because you have to, I don't know, how often do I hit control in VIM? Honestly, not that often. I know that I could if I wanted to use more scripts.
But, but yes, it's, I haven't quite integrated it 100% for myself, but it is really, really slick, highly recommended, especially if you're more of a VIM person than an EMAX person.
Okay, so we now have a text document. We, I mean, a text editor that we can edit XML in. That's good. So now if you just open up any of these documents.
chapter.xml. Like I say, it gives you the skeletal structure of this thing already. You can go either to the dock book menu in EMAX or go online to the definitive guide for dock book, which, again, I'll have to include a link, I guess.
You can find all the different tags that you're allowed to use in dock book, and there are many. There are plenty. It's, it's, dock book is, dock book is great for both creative and technical writing.
I think it was probably geared toward technical writing at first, but honestly, it's just as good for the creative stuff.
You've got lots and lots of stuff to choose from, and it's important to tag more often than you think necessary. I have found why.
Well, because the power of metadata, if you're writing in dock book and you have access to all of this metadata that you can provide, then you never know what you'll do with it.
Because if you, for instance, every time you mention Slack or Media, you put a brand, a product name, a tag around that, or every time you mention a certain program that you like to use, an application, put an application tag around that.
Every time you put a keyboard combination that you like to use, put key combo tags around that. All these tags, I mean, there's stuff for program listings, there's stuff for prompt, command, user input, computer output, just all kinds of stuff.
Well, use them because you never know what schema you'll find or what schema you'll develop that you can take advantage of all that metadata and make certain things different colors or different font faces or whatever.
Plus, if it's ever going to go online, then you never know what kind of magical CSS stuff you'll be able to do with it or whatever.
As long as you've got that metadata around the important elements of your document, really the sky is the limit. You're kind of future-proofing your document.
So use lots of tags right within the public in skeletal structure that they provide.
And really, the only setup is what we've just done. Public and create, and then make sure that you've got a good XML environment going on.
One thing that you will have to edit that you won't think you'll have to edit is this. Public and is fun.int.
It's got this little message in there. You need to change the holder entity in the EN-US. Public and is fun.int file.
And so we can write over that. That's some kind of entity holder thing. I don't know. It appears somewhere in the book. I don't remember where.
But that's one of those that you don't find out about until you don't configure it and it tells you. It's got this little message for you after you've built it and everything.
So do that. But other than that, everything's good. Everything's good to go. Just keep copying the master chapter.xml documents that they provide for you and follow its structure and you're writing.
Okay. Once you've written your book, your manual, your article, whatever you're writing, then the next thing to do is be able to build it into whatever you want to publish to.
This is one of those really, really powerful things that you just get for free with public and it's insane. You want to publish to plain text? No problem.
You want to publish to HTML? Not a problem. It'll make a whole little structured site with next buttons and home buttons and a table of contents with actual links to each section. That'll be done for you.
You want to publish to a PDF? That's really easy. But the cool thing is it's not just like a print to PDF kind of deal. No, this is a PDF with links in it. You open the PDF. You see the chapter of contents, the table of contents.
You see a chapter that you like. You click on it. It takes you to that page in that PDF. This is like one of the fancy PDFs. You want an EPUB for people's tablets and tablets and stuff. Then no problem. Public and can do that as well.
Again, this isn't one of those quickly converted. I'm going to take a PDF and deconstruct it and convert it to EPUB for you. That works. Calibra does it caliber. Does it very well. But this is the real deal. This takes your code and customizes it for that format.
RTF even. You can even do RTF. If you want to send this thing so that it looks pretty to some Microsoft user or Apple user, then you can do that too. They get a PDF or not a PDF and RTF so that they can still edit it if they want to. It looks very nice and it's very friendly and they don't panic.
So yeah, this is really powerful stuff and it's super easy. All you do is go into your little public and directory, which we're actually there already. Actually, I think I'm going to step back out one so that I'm seeing. Yeah, I want to be outside of the E and dash US folder. I don't know if that's necessary, but that's where I usually build from.
So public and space build space dash dash Langs like languages Langs equals in dash US and that's easy because that's the only folder we've got.
Dash dash formats equals, I don't know, take your pick. You can also comma delimit them so you could say PDF comma HTML comma RTF comma EPUB comma TXT. I think it's TXT. I don't know. I don't usually actually build out to plain text, but there you go.
PDF comma HTML comma RTF comma EPUB. Actually, I haven't done RTF lately either with public and so we're just going to reduce it to PDF HTML and EPUB and actually screw PDF EPUB rocks HTML comma EPUB and that'll spit out two versions of your book, both in English, both with all your images and your fancy little notes.
That'll be green in green boxes in your warnings and red boxes and your little house icon and the little arrows to go to the next page if it's HTML.
It's going to be brilliant. You will be so impressed. I mean, it's publishing. It's publishing made easy, but it looks so professional.
I probably didn't mention yet that this is the thing that Red Hat and Fedora and Jay Boss and all those companies, they use this for their official documentation. So it looks really, really nice and it just looks like you put a lot of effort into it and all you did was deconstruct a couple of XML tags and wrote very, very simple, very, very powerful.
That's about all there is to public. I hope that helps. I hope that's informative. And if you have any questions, hit me up about it because while I'm not a power user of it by any means, I do tend to use it a lot.
So let me know if you're not clear on anything, if it's not building correctly for you. If you don't know why it's telling you that something isn't invalid tag, whatever, ask away. Thanks for listening and go out and document something.
You have been listening to Hacker Public Radio at Hacker Public Radio. We are a community podcast network that releases shows every weekday Monday through Friday.
Today's show, like all our shows, was contributed by a HBR listener like yourself. If you ever consider recording a podcast, then visit our website to find out how easy it really is. Hacker Public Radio was founded by the digital dog pound and the economical and computer club.
HBR is funded by the binary revolution at binref.com, all binref projects are crowd-responsive by linear pages. From shared hosting to custom private clouds, go to lunarpages.com for all your hosting needs.
Unless otherwise stasis, today's show is released under a creative comments, attribution, share a line, read those own license.