On Wed, Jun 14, 2017 at 03:45:43PM -0700, Paul Rogers wrote: > > > I didn't *think* so either, but OTOH AIUI GTK has a compiled-in > > > default theme. Can "runtime" be added to the book, just in the > > > interests of clarity for newbies, and some of the rest of us? > > > > Patches accepted. > > I've seen your HTML source, it's rather more involved than the HTML-3 I > learned to hand-code many years ago. I just used pico to make my > website. Apparently you have a much more complex infrastructure. I'm > not at all sure I CAN make an insertion without messing something up. I > suppose you have some sort of WYSIWYG editor, DocBooks (which I've never > installed nor used) or some such? I dunno. >
The html is only the source for the website (e.g. errata), and I very much doubt you have looked at that. The source for the books in in xml. Yes, it is involved - but most of the time we can copy structure from another page, e.g. when adding a patch to the source to make a package compile. For the books, vim followed by 'make' (and 'make REV=systemd' if the page has conditional parts). Plus, of course, a copy of the file tree *before* the change so that you can create a diff. A full stack of the bockbook tools (xml, xslt) is needed. Perhaps only chapter 51 and its dependencies is required, I'm not sure - I've always built all of chapter 50 as well as chapter 51. It also needs a graphical browser (links -g is NOT good enough for testing an edit) to check that things look ok. And yes, sometimes getting the book to render is hard. New pages are typically the worst part (all the indexing, and remembering to check it), but perl-modules is a close second (I tend to have to make a lot of additions there when the deps pulled in by biber change, and the easiest method I have found is: add a new dep in the right place, render and check the link and the text, rinse, repeat, save a copy of the file, add its dependencies, sometimes only one at a time, sometimes several, and save copies along the way. The general rule is: if possible, only change a little at a time, and use 'svn diff' to confirm what you actually changed, particularly if it doesn't render and you're not sure why - the diff can often show unbalanced tags from mistyping. When running 'make' for the books, try to hit Ctrl-C as soon as the validation fails, so that you can get back to the first error message (just like compilation - after one error, any subsequent reported errors might be irrelevant). More generally, finding language / phraseology I'm confident about, and fixing explanations which suddenly look outdated or misleading, also make *me* do a bit of reworking when I've got it to render. But I'm sure some people know exactly what they want to say and can get it right first time. It isn't difficult (most of the time), but it can be tedious. As we've said before: if somebody wants to produce a patch, don't bother with the changelog.xml - whoever applies it can fix that up. ĸen -- I live in a city. I know sparrows from starlings. After that everything is a duck as far as I'm concerned. -- Monstrous Regiment -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
