Clint,

I'm not sure what scales for large numbers of collaborators.  I've collaborated 
with both Word and OO.  I've not used Latex before although I've used older 
script and scribe.  


It occurs to me that a wiki might work if there were a way of creating the book 
from it.  


I'm guessing there will always be a bit of reformatting to a new version of a 
book.  The question is how much.



David




>________________________________
>From: Clinton Jeffery <[email protected]>
>To: David Gamey <[email protected]>
>Cc: UniconGroup <[email protected]>
>Sent: Saturday, October 29, 2011 7:52:20 PM
>Subject: Re: [Unicon-group] fork under windows?
>
>
>So, we need a much more open documentation process in which it is far easier 
>for folks to contribute, and where we still have a high quality of editorial 
>review and a "reasonably" consistent prose style.  I pretty much have done a 
>poor job of maintaining the Unicon book via OpenOffice; OpenOffice was more 
>open and accessible (and multi-platform) than when we did the book originally 
>in MS Word (originally it was in Word because of the prospective publisher's 
>requirements), but it is not open enough in terms of change/revision 
>management, not portable enough, and its fonts and formatting are rather too 
>fragile.  For a 500 page book with complex figure arrangements, any time you 
>switch to a new OS or a new version of OpenOffice, the formatting is at risk 
>of getting messed up.
>
>The "fix" that comes most readily to mind would be to switch to a text-based 
>format that could be handled as part of the Unicon SVN codebase, such as 
>LaTeX. I have ported the Unicon book to LaTeX before, and it worked, but would 
>require a fair amount of effort to get the formatting nice and presentable 
>again. Do you have any alternative suggestions, and for that matter, does this 
>suggestion make good sense?
>
>As to whether fork() should fail or have a runtime error where it is not 
>implemented, I agree with you that I made a mistake in this case, the 
>comparables are the graphics functions, which are defined on all builds, but 
>if you ever call them on a platform built without graphics, they die with 
>runtime error 121 "function not supported".  We should probably do a sweep 
>through the posix functions and find all the ones that just fail on Windows, 
>and change them to use the MissingFunc() family of macros that we use for 
>graphics functions.
>
>Clint
>
>
>On Sat, Oct 29, 2011 at 4:26 PM, David Gamey <[email protected]> wrote:
>
>
>>
>>Documentation is something I can do :)
>
>------------------------------------------------------------------------------
>Get your Android app more play: Bring it to the BlackBerry PlayBook 
>in minutes. BlackBerry App World™ now supports Android™ Apps 
>for the BlackBerry&reg; PlayBook™. Discover just how easy and simple 
>it is! http://p.sf.net/sfu/android-dev2dev
>
>_______________________________________________
>Unicon-group mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/unicon-group
>
>
>
------------------------------------------------------------------------------
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World&#153; now supports Android&#153; Apps 
for the BlackBerry&reg; PlayBook&#153;. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
_______________________________________________
Unicon-group mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/unicon-group

Reply via email to