A pragmatic toolchain
Peter, Steve
In this talk, we present the toolchain used to produce the award-winning Pragmatic Bookshelf titles and examine some of the pleasures and pitfalls encountered using TeX, XML, XSLT, Ruby and other open technologies.
 All right, good morning. I'm Steve Peter as this slide says. This morning I'm here representing the pragmatic programmers. I'm not technically an employee but an independent consultant or contract or whatever term you want to use, which has all the joys that you might think that entails. Like two minutes before I left for the airport to come here, I had all kinds of questions from authors to answer and say no, I'm going away for a week. Sorry folks. So who are the pragmatic programmers? Sounds like the beginning of Mythbusters here. Pragmatic programmers came about when two programmers, Andy Hunt and Dave Thomas, who was not the founder of Wendy's, but a different Dave Thomas. Both of them were programmers working out in industry for years and years. Andy worked at AT&T, Dave worked for AT&T at one point in different groups. But they got together and started comparing notes and realized that every time they got called to a consulting job that they were solving the same problem over and over again. And they decided that they would try to put their knowledge into a book, which they did and they called it the Pragmatic Programmer. They still got called to do the same thing over and over again because people weren't reading the book and following the advice. But if you haven't read the book and you do programming, I do recommend that it's a very good book. The part about it that I liked best when I first read it was they talk about documenting your work and if you're going to document it, you might as well make it look good. And there's a system out there called tech and you should use it. When I read through that, I thought, I like these guys. A couple years after they wrote the Pragmatic Programmer, they both discovered the Ruby programming language and immediately fell in love with it and said that it reflected exactly the way they thought about problems, that there was no need to conceptualize how they might solve it and then translate that into some programming language and then implement it, that they just sort of thought directly in Ruby and they could do it. So Ruby was created by a Japanese programmer and at the time all the documentation was in Japanese. So the two of them sat down and went through all the source code and wrote the book called Programming Ruby, which is now in the third edition that details the language, how to program it. We use a lot of Ruby at the Pragmatic Programmers, as you might expect. I can't say that my mind works exactly like Ruby. I'm forced to, after I think about it much, realize that the way my mind works is actually more like Pearl, which is sort of this mish-mash. It works great at one point and then you go back to figure out what you did six months later and you can't figure it out. Unfortunately, that is the way my mind works. But I am a linguist by trading and Larry Wall is a linguist. After these two books came out, they were very popular books and Andy and Dave being Pragmatic decided to buy back the rights to the books and start their own publishing enterprise that they called the Pragmatic Bookshelf. If you haven't read any of the Pragmatic books, I urge you at least to go to our website. I would show it to you now if I had connectivity, but I don't. And I would show you pictures of some of these if I had it when I was writing this last night, but I didn't. So you'll just have to go with the brown and brown instead of black and white. But go and look at the website or pick up some of our books. I don't get any extra money if a lot of these books sell well, but I do enjoy typesetting. A number of years after they started working on this enterprise, I should back up and say the Pragmatic Programmer, they typeset themselves. It started out as both of them have been at AT&T, or at least Andy was at the time. The original Pragmatic Programmer was written in T-Rough. And as it grew a little bit larger, they started having some issues with it and then took it to the publisher. And the publisher said, we don't really like the way this looks. Have you considered using this thing called tech? Our designer knows tech and can come up with something and created a layout for them in tech that they then used. And when they started the Pragmatic Bookshelf, they took that with them and started enhancing that tool chain. That's part of my problem these days, is that I inherited that tool chain that started years and years and years ago. And we heard in the first talk about legacy code and what do you do with these legacy formats. That's something that I face all the time. But anyway, a couple of years after they started this, I got an email from Andy saying, hey, we need somebody with some tech experience and who knows, XSLT, can you help us out? So I got my car drove to the bookstore and bought a book on XSLT. He flipped it and said, yeah, I can do this. And thus began my adventure with them that continues to this day. We'll go into that. What tool chain do we use? We use a bunch of things. All of our source code that the authors write is in XML. It's in our own DTD called Pragmatic Markup Language, or PML. We use Unix tools like Make. We use lots of Ruby, although we do have a few scripts in other languages. We've got a couple of Pearl scripts in, a couple of Python scripts. No will yet, but we'll probably be adding that at some point. We use XSLT, which I've now come to know. I don't know if I love it, but I deal with it. We use tech and we use PDF that we get through a couple of different routes. All of the books that we sell, we sell in either print versions or as PDF versions. And they get two different routes to PDF, depending on which one we use. Our print versions ultimately go through Acrobat because of the requirements of our printers. They throw hissy fits every time we try to do something different, so we generally take the last step through Acrobat. But the ones that we sell as PDF online, those go through the normal DVI, or I shouldn't say the normal anymore, DVI, PS, and then PS to PDF route. The books that we sell as PDFs aren't digitally rights managed. We do have certain information that's encoded into the PDF, and that's why we do the last automated step in there. But there's no big encryption that goes on. But that's one reason why we have to stick somewhat to the tool chain that we have. Now let me show you a demo of what we have here. All right, here is a typical file that an author might have. Should probably hook up my mouse so that I can do this more efficiently. What you can see here, what a typical PML file looks like. Looks like fairly stock XML. And then you can see there why I haven't been writing any books on tech recently. I've got Arn Swaggild into doing this book here. This has been occupying my time recently. But we take the XML, and the nice thing about this with using these mainly open source tools is that all of our authors can download this. This build system works brilliantly on any Unix-based system. So it works wonderfully on Linux, on Mac OS X. It can work on Windows, but you really have to bend over backwards. It's much better if you're using some sort of SigWin type environment, which is essentially then running Unix on your Windows machine. But it works well on Unix-based systems. So when I get ready to build a book, all I do is type make all, of course, goes through, pre-processes with a bunch of scripts, and then runs tech, runs bib tech, and then runs tech another two times to resolve everything. And you can see here it's running dvips and ps2pdf, and bingo we get output, which looks something like this. Now our pre-processing we use for coloring code. Let me get you some code here. Not anything exciting. I'm not going to scroll that. I'll use my screen set wrong. But you can see here the keywords in code are always colored. We can also, by throwing a different switch in the make process, by adding in a switch to the make process, we can make a screen version of this. This is going to be full and then crash. And that's a dummy color that I inserted there. But here's what our PDF versions look like. So they're colored for, they've got hyperlinks here, so you can go directly to a section, the URLs work, if we were online. And you can see down here, let me blow this up. You can see here our code is colored, literally. All right. Our source is generally organized into two different directories, a book directory and a pp stuff, pragmatic programmer stuff directory. The authors generally work out of the book directory. I do most of my stuff in two directories in the pp stuff. We have a tech directory that has all of our fun stuff in it. Most of this stuff that I'm modifying comes out of our style sheet, which is called pragprog.sty. So that's where I spend most of my time making tech changes. I won't really show you anything there. It's fairly standard. We use memoir as our class file, but it's fairly standard tech. There's nothing Earthshaking there. Our XML comes out of our DTD, and then we've got different formats that we can create from that XML. So we can go to an HTML. That's useful for some ebooks that are coming out that require HTML as their input file. We go to LaTeX. That's the one that I do most of my maintenance on. And then we have a couple of different ebook formats. The ebook space right now is in flux, but it's becoming much more important to us. I'll go in a little bit, present one of our problems that has to do with ebooks. But generally, we're trying to keep one of the two principles of the Pragmatic programmers is very keen in keeping our XML as the canonical source of all of our books that we can then do the conversion on, with tech being the main route that we're using right now. But we don't have to keep that in the future. So what are some of the issues that we have using this tool chain? Like I say, one thing to remember before I present the issues, because there are solutions that you can immediately see to some of these issues if we abandon the XML as the canonical source. But my hands are tied in this. I can't really abandon that. The first problem we're having is with hyperrefs in general. And until recently, our URLs have been a pain. I think knock on simulated wood grain finish that I have solved that problem. But it does keep popping up that the URLs aren't breaking properly that sometimes in the sidebars, if people read the book in Acrobat, the sidebars end up with tech code in them that then display. And they say, hey, what is this un-Vbox stuff that's sitting here? I can click on it and I get to something, but it's hard to get rid of. But right now, our biggest problem is with eBooks and reflowable PDF. Reflowable PDF means that you can change the size of your margins and the PDF will reflow automatically, as opposed to then having to pan back and forth. At this point, we're getting at least an email a day asking us when we're going to support all these different eBook formats like Kindle and various other ones. It's increasing in frequency and I'm getting a lot of pressure to be able to produce reflowable PDFs. I can't do that right now with stock tech and I need a solution. And I'm hoping that the collective brilliance in this room will provide me with a solution by the time I get on the plane. If not by the time I walk out the door this morning. So what can we use? Is LuaTech going to provide a solution? No. Is ZeeTech going to provide a solution? No. Is ZeeLuaTech going to provide a solution? The problem is with the idea of reflowable PDFs. What's LuaTech? Well, yeah, but... I have a solution for you. Okay, we've got a solution. Yes, it's very easy. You just, instead of doing full reflowable, then you can change it in all ways. You can make several copies with different size screens. And when they change the size, you actually allow them to stick to the next grid level. And substitute the copy you want. But a lot of ebook formats aren't going to allow me to input several different... Like if I put into it, say, Kindle, it won't allow me to put in multiple inputs. I need to look how Kindle format is there, right? Yeah, it's... I think it's possible to do it. All right, if we can do that great. So these are kind of engine problems. Then there's a question of what format we can then use. And that kind of ties in. It's orthogonal, but it's related. And we can use basically anything. And, you know, even E-plane is fine, because I'm really the only one who has to deal with the tech aspect of it. Until very recently, Dave dealt a lot with the tech, too. But Dave's spending most of his time these days writing Ruby on Rails. And I'd rather him do that than me have to do that. And I'd rather do the tech. Do we do some new format that's not any of these that then incorporates this? Now, the carrot to place in front of this group that's in front of me there with these different formats and different engines, we can provide some funding to do some of this. It would be in dollars, which I realize is funny money these days. But if need be, we can come up with euros or Ruble or Grohmar, whatever we want. Monopoly money works well, too. And if we can't get satisfaction out of this, we may have to switch away from tech. We do know that XSLFO, as much as it pains me, does work and does produce reflowable PDF. And since we've already got part of XML in our tool chain, it can be done. It doesn't look as good as tech. But if we can get eBooks out of it, we may have to use tech for our print and on-screen PDF and then use XSLFO to do the reflowable eBook formats. I prefer not to do that. So maybe that might be an additional inducement. Please help us keep tech in this. But that's basically what I want to present to you. Are there any questions? And hopefully, are there solutions? We've got another solution. It's not about solutions. I have to talk to you about this afterwards. I have some ideas, but here are the questions. The question is about tools. First, what do you offer to use to produce XML? Do they just type in editor like Emacs or with a text? We don't actually... We've got a few things that we offer for Emacs users and for textmate users. We've got some macros in there to help them out. But we generally let the author use whatever they want to type in the XML. What do you use? I go back and forth between Emacs and textmate when I'm authoring, depending on what I'm doing. And second question, what do you do to convert from XML to all these forms according to your... XSLT. Yeah. I think it's the Xerxes. What? Xerxes? I think that's what we're using. I rarely get into it. I just sort of... I do my XSL format and then just run it through. But I think we're using Xerxes. There. Hans. I'm just going to start with two remarks. First is if you want the reflow, why don't you just use HTML for these people? Or alternatively, just generate a different PDF in the right...... and a different form of that? Why do you want the reflow? Well, because some of the ebook formats require... Some do take HTML as input and those were fine on. Yeah. But you can use PDF and some don't... There's no aspect ratio. It depends on what the user sets. So that has to be reflow. If you look at like this...... we have one of those ebook things. If you just generate it in a nice format, fitting the screen...... that doesn't solve the problem if somebody is using a mobile phone and then wants to change the website. You need to reflow so you don't have to scroll. But I'm over from, I think, any reflow. Yeah, I mean, it's kind of like... How about you're going to say that you have... Okay, use the pages for the pragmatic problem. Just look to other... Simple. But if you have a group which has a little bit of more...... click on the page. Maybe you can use Mike's headings and Mike's titles and whatever. How do you reflow them? If you have the design book... Right, I mean, but that's the general ebook problem...... that I can't really solve as a book designer. But I can't throw this strictly to the support department...... because they're going to get tons of emails every day saying, hey, I spent $30 on this ebook and it looks like crap on my reader. I think that getting it looks like crap. But the question is, how do you...... less crap is it... You just made the other half a piece of the solution. That's the problem you solved. That means why the private conversation, please. John. I don't know what engine is used to reflow in PGA. But I'm sure it's not tech. And it would be wonderful if it were tech or something related to tech. And if that was the case, then the whole problem would almost certainly be a lot easier...... because there'd be a close relationship between what we're doing here and what we're doing there. And whilst this doesn't help you because the answer I'm giving you is, if I wanted to do that, I wouldn't start from here, we have had enormous misopportunity over the past 20 years in that we have not packaged tech...... or an extension of tech in such a way that it can be used, for example, as a reflow engine for PGA. So this problem is actually of our own making, because we have not addressed the issue of packaging the engine tech for an extension of tech...... so that it can be used for this sort of purpose. We've missed that opportunity. There's an old saying that every problem, there's an opportunity in it, but here's the problem, and I think there's the opportunity in it, which is one that we've missed. Now I do have a question, which is there's clearly a lot of interest in what you're doing...... and you're bringing in fresh and interesting problems coming from real opportunities out there. So, would you like to organize a session where people have a strong interest and this can get together? Sure. How do we do that? We'll work on that in a bit. Alright. You said that you were producing your PDS in the ODS, and that PDS was called that. Do you consider it a PDS, though? Yes. The reason why, as of right now, we're still doing it this way is because the original pragmatic programmer...... and the original programming Ruby rely heavily on PDS tricks for certain things that are on the page. And every time I suggest that we get away from that, there's strong interest in it, and then the very next book...... somebody says, oh, I want to do that. And I really haven't had the time yet to reimplement all the stuff that we're currently using with PDS tricks...... into something that I can use with PDF tech. But yes, I would like to get away from that. It strikes me that the brain replays, re-tubles PDS and something with PDF tech, but the writing breaks down. Right. Yeah, I agree. How does the thumb have an experimental footage that can be implemented? Yes, we have some that can do it. Can you please answer this? Yes. I think you say that you have this other solution that can use your verbal PDF. Yes. But then you said that I want to stay with tech. My question is, is that a purely religious statement, or are there practical reasons? There's aesthetic reasons. XSLFO produces wonderful reflowable PDF. It just doesn't look as good as tech. Yeah. And I, coming from... That's such a property of reflowable stuff that you produce. I don't know. No, because I can take XSLFO and produce a non-reflowable PDF that looks similar, but not quite as good as the tech output. Which is so much the same as I'm suggesting that to have it reflowable, you're not going to get the photographic quality. Probably. So that's something to do with what... I mean, renewable reflowable PDF is a clutch, I mean, it's still in the city, but you can have it done. Right. It's not worth knowing how it's done. Yeah. And part of it too is pure laziness on my part in that you saw the number of XSLTFiles I had to have already. And I would much rather be able to just maintain the PPV to LATAC file and get everything in there. And actually, unfortunately, that's what I spend most of my life doing. That's a practical reason. You know, and now if I have to maintain an HTML, because the Kindle stuff comes off of HTML. But has anybody used Kindle here? It's utterly unusable for programming books. Kindle provides you with two fonts, a sans-serif and a serif. There's no fix with font. So you can't do code listings. And it converts everything to black and white. So any screenshots you show get pixelated beyond belief. I can show you some horrible shots of we tried to produce one book through just to see what it would look like. And it practically turned my stomach. But one of our other non-technical members of the team said, eh, you guys are too picky. It looks fine to me. So that may be the case that I'm too much of an esthete to be able to do that. I don't know if this makes sense. If you could get XSLFO, so to speak, off the back end of 10, would that solve your problem? Sure. I don't know how you would do that though. Now the second question is, could you do any better than that in terms of quality of the output? Is it possible to do? In other words, does the optimum route pass through XSLFO in terms of quality of the output? I don't know. I don't know. I would have to try and see what came out. That's a pragmatic answer. Yes, yes. That's a very hidden house called for the Germans in the audience. I'm going to read in the very different books. But we have to change the pages. Do people really play one of those? Yes, yes. The reason why I wrote that last year's tech conference was that I was in Moscow for several months. I brought a bunch of books with me on my computer to read. I spent a lot of time reading on my computer. I guess maybe I'm just too old, but I agree with you. I don't find it an enjoyable experience. I much prefer having... I'll have you use the info format to press space and just change the page. Apart from that, it's when you're all the time scrolling up and down the screen, you're going to be able to sit the opposition. Yes, well, with my eyes, I was having to have it blown up extremely big. I don't enjoy it, but the young folks seem to enjoy doing it. I do know plenty of people who have read tons of books on their cell phone. I can't do it. I mean, I read when I had my old... What was it? It was a poem, I guess, at the time. I read Zane Gray on it, and that's the only thing I've ever been able to do was know something light like that I could handle, but anything more technical, it just gets to be a nightmare. And especially if you've got a programming book or something like a Photoshop book, where you've got to have screenshots in there. Once you get these little screens, it's impossible. I am a phogy, I guess, is what it comes down to. All right.
 All right, good morning. I'm Steve Peter as this slide says. This morning I'm here representing the pragmatic programmers. I'm not technically an employee but an independent consultant or contract or whatever term you want to use, which has all the joys that you might think that entails.  Like two minutes before I left for the airport to come here, I had all kinds of questions from authors to answer and say no, I'm going away for a week. Sorry folks.  So who are the pragmatic programmers? Sounds like the beginning of Mythbusters here.  Pragmatic programmers came about when two programmers, Andy Hunt and Dave Thomas, who was not the founder of Wendy's, but a different Dave Thomas.  Both of them were programmers working out in industry for years and years. Andy worked at AT&T, Dave worked for AT&T at one point in different groups.  But they got together and started comparing notes and realized that every time they got called to a consulting job that they were solving the same problem over and over again.  And they decided that they would try to put their knowledge into a book, which they did and they called it the Pragmatic Programmer.  They still got called to do the same thing over and over again because people weren't reading the book and following the advice.  But if you haven't read the book and you do programming, I do recommend that it's a very good book.  The part about it that I liked best when I first read it was they talk about documenting your work and if you're going to document it, you might as well make it look good.  And there's a system out there called tech and you should use it. When I read through that, I thought, I like these guys.  A couple years after they wrote the Pragmatic Programmer, they both discovered the Ruby programming language and immediately fell in love with it and said that it reflected exactly the way they thought about problems,  that there was no need to conceptualize how they might solve it and then translate that into some programming language and then implement it, that they just sort of thought directly in Ruby and they could do it.  So Ruby was created by a Japanese programmer and at the time all the documentation was in Japanese.  So the two of them sat down and went through all the source code and wrote the book called Programming Ruby, which is now in the third edition that details the language, how to program it.  We use a lot of Ruby at the Pragmatic Programmers, as you might expect.  I can't say that my mind works exactly like Ruby.  I'm forced to, after I think about it much, realize that the way my mind works is actually more like Pearl, which is sort of this mish-mash.  It works great at one point and then you go back to figure out what you did six months later and you can't figure it out.  Unfortunately, that is the way my mind works.  But I am a linguist by trading and Larry Wall is a linguist.  After these two books came out, they were very popular books and Andy and Dave being Pragmatic decided to buy back the rights to the books and start their own publishing enterprise that they called the Pragmatic Bookshelf.  If you haven't read any of the Pragmatic books, I urge you at least to go to our website.  I would show it to you now if I had connectivity, but I don't. And I would show you pictures of some of these if I had it when I was writing this last night, but I didn't.  So you'll just have to go with the brown and brown instead of black and white.  But go and look at the website or pick up some of our books.  I don't get any extra money if a lot of these books sell well, but I do enjoy typesetting.  A number of years after they started working on this enterprise, I should back up and say the Pragmatic Programmer, they typeset themselves.  It started out as both of them have been at AT&T, or at least Andy was at the time.  The original Pragmatic Programmer was written in T-Rough.  And as it grew a little bit larger, they started having some issues with it and then took it to the publisher. And the publisher said, we don't really like the way this looks.  Have you considered using this thing called tech?  Our designer knows tech and can come up with something and created a layout for them in tech that they then used.  And when they started the Pragmatic Bookshelf, they took that with them and started enhancing that tool chain.  That's part of my problem these days, is that I inherited that tool chain that started years and years and years ago.  And we heard in the first talk about legacy code and what do you do with these legacy formats. That's something that I face all the time.  But anyway, a couple of years after they started this, I got an email from Andy saying, hey, we need somebody with some tech experience and who knows, XSLT, can you help us out?  So I got my car drove to the bookstore and bought a book on XSLT.  He flipped it and said, yeah, I can do this. And thus began my adventure with them that continues to this day.  We'll go into that. What tool chain do we use?  We use a bunch of things. All of our source code that the authors write is in XML. It's in our own DTD called Pragmatic Markup Language, or PML.  We use Unix tools like Make. We use lots of Ruby, although we do have a few scripts in other languages.  We've got a couple of Pearl scripts in, a couple of Python scripts. No will yet, but we'll probably be adding that at some point.  We use XSLT, which I've now come to know. I don't know if I love it, but I deal with it.  We use tech and we use PDF that we get through a couple of different routes. All of the books that we sell, we sell in either print versions or as PDF versions.  And they get two different routes to PDF, depending on which one we use.  Our print versions ultimately go through Acrobat because of the requirements of our printers.  They throw hissy fits every time we try to do something different, so we generally take the last step through Acrobat.  But the ones that we sell as PDF online, those go through the normal DVI, or I shouldn't say the normal anymore, DVI, PS, and then PS to PDF route.  The books that we sell as PDFs aren't digitally rights managed.  We do have certain information that's encoded into the PDF, and that's why we do the last automated step in there.  But there's no big encryption that goes on.  But that's one reason why we have to stick somewhat to the tool chain that we have.  Now let me show you a demo of what we have here.  All right, here is a typical file that an author might have.  Should probably hook up my mouse so that I can do this more efficiently.  What you can see here, what a typical PML file looks like.  Looks like fairly stock XML.  And then you can see there why I haven't been writing any books on tech recently.  I've got Arn Swaggild into doing this book here.  This has been occupying my time recently.  But we take the XML, and the nice thing about this with using these mainly open source tools is that all of our authors can download this.  This build system works brilliantly on any Unix-based system.  So it works wonderfully on Linux, on Mac OS X.  It can work on Windows, but you really have to bend over backwards.  It's much better if you're using some sort of SigWin type environment, which is essentially then running Unix on your Windows machine.  But it works well on Unix-based systems.  So when I get ready to build a book, all I do is type make all, of course, goes through, pre-processes with a bunch of scripts,  and then runs tech, runs bib tech, and then runs tech another two times to resolve everything.  And you can see here it's running dvips and ps2pdf, and bingo we get output, which looks something like this.  Now our pre-processing we use for coloring code.  Let me get you some code here.  Not anything exciting.  I'm not going to scroll that.  I'll use my screen set wrong.  But you can see here the keywords in code are always colored.  We can also, by throwing a different switch in the make process,  by adding in a switch to the make process, we can make a screen version of this.  This is going to be full and then crash.  And that's a dummy color that I inserted there.  But here's what our PDF versions look like.  So they're colored for, they've got hyperlinks here, so you can go directly to a section, the URLs work, if we were online.  And you can see down here, let me blow this up.  You can see here our code is colored, literally.  All right.  Our source is generally organized into two different directories, a book directory and a pp stuff, pragmatic programmer stuff directory.  The authors generally work out of the book directory.  I do most of my stuff in two directories in the pp stuff.  We have a tech directory that has all of our fun stuff in it.  Most of this stuff that I'm modifying comes out of our style sheet, which is called pragprog.sty.  So that's where I spend most of my time making tech changes.  I won't really show you anything there.  It's fairly standard. We use memoir as our class file, but it's fairly standard tech.  There's nothing Earthshaking there.  Our XML comes out of our DTD, and then we've got different formats that we can create from that XML.  So we can go to an HTML.  That's useful for some ebooks that are coming out that require HTML as their input file.  We go to LaTeX. That's the one that I do most of my maintenance on.  And then we have a couple of different ebook formats.  The ebook space right now is in flux, but it's becoming much more important to us.  I'll go in a little bit, present one of our problems that has to do with ebooks.  But generally, we're trying to keep one of the two principles of the Pragmatic programmers is very keen in keeping our XML as the canonical source of all of our books that we can then do the conversion on,  with tech being the main route that we're using right now.  But we don't have to keep that in the future.  So what are some of the issues that we have using this tool chain?  Like I say, one thing to remember before I present the issues, because there are solutions that you can immediately see to some of these issues if we abandon the XML as the canonical source.  But my hands are tied in this. I can't really abandon that.  The first problem we're having is with hyperrefs in general.  And until recently, our URLs have been a pain. I think knock on simulated wood grain finish that I have solved that problem.  But it does keep popping up that the URLs aren't breaking properly that sometimes in the sidebars, if people read the book in Acrobat, the sidebars end up with tech code in them that then display.  And they say, hey, what is this un-Vbox stuff that's sitting here?  I can click on it and I get to something, but it's hard to get rid of.  But right now, our biggest problem is with eBooks and reflowable PDF.  Reflowable PDF means that you can change the size of your margins and the PDF will reflow automatically, as opposed to then having to pan back and forth.  At this point, we're getting at least an email a day asking us when we're going to support all these different eBook formats like Kindle and various other ones.  It's increasing in frequency and I'm getting a lot of pressure to be able to produce reflowable PDFs.  I can't do that right now with stock tech and I need a solution.  And I'm hoping that the collective brilliance in this room will provide me with a solution by the time I get on the plane.  If not by the time I walk out the door this morning.  So what can we use?  Is LuaTech going to provide a solution?  No.  Is ZeeTech going to provide a solution?  No.  Is ZeeLuaTech going to provide a solution?  The problem is with the idea of reflowable PDFs.  What's LuaTech?  Well, yeah, but...  I have a solution for you.  Okay, we've got a solution.  Yes, it's very easy.  You just, instead of doing full reflowable, then you can change it in all ways.  You can make several copies with different size screens.  And when they change the size, you actually allow them to stick to the next grid level.  And substitute the copy you want.  But a lot of ebook formats aren't going to allow me to input several different...  Like if I put into it, say, Kindle, it won't allow me to put in multiple inputs.  I need to look how Kindle format is there, right?  Yeah, it's...  I think it's possible to do it.  All right, if we can do that great.  So these are kind of engine problems.  Then there's a question of what format we can then use.  And that kind of ties in.  It's orthogonal, but it's related.  And we can use basically anything.  And, you know, even E-plane is fine,  because I'm really the only one who has to deal with the tech aspect of it.  Until very recently, Dave dealt a lot with the tech, too.  But Dave's spending most of his time these days writing Ruby on Rails.  And I'd rather him do that than me have to do that.  And I'd rather do the tech.  Do we do some new format that's not any of these that then incorporates this?  Now, the carrot to place in front of this group that's in front of me there  with these different formats and different engines,  we can provide some funding to do some of this.  It would be in dollars, which I realize is funny money these days.  But if need be, we can come up with euros or Ruble or Grohmar, whatever we want.  Monopoly money works well, too.  And if we can't get satisfaction out of this,  we may have to switch away from tech.  We do know that XSLFO, as much as it pains me, does work  and does produce reflowable PDF.  And since we've already got part of XML in our tool chain, it can be done.  It doesn't look as good as tech.  But if we can get eBooks out of it,  we may have to use tech for our print and on-screen PDF  and then use XSLFO to do the reflowable eBook formats.  I prefer not to do that.  So maybe that might be an additional inducement.  Please help us keep tech in this.  But that's basically what I want to present to you.  Are there any questions?  And hopefully, are there solutions?  We've got another solution.  It's not about solutions.  I have to talk to you about this afterwards.  I have some ideas, but here are the questions.  The question is about tools.  First, what do you offer to use to produce XML?  Do they just type in editor like Emacs or with a text?  We don't actually...  We've got a few things that we offer for Emacs users and for textmate users.  We've got some macros in there to help them out.  But we generally let the author use whatever they want to type in the XML.  What do you use?  I go back and forth between Emacs and textmate when I'm authoring,  depending on what I'm doing.  And second question, what do you do to convert from XML to all these forms according to your...  XSLT.  Yeah.  I think it's the Xerxes.  What?  Xerxes? I think that's what we're using.  I rarely get into it.  I just sort of...  I do my XSL format and then just run it through.  But I think we're using Xerxes.  There. Hans.  I'm just going to start with two remarks. First is if you want the reflow, why don't you just use HTML  for these people?  Or alternatively, just generate a different PDF in the right... ... and a different form of that?  Why do you want the reflow?  Well, because some of the ebook formats require...  Some do take HTML as input and those were fine on.  Yeah.  But you can use PDF and some don't...  There's no aspect ratio. It depends on what the user sets.  So that has to be reflow.  If you look at like this... ... we have one of those ebook things.  If you just generate it in a nice format, fitting the screen... ... that doesn't solve the problem if somebody is using a mobile phone and then wants to change the website.  You need to reflow so you don't have to scroll.  But I'm over from, I think, any reflow.  Yeah, I mean, it's kind of like...  How about you're going to say that you have...  Okay, use the pages for the pragmatic problem.  Just look to other...  Simple.  But if you have a group which has a little bit of more... ... click on the page.  Maybe you can use Mike's headings and Mike's titles and whatever.  How do you reflow them?  If you have the design book...  Right, I mean, but that's the general ebook problem... ... that I can't really solve as a book designer.  But I can't throw this strictly to the support department... ... because they're going to get tons of emails every day saying,  hey, I spent $30 on this ebook and it looks like crap on my reader.  I think that getting it looks like crap.  But the question is, how do you... ... less crap is it...  You just made the other half a piece of the solution.  That's the problem you solved.  That means why the private conversation, please.  John.  I don't know what engine is used to reflow in PGA.  But I'm sure it's not tech.  And it would be wonderful if it were tech or something related to tech.  And if that was the case, then the whole problem would almost certainly be a lot easier... ... because there'd be a close relationship between what we're doing here and what we're doing there.  And whilst this doesn't help you because the answer I'm giving you is,  if I wanted to do that, I wouldn't start from here,  we have had enormous misopportunity over the past 20 years in that we have not packaged tech... ... or an extension of tech in such a way that it can be used, for example, as a reflow engine for PGA.  So this problem is actually of our own making,  because we have not addressed the issue of packaging the engine tech for an extension of tech... ... so that it can be used for this sort of purpose.  We've missed that opportunity.  There's an old saying that every problem, there's an opportunity in it,  but here's the problem, and I think there's the opportunity in it, which is one that we've missed.  Now I do have a question, which is there's clearly a lot of interest in what you're doing... ... and you're bringing in fresh and interesting problems coming from real opportunities out there.  So, would you like to organize a session where people have a strong interest and this can get together?  Sure.  How do we do that?  We'll work on that in a bit.  Alright.  You said that you were producing your PDS in the ODS, and that PDS was called that.  Do you consider it a PDS, though?  Yes.  The reason why, as of right now, we're still doing it this way is because the original pragmatic programmer... ... and the original programming Ruby rely heavily on PDS tricks for certain things that are on the page.  And every time I suggest that we get away from that, there's strong interest in it, and then the very next book... ... somebody says, oh, I want to do that.  And I really haven't had the time yet to reimplement all the stuff that we're currently using with PDS tricks... ... into something that I can use with PDF tech.  But yes, I would like to get away from that.  It strikes me that the brain replays, re-tubles PDS and something with PDF tech, but the writing breaks down.  Right.  Yeah, I agree.  How does the thumb have an experimental footage that can be implemented?  Yes, we have some that can do it.  Can you please answer this?  Yes.  I think you say that you have this other solution that can use your verbal PDF.  Yes.  But then you said that I want to stay with tech.  My question is, is that a purely religious statement, or are there practical reasons?  There's aesthetic reasons. XSLFO produces wonderful reflowable PDF.  It just doesn't look as good as tech.  Yeah.  And I, coming from...  That's such a property of reflowable stuff that you produce.  I don't know.  No, because I can take XSLFO and produce a non-reflowable PDF that looks similar, but not quite as good as the tech output.  Which is so much the same as I'm suggesting that to have it reflowable, you're not going to get the photographic quality.  Probably.  So that's something to do with what...  I mean, renewable reflowable PDF is a clutch, I mean, it's still in the city, but you can have it done.  Right.  It's not worth knowing how it's done.  Yeah.  And part of it too is pure laziness on my part in that you saw the number of XSLTFiles I had to have already.  And I would much rather be able to just maintain the PPV to LATAC file and get everything in there.  And actually, unfortunately, that's what I spend most of my life doing.  That's a practical reason.  You know, and now if I have to maintain an HTML, because the Kindle stuff comes off of HTML.  But has anybody used Kindle here?  It's utterly unusable for programming books.  Kindle provides you with two fonts, a sans-serif and a serif.  There's no fix with font.  So you can't do code listings.  And it converts everything to black and white.  So any screenshots you show get pixelated beyond belief.  I can show you some horrible shots of we tried to produce one book through just to see what it would look like.  And it practically turned my stomach.  But one of our other non-technical members of the team said,  eh, you guys are too picky.  It looks fine to me.  So that may be the case that I'm too much of an esthete to be able to do that.  I don't know if this makes sense.  If you could get XSLFO, so to speak, off the back end of 10, would that solve your problem?  Sure. I don't know how you would do that though.  Now the second question is, could you do any better than that in terms of quality of the output?  Is it possible to do?  In other words, does the optimum route pass through XSLFO in terms of quality of the output?  I don't know. I don't know.  I would have to try and see what came out.  That's a pragmatic answer.  Yes, yes. That's a very hidden house called for the Germans in the audience.  I'm going to read in the very different books.  But we have to change the pages.  Do people really play one of those?  Yes, yes.  The reason why I wrote that last year's tech conference was that I was in Moscow for several months.  I brought a bunch of books with me on my computer to read. I spent a lot of time reading on my computer.  I guess maybe I'm just too old, but I agree with you. I don't find it an enjoyable experience.  I much prefer having...  I'll have you use the info format to press space and just change the page.  Apart from that, it's when you're all the time scrolling up and down the screen,  you're going to be able to sit the opposition.  Yes, well, with my eyes, I was having to have it blown up extremely big.  I don't enjoy it, but the young folks seem to enjoy doing it.  I do know plenty of people who have read tons of books on their cell phone.  I can't do it.  I mean, I read when I had my old...  What was it? It was a poem, I guess, at the time.  I read Zane Gray on it, and that's the only thing I've ever been able to do was know something light like that I could handle,  but anything more technical, it just gets to be a nightmare.  And especially if you've got a programming book or something like a Photoshop book,  where you've got to have screenshots in there.  Once you get these little screens, it's impossible.  I am a phogy, I guess, is what it comes down to.  All right.
A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_0_767.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_768_8831.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_8832_11795.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_11796_11951.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_11952_11999.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_12000_12107.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_12108_12155.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_12156_12467.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_12468_12527.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_12528_13019.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_13020_13067.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_13068_13151.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_13152_14147.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_14148_14243.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_14244_14291.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_14292_14651.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_14652_14747.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_14748_14807.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_14808_14879.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_14880_14927.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_14928_14975.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_14976_15023.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_15024_15083.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_15084_15311.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_15312_15527.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_15528_16547.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_16548_16811.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_16812_16871.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_16872_17075.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_17076_17123.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_17124_17375.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_17376_17435.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_17436_17483.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_17484_17531.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_17532_17711.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_17712_17807.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_17808_17891.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_17892_18227.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_18228_18347.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_18348_18395.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_18396_20651.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_20652_20711.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_20712_20771.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_20772_28895.png A_pragmatic_toolchain__TeX_and_friends_and_friends_of_friends_28896_45978.png
All right, good morning. I'm Steve Peter as this slide says. This morning I'm here representing the pragmatic programmers. I'm not technically an employee but an independent consultant or contract or whatever term you want to use, which has all the joys that you might think that entails. Like two minutes before I left for the airport to come here, I had all kinds of questions from authors to answer and say no, I'm going away for a week. Sorry folks. So who are the pragmatic programmers? Sounds like the beginning of Mythbusters here. Pragmatic programmers came about when two programmers, Andy Hunt and Dave Thomas, who was not the founder of Wendy's, but a different Dave Thomas. Both of them were programmers working out in industry for years and years. Andy worked at AT&T, Dave worked for AT&T at one point in different groups. But they got together and started comparing notes and realized that every time they got called to a consulting job that they were solving the same problem over and over again. And they decided that they would try to put their knowledge into a book, which they did and they called it the Pragmatic Programmer. They still got called to do the same thing over and over again because people weren't reading the book and following the advice. But if you haven't read the book and you do programming, I do recommend that it's a very good book. The part about it that I liked best when I first read it was they talk about documenting your work and if you're going to document it, you might as well make it look good. And there's a system out there called tech and you should use it. When I read through that, I thought, I like these guys. A couple years after they wrote the Pragmatic Programmer, they both discovered the Ruby programming language and immediately fell in love with it and said that it reflected exactly the way they thought about problems, that there was no need to conceptualize how they might solve it and then translate that into some programming language and then implement it, that they just sort of thought directly in Ruby and they could do it. So Ruby was created by a Japanese programmer and at the time all the documentation was in Japanese. So the two of them sat down and went through all the source code and wrote the book called Programming Ruby, which is now in the third edition that details the language, how to program it. We use a lot of Ruby at the Pragmatic Programmers, as you might expect. I can't say that my mind works exactly like Ruby. I'm forced to, after I think about it much, realize that the way my mind works is actually more like Pearl, which is sort of this mish-mash. It works great at one point and then you go back to figure out what you did six months later and you can't figure it out. Unfortunately, that is the way my mind works. But I am a linguist by trading and Larry Wall is a linguist. After these two books came out, they were very popular books and Andy and Dave being Pragmatic decided to buy back the rights to the books and start their own publishing enterprise that they called the Pragmatic Bookshelf. If you haven't read any of the Pragmatic books, I urge you at least to go to our website. I would show it to you now if I had connectivity, but I don't. And I would show you pictures of some of these if I had it when I was writing this last night, but I didn't. So you'll just have to go with the brown and brown instead of black and white. But go and look at the website or pick up some of our books. I don't get any extra money if a lot of these books sell well, but I do enjoy typesetting. A number of years after they started working on this enterprise, I should back up and say the Pragmatic Programmer, they typeset themselves. It started out as both of them have been at AT&T, or at least Andy was at the time. The original Pragmatic Programmer was written in T-Rough. And as it grew a little bit larger, they started having some issues with it and then took it to the publisher. And the publisher said, we don't really like the way this looks. Have you considered using this thing called tech? Our designer knows tech and can come up with something and created a layout for them in tech that they then used. And when they started the Pragmatic Bookshelf, they took that with them and started enhancing that tool chain. That's part of my problem these days, is that I inherited that tool chain that started years and years and years ago. And we heard in the first talk about legacy code and what do you do with these legacy formats. That's something that I face all the time. But anyway, a couple of years after they started this, I got an email from Andy saying, hey, we need somebody with some tech experience and who knows, XSLT, can you help us out? So I got my car drove to the bookstore and bought a book on XSLT. He flipped it and said, yeah, I can do this. And thus began my adventure with them that continues to this day. We'll go into that. What tool chain do we use? We use a bunch of things. All of our source code that the authors write is in XML. It's in our own DTD called Pragmatic Markup Language, or PML. We use Unix tools like Make. We use lots of Ruby, although we do have a few scripts in other languages. We've got a couple of Pearl scripts in, a couple of Python scripts. No will yet, but we'll probably be adding that at some point. We use XSLT, which I've now come to know. I don't know if I love it, but I deal with it. We use tech and we use PDF that we get through a couple of different routes. All of the books that we sell, we sell in either print versions or as PDF versions. And they get two different routes to PDF, depending on which one we use. Our print versions ultimately go through Acrobat because of the requirements of our printers. They throw hissy fits every time we try to do something different, so we generally take the last step through Acrobat. But the ones that we sell as PDF online, those go through the normal DVI, or I shouldn't say the normal anymore, DVI, PS, and then PS to PDF route. The books that we sell as PDFs aren't digitally rights managed. We do have certain information that's encoded into the PDF, and that's why we do the last automated step in there. But there's no big encryption that goes on. But that's one reason why we have to stick somewhat to the tool chain that we have. Now let me show you a demo of what we have here. All right, here is a typical file that an author might have. Should probably hook up my mouse so that I can do this more efficiently. What you can see here, what a typical PML file looks like. Looks like fairly stock XML. And then you can see there why I haven't been writing any books on tech recently. I've got Arn Swaggild into doing this book here. This has been occupying my time recently. But we take the XML, and the nice thing about this with using these mainly open source tools is that all of our authors can download this. This build system works brilliantly on any Unix-based system. So it works wonderfully on Linux, on Mac OS X. It can work on Windows, but you really have to bend over backwards. It's much better if you're using some sort of SigWin type environment, which is essentially then running Unix on your Windows machine. But it works well on Unix-based systems. So when I get ready to build a book, all I do is type make all, of course, goes through, pre-processes with a bunch of scripts, and then runs tech, runs bib tech, and then runs tech another two times to resolve everything. And you can see here it's running dvips and ps2pdf, and bingo we get output, which looks something like this. Now our pre-processing we use for coloring code. Let me get you some code here. Not anything exciting. I'm not going to scroll that. I'll use my screen set wrong. But you can see here the keywords in code are always colored. We can also, by throwing a different switch in the make process, by adding in a switch to the make process, we can make a screen version of this. This is going to be full and then crash. And that's a dummy color that I inserted there. But here's what our PDF versions look like. So they're colored for, they've got hyperlinks here, so you can go directly to a section, the URLs work, if we were online. And you can see down here, let me blow this up. You can see here our code is colored, literally. All right. Our source is generally organized into two different directories, a book directory and a pp stuff, pragmatic programmer stuff directory. The authors generally work out of the book directory. I do most of my stuff in two directories in the pp stuff. We have a tech directory that has all of our fun stuff in it. Most of this stuff that I'm modifying comes out of our style sheet, which is called pragprog.sty. So that's where I spend most of my time making tech changes. I won't really show you anything there. It's fairly standard. We use memoir as our class file, but it's fairly standard tech. There's nothing Earthshaking there. Our XML comes out of our DTD, and then we've got different formats that we can create from that XML. So we can go to an HTML. That's useful for some ebooks that are coming out that require HTML as their input file. We go to LaTeX. That's the one that I do most of my maintenance on. And then we have a couple of different ebook formats. The ebook space right now is in flux, but it's becoming much more important to us. I'll go in a little bit, present one of our problems that has to do with ebooks. But generally, we're trying to keep one of the two principles of the Pragmatic programmers is very keen in keeping our XML as the canonical source of all of our books that we can then do the conversion on, with tech being the main route that we're using right now. But we don't have to keep that in the future. So what are some of the issues that we have using this tool chain? Like I say, one thing to remember before I present the issues, because there are solutions that you can immediately see to some of these issues if we abandon the XML as the canonical source. But my hands are tied in this. I can't really abandon that. The first problem we're having is with hyperrefs in general. And until recently, our URLs have been a pain. I think knock on simulated wood grain finish that I have solved that problem. But it does keep popping up that the URLs aren't breaking properly that sometimes in the sidebars, if people read the book in Acrobat, the sidebars end up with tech code in them that then display. And they say, hey, what is this un-Vbox stuff that's sitting here? I can click on it and I get to something, but it's hard to get rid of. But right now, our biggest problem is with eBooks and reflowable PDF. Reflowable PDF means that you can change the size of your margins and the PDF will reflow automatically, as opposed to then having to pan back and forth. At this point, we're getting at least an email a day asking us when we're going to support all these different eBook formats like Kindle and various other ones. It's increasing in frequency and I'm getting a lot of pressure to be able to produce reflowable PDFs. I can't do that right now with stock tech and I need a solution. And I'm hoping that the collective brilliance in this room will provide me with a solution by the time I get on the plane. If not by the time I walk out the door this morning. So what can we use? Is LuaTech going to provide a solution? No. Is ZeeTech going to provide a solution? No. Is ZeeLuaTech going to provide a solution? The problem is with the idea of reflowable PDFs. What's LuaTech? Well, yeah, but... I have a solution for you. Okay, we've got a solution. Yes, it's very easy. You just, instead of doing full reflowable, then you can change it in all ways. You can make several copies with different size screens. And when they change the size, you actually allow them to stick to the next grid level. And substitute the copy you want. But a lot of ebook formats aren't going to allow me to input several different... Like if I put into it, say, Kindle, it won't allow me to put in multiple inputs. I need to look how Kindle format is there, right? Yeah, it's... I think it's possible to do it. All right, if we can do that great. So these are kind of engine problems. Then there's a question of what format we can then use. And that kind of ties in. It's orthogonal, but it's related. And we can use basically anything. And, you know, even E-plane is fine, because I'm really the only one who has to deal with the tech aspect of it. Until very recently, Dave dealt a lot with the tech, too. But Dave's spending most of his time these days writing Ruby on Rails. And I'd rather him do that than me have to do that. And I'd rather do the tech. Do we do some new format that's not any of these that then incorporates this? Now, the carrot to place in front of this group that's in front of me there with these different formats and different engines, we can provide some funding to do some of this. It would be in dollars, which I realize is funny money these days. But if need be, we can come up with euros or Ruble or Grohmar, whatever we want. Monopoly money works well, too. And if we can't get satisfaction out of this, we may have to switch away from tech. We do know that XSLFO, as much as it pains me, does work and does produce reflowable PDF. And since we've already got part of XML in our tool chain, it can be done. It doesn't look as good as tech. But if we can get eBooks out of it, we may have to use tech for our print and on-screen PDF and then use XSLFO to do the reflowable eBook formats. I prefer not to do that. So maybe that might be an additional inducement. Please help us keep tech in this. But that's basically what I want to present to you. Are there any questions? And hopefully, are there solutions? We've got another solution. It's not about solutions. I have to talk to you about this afterwards. I have some ideas, but here are the questions. The question is about tools. First, what do you offer to use to produce XML? Do they just type in editor like Emacs or with a text? We don't actually... We've got a few things that we offer for Emacs users and for textmate users. We've got some macros in there to help them out. But we generally let the author use whatever they want to type in the XML. What do you use? I go back and forth between Emacs and textmate when I'm authoring, depending on what I'm doing. And second question, what do you do to convert from XML to all these forms according to your... XSLT. Yeah. I think it's the Xerxes. What? Xerxes? I think that's what we're using. I rarely get into it. I just sort of... I do my XSL format and then just run it through. But I think we're using Xerxes. There. Hans. I'm just going to start with two remarks. First is if you want the reflow, why don't you just use HTML for these people? Or alternatively, just generate a different PDF in the right...... and a different form of that? Why do you want the reflow? Well, because some of the ebook formats require... Some do take HTML as input and those were fine on. Yeah. But you can use PDF and some don't... There's no aspect ratio. It depends on what the user sets. So that has to be reflow. If you look at like this...... we have one of those ebook things. If you just generate it in a nice format, fitting the screen...... that doesn't solve the problem if somebody is using a mobile phone and then wants to change the website. You need to reflow so you don't have to scroll. But I'm over from, I think, any reflow. Yeah, I mean, it's kind of like... How about you're going to say that you have... Okay, use the pages for the pragmatic problem. Just look to other... Simple. But if you have a group which has a little bit of more...... click on the page. Maybe you can use Mike's headings and Mike's titles and whatever. How do you reflow them? If you have the design book... Right, I mean, but that's the general ebook problem...... that I can't really solve as a book designer. But I can't throw this strictly to the support department...... because they're going to get tons of emails every day saying, hey, I spent $30 on this ebook and it looks like crap on my reader. I think that getting it looks like crap. But the question is, how do you...... less crap is it... You just made the other half a piece of the solution. That's the problem you solved. That means why the private conversation, please. John. I don't know what engine is used to reflow in PGA. But I'm sure it's not tech. And it would be wonderful if it were tech or something related to tech. And if that was the case, then the whole problem would almost certainly be a lot easier...... because there'd be a close relationship between what we're doing here and what we're doing there. And whilst this doesn't help you because the answer I'm giving you is, if I wanted to do that, I wouldn't start from here, we have had enormous misopportunity over the past 20 years in that we have not packaged tech...... or an extension of tech in such a way that it can be used, for example, as a reflow engine for PGA. So this problem is actually of our own making, because we have not addressed the issue of packaging the engine tech for an extension of tech...... so that it can be used for this sort of purpose. We've missed that opportunity. There's an old saying that every problem, there's an opportunity in it, but here's the problem, and I think there's the opportunity in it, which is one that we've missed. Now I do have a question, which is there's clearly a lot of interest in what you're doing...... and you're bringing in fresh and interesting problems coming from real opportunities out there. So, would you like to organize a session where people have a strong interest and this can get together? Sure. How do we do that? We'll work on that in a bit. Alright. You said that you were producing your PDS in the ODS, and that PDS was called that. Do you consider it a PDS, though? Yes. The reason why, as of right now, we're still doing it this way is because the original pragmatic programmer...... and the original programming Ruby rely heavily on PDS tricks for certain things that are on the page. And every time I suggest that we get away from that, there's strong interest in it, and then the very next book...... somebody says, oh, I want to do that. And I really haven't had the time yet to reimplement all the stuff that we're currently using with PDS tricks...... into something that I can use with PDF tech. But yes, I would like to get away from that. It strikes me that the brain replays, re-tubles PDS and something with PDF tech, but the writing breaks down. Right. Yeah, I agree. How does the thumb have an experimental footage that can be implemented? Yes, we have some that can do it. Can you please answer this? Yes. I think you say that you have this other solution that can use your verbal PDF. Yes. But then you said that I want to stay with tech. My question is, is that a purely religious statement, or are there practical reasons? There's aesthetic reasons. XSLFO produces wonderful reflowable PDF. It just doesn't look as good as tech. Yeah. And I, coming from... That's such a property of reflowable stuff that you produce. I don't know. No, because I can take XSLFO and produce a non-reflowable PDF that looks similar, but not quite as good as the tech output. Which is so much the same as I'm suggesting that to have it reflowable, you're not going to get the photographic quality. Probably. So that's something to do with what... I mean, renewable reflowable PDF is a clutch, I mean, it's still in the city, but you can have it done. Right. It's not worth knowing how it's done. Yeah. And part of it too is pure laziness on my part in that you saw the number of XSLTFiles I had to have already. And I would much rather be able to just maintain the PPV to LATAC file and get everything in there. And actually, unfortunately, that's what I spend most of my life doing. That's a practical reason. You know, and now if I have to maintain an HTML, because the Kindle stuff comes off of HTML. But has anybody used Kindle here? It's utterly unusable for programming books. Kindle provides you with two fonts, a sans-serif and a serif. There's no fix with font. So you can't do code listings. And it converts everything to black and white. So any screenshots you show get pixelated beyond belief. I can show you some horrible shots of we tried to produce one book through just to see what it would look like. And it practically turned my stomach. But one of our other non-technical members of the team said, eh, you guys are too picky. It looks fine to me. So that may be the case that I'm too much of an esthete to be able to do that. I don't know if this makes sense. If you could get XSLFO, so to speak, off the back end of 10, would that solve your problem? Sure. I don't know how you would do that though. Now the second question is, could you do any better than that in terms of quality of the output? Is it possible to do? In other words, does the optimum route pass through XSLFO in terms of quality of the output? I don't know. I don't know. I would have to try and see what came out. That's a pragmatic answer. Yes, yes. That's a very hidden house called for the Germans in the audience. I'm going to read in the very different books. But we have to change the pages. Do people really play one of those? Yes, yes. The reason why I wrote that last year's tech conference was that I was in Moscow for several months. I brought a bunch of books with me on my computer to read. I spent a lot of time reading on my computer. I guess maybe I'm just too old, but I agree with you. I don't find it an enjoyable experience. I much prefer having... I'll have you use the info format to press space and just change the page. Apart from that, it's when you're all the time scrolling up and down the screen, you're going to be able to sit the opposition. Yes, well, with my eyes, I was having to have it blown up extremely big. I don't enjoy it, but the young folks seem to enjoy doing it. I do know plenty of people who have read tons of books on their cell phone. I can't do it. I mean, I read when I had my old... What was it? It was a poem, I guess, at the time. I read Zane Gray on it, and that's the only thing I've ever been able to do was know something light like that I could handle, but anything more technical, it just gets to be a nightmare. And especially if you've got a programming book or something like a Photoshop book, where you've got to have screenshots in there. Once you get these little screens, it's impossible. I am a phogy, I guess, is what it comes down to. All right.
Pragmatic Bookshelf, they took that with them and what are some of the issues that we have using remember before I present the issues, because what do you offer to use to produce XML? Do they that you have this other solution that can use