Why do i feel that this has been discussed multiple times before and the end result was to stick with the status quo... but anyway see below.
Below I'm playing devils advocate a little bit. On 20 February 2012 20:17, Jörg Emmerich <j-emmer...@online.de> wrote: > Congratulation to all of you having worked hard on getting the 2.6 out. > > So pls let me come back to my proposal for a different style of the > "FGFS-Manual". > > For several month now I made many tests with LaTeX, LyX, basic PDF, etc. > - but was not able to achieve with those what I am proposing: > > -- splitting up the ever growing pdf-file "getstart" into smaller > "books", totaling a growing contents with increasing "referencing" > between specialized chapters. Thus achieving a BASE from which users can > develop their skills. Perhaps the probably with the Getting Started manual is more of a naming issue as it's more of a warts and all manual. > > -- make use of the modern art of on-line reading/studying! > e.g.: Jumping between the "books" to any given place inside and outside > the book! Thus achieving the oposit of todays "Indexing". Not searching > in the Index to find something in the book (that you can do much more > efficient with the standard on-line "Find"-utilities) - but jumping from > any place inside the books to other places for advanced and/or common > explanations/informations. Thus avoiding the need of describing many > things many times (and forget to change many places when a change is > needed!). > Why shouldn't we, as the promoters of the most modern style of > designing, not also make use of the most modern style of > reading/studying/updating manuals, dictionaries, newspapers, etc.? > Manuals, dictionaries and newspapers are generally read in hard copy with the markup being very obscure such as InDesign markup. > -- stimulate translations! > Consider that this Manual will not be used just for highly educated > professionals that mostly do speak English - but for common users of all > Nationalities, all stages in education, etc. We definitely do need to > attract those to participate. As we accept that any professional can > participate in the design, we should also trust our users to generate > and maintain their manuals by themselves! FGFS, FGFS-wiki, Wikipedia, > Linux, etc. etc. -- they all proved that it works! If we were to use a Mediawiki such as the FlightGear wiki as the authoritative raw source for the PDF versions of the manual, we will need to ensure the following extensions are installed and enabled :- http://www.mediawiki.org/wiki/Extension:PDF_Writer and http://www.mediawiki.org/wiki/Extension:Collection I'm not sure how it would handle page number references between subsections and other books. And you still need to ensure that all books are generated when content has changed. > > -- Use common tools. > Most kids today learn how to generate a Homepage and use "html" - while > "LaTeX" (and similar) needs some more "unique" > skills/environments/procedures. It is streamlined for the use in > "publishing houses/departments" - with the need for a so called > "corporate identity". But that identity is also achievable today via > HTML (CSS) -- see e.g. the articles inside todays FGFS-wiki! > The fgfs wiki is not html... but wiki markup rendered as html. Unanswered questions; 1. what about the issue of pulling the individual pages together to form a book? 2. How do you add a reference to another page and have it relevant when printed? > -- Avoid the dependency on uniquely skilled persons: > What happens when the private priorities of those "few" (and thus often > overloaded volunteers) will change? In addition: A detailed proofreading > of todays "getstart" takes weeks - while thousands of users will find > errors and improvements without any scheduled task - just by using it! > But then an "administrative procedure for corrective actions" might not > really convince them to become active! Changing toolsets will not remove the need to proof read the result for errors such as wiki vandalism and broken references. > > Please let me know if you have an issue with that - otherwise I will > start to setup FGFS-wiki versions. Then we may have two versions - which > I believe could develop into different flavors: One more "users-taste" > and one more "engineering-needs". I see my personal preferences more on > the user/customer aspects - and hope the "engineering" environment > forgives me for that! > > If you are interested to know more about the WIKI pros/cons, I suggest: > http://wikieducator.org/Wikieducator_tutorial/What_is_a_wiki/Advantages_and_disadvantages > See also my current HTML-version on http://www.emmerich-j.de/S6.html > (having now about 1000 hits per month after 2 month on-line). Sure. Though a long html page can become ugly when printed to hard copy due to inappropriate pagination, image sizes, word wrapping, etc. At the moment, I don't have the time to investigate tools mentioned above, but being able to order an up to date book (dead tree version) from an on-demand printer would be something that I'd be interested in. I like to get away from the computer to read multi-pages of detailed documents. Regards George ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
