Future of LFS
jhuntwork at linuxfromscratch.org
Sun May 18 13:49:41 PDT 2008
Gerard Beekmans wrote:
> For us to be able to use an online tool to write the book, that tool
> needs to support every kind of tag we'd use for book editing; including
> tags like <sectx>, <itemizedlist>/<listitem>, all the structures
> surrounding chapter setup, entities, section info tags, the sometimes
> tricky internal XML links, and the list goes on for a while.
I understand. However, many of our current tags, and our current
structure, can be simplified or improved, I believe. But yes, what you
see in the POC is only a handful of what would need to be supported.
> I'm afraid that in the end an online tool gives a user buttons/links to
> click on that insert the proper start and end tags. After doing it a few
> times, you may as well type them out. If one is a reasonable fast typer,
> it is faster to type out the start and close tags as you type the rest
> of your sentence of paragraph (compared to grabbing the mouse, find the
> button, click on it, then click somewhere in the text edit field to
> start typing between the just inserted tags).
Not necessarily, but that comes down to user preference. Of course, with
a new format, an editor should still be able to edit manually with vim,
if he desires. One advantage to having a gui with buttons and controls
that generate tags is that it helps to reduce tag typos and validation
errors. (As an aside, I don't know if you tried it, but I believe my POC
will show you if there is an error validating the document when you hit
> This may be a bit exaggerated (though often it's simply the truth) but
> the point is, I've never been convinced a WYSIWYG (what you see is what
> you get) editor is the right tool for us.
It may not be the right tool for _you_. :) But it may very well be the
right tool for someone else, and make it easier for new contributors to
add changes to the book.
> On the other hand, it would be nice to be able to see the formatted page
> as you're typing without having to render it every time a change is made
> and then having to open it in another program (ie: web browser).
Yes, that was another advantage.
> Rather than re-invent the wheel, would a program like BlueFish be a
> possible candidate? I haven't used this program in over half a decade
> but I hear it supports XML. It may be a possible alternative to at least
> look into before deciding on a custom "in-house" application.
Sure, you could look. Often, though, I feel it is just as much work to
get full-featured applications such as BlueFish to work with a custom
setup as it is to write our own simple app.
Even so, the code-editing aspect was just one portion of the POC. Part
of the main focus of the POC is still to allow custom, dynamic
renderings of the book.
> Also keep the following in mind: we don't need to necessarily change the
> XML structure to make it easier for other people to contribute.
I respectfully disagree. Our current XML syntax isn't the easiest to
work with and it doesn't do all we would like to do (such as define PM
type). I'm glad you mentioned 'itemizedlist' and 'listitem'. Those are
two of my least favorite tags, partly because they are so long and
unwieldly. Another is the whole <screen><userinput> combination.
> In fact, anybody can contribute textual changes. That doesn't mean we
> need or even want people to submit XML code. Editors should review all
> submissions and edit for content, correctness, style, grammer, etc. The
> last thing we want is to copy and paste contributed XML into the book.
I agree with the desire to keep the book 'pristine', correct and
reliable. On the other hand, I think being too restrictive keeps us with
a low active editor count and a high workload. I think we need to find a
way to open up more opportunities for contribution while keeping the
quality of the book intact.
> Before long, the book will develop an inconsistent format because
> everybody has a different style of writing, or English isn't their first
> language. In the end we want a book that has a professional feel to itt
> with one style of writing that is consistent throughout.
Wikipedia. There is an example of an online resource that in theory
shouldn't work, but in practice actually accomplishes something worthy
of note. How do they manage to allow Everyday Joe to edit their book and
yet keep a fairly reliable and quality resource? Because they have
guidelines and a community that helps keep those guidelines in place.
I'm not saying that we should do exactly as Wikipedia does, but I don't
opening up the book will produce as much of a nightmare as you think.
Let's say we have the task of adding a new section to the book. If one
person who doesn't have the right writing style or expertise in English
draws it up and is able to convey the right ideas, they've done 80-90%
of the work. Others, perhaps with less time on their hands, can now
tweak up the text or fix minor technical issues. The point is that the
book has now moved forward, instead of stalling while waiting for
someone 'approved' to have the time to write it up or make changes.
> That is near impossible to accomplish unless only a handful of people
> actually update the text - those people will have worked together for a
> while and know the right styles to use while writing. And they can be
> the XML experts and translate a contribution into the proper XML format
> used by us.
This is exactly what we have been doing up to now. And it doesn't
address the issue that I raised, namely, we need to get more people
interested and willing to contribute.
More information about the lfs-dev