[sdiy] A book about analogue synthesizer circuits?

[Stephan Vladimir Bugaj]

By now [PNG] exists on most if not all platforms and in many tools.
-----------------------------
PNG is an excellent raster format.
However, for things like schematics, it would be excellent to try to
find a way to use SVG.  Since SVG is a vector format, it easily allows
for scaling without pixelization, etc.  However, you wouldn't want to
do a whole book in SVG :-)


> Agreed.  Sourceforge is a web-based open-source system.  See:
> 	http://sourceforge.net
Personally I know sourceforge, I just wanted to point out that I am dead
tired
by feature-happy (compare trigger-happy) people. Look at my webpages, they
are
booring like hell (and I do want to spiff them up some) but they work, work
and work, well except for some broken links... I don't depend in tuned
servers
etc.
----------------------------------
Source control and document control are not necessarily the same, but one
thing
to keep in mind is that successful books have something in common with
successful
code: an editor (ok, so in source code that person is usually called the
build-
master).  "Books" without editors are usually very easy to identify and
terrible
to read.  In the actual printed book world, this almost never happens,
because
the $$ involved in producing a book demands that there be an editor.
However,
with small and vanity press houses, such books do slip by, and they usually
suck (even if the information is actually correct).

Technical books, actually, often have more editors than regular books.  Most
professional books have a lead editor (who may not necessarily be a domain
expert), and at least one copy-editor (which is a job that sucks massively
and is really hard to get anyone to do for free).  Tech books often have
a lead technical editor, and a technical review committee.  This group
already
comprises the committee, but what about the rest?

It depends on how professional of a book it should be.  Lead editing is
almost
essential in group writing efforts (unless it will be simply a collection of
papers without any logical thread running through the chapters, like the
ones Springer so frequently publishes based on conferences).  Copy editing
is
very useful, especially with authors who don't all speak English natively
(and
that is assuming the book would be in English).   A group without editors
can
put together a useful collection of technical papers which will be
successful
in teaching the material to some readers, but even so there needs to be some
coordination (often the expert in each topic coordinates its entries) if not
actual editorial control.

> > > The other contender, PDF, is perhaps more viable (a modern version of
> > > Postscript, to keep Magnus happy :-)
> >
> > Not quite, but I agree it is a good format most of the times. However,
> > in order to work with a large range of PDF browsers restrictions on
> > which features to use must be setup.
>
> Agreed.  Just plain text and figures (diagrams, schematics, pictures).
That's not what I meant.
-----------------------------------
PDF or PostScript are ok if the plan is to make an actual printed book.
If that is the plan, actually contacting a few publishers to measure
interest
and find out about submission formats (and hope for some commonalities) is
a good idea.

However, if the plan were to make an online book, HTML + images and
schematics
in PNG and/or SVG would possibly be even better.  I say this because of the
nicer treatment of hyperlinking and also because nice stuff can be done with
searching and database-driven stuff.  An example would be: an updatable,
database-driven set of tables of component data which could be maintained by
the group.  You can even put in PDF and LaTeX inserts, or use newer browser
features like CSS, MML, etc. to do (hopefully useful and not eye candy)
stuff
with layout, formula insertion, etc.   At work we are moving away from troff
man pages, and PS and PDF whitepapers, to XML and HTML based documentation
workflows (and looking at serving LaTeX papers which are in LaTeX due to
conference and journal submission requirements into HTML using converters).

One thing to consider is DocBook http://www.docbook.org/
DocBook is an XML DTD for technical books, and there are conversion tools
to and from various other formats.  It's intended to be less annoying to
deliver a DocBook to HTML or PDF or whatever than to do the same from,
say, LaTeX.  This has a lot to do with it being XML and the ability to then
use various XML tools (and XSLT for layout, etc.) to deploy the info to
the target format and manipulate the layout.

Actually, the best thing where if people where using the same tools, for
ease
of maintenance.
-----------------
True

My $0.02

- S