Re: [Flightgear-devel] Links for new FlightGear pilots
LaTeX is not a word processor, it is a professional typesetting tool. I see all the reasons to keep the docs in LaTex (like keeping the process efficient at the moment), but this sentence here about professional tools is probably not that serious as I read it, right ? I don't know how you read it, but I know for a fact that many professional science publishers use it (Elsevier is just one example, pretty much every physics journal asks you to prepare manuscripts in LaTeX). So yes, I guess I am serious - pretty much anyone I know who is publishing on professional level (i.e. makes money by selling books or journals) and has complicated layout problems (math formulae, Hebrew sentences with reverse writing direction inside English texts, Egyptian hieroglyphs written from top-down or right-left,...) uses LaTeX for typesetting. It's not some exotic tool in publishing business - it's just not so well known for every-day office work. * Thorsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
Am 14.09.11 08:58, schrieb thorsten.i.r...@jyu.fi: LaTeX is not a word processor, it is a professional typesetting tool. I see all the reasons to keep the docs in LaTex (like keeping the process efficient at the moment), but this sentence here about professional tools is probably not that serious as I read it, right ? I don't know how you read it, but I know for a fact that many professional science publishers use it (Elsevier is just one example, pretty much every physics journal asks you to prepare manuscripts in LaTeX). So yes, I guess I am serious - pretty much anyone I know who is publishing on professional level (i.e. makes money by selling books or journals) and has complicated layout problems (math formulae, Hebrew sentences with reverse writing direction inside English texts, Egyptian hieroglyphs written from top-down or right-left,...) uses LaTeX for typesetting. It's not some exotic tool in publishing business - it's just not so well known for every-day office work. * Thorsten Hi Thorsten I apologize, I just hit return to much in my mailer the last days, please ignore. Cheers, Yves -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
On Tue, 2011-09-13 at 11:46 +0300, thorsten.i.r...@jyu.fi wrote: LaTeX is not a word processor, it is a professional typesetting tool. I don't know about fiction books, but the vast majority of science books you can buy is done with LaTeX. If you know how to work with it (rather than against it), the layout you can get is orders of magnitude better than anything else. I fully agree with what you are saying. I even would add as reference: http://en.wikipedia.org/wiki/LaTeX http://www.latex-project.org/intro.html They all fully support what you are saying. bUT did you notice that nobody is mentioning support for Web-pages, Softcopies, wikis, references, distributed-engineering, etc.? I am sorry that some people seem to believe I am against LaTex and/or a controlled release processes - I am not! I just ran into the fact, that the present manual is not as much in use as I believe it earned to be and/or it should be. So I try to find a way how to improve that! Doing so I guess we need to evaluate the aspects of all the actors in that process: 1) Writer, Poet, Engineering, Marketing, etc. Most of those surely do not want to be bothered with the final looks of their design - but surely some do (and then run into problems). 2) Publisher and Corporate identity They definitely will support to use LaTex 3) Maintainer One of the questions I raised but did not yet get an answer for: How can all the many developers input there updates into the existing document? And how often? (We have the GIT for the design - but descriptions for the users in real time updates?) Do we have a publishing department in FlightGear? (I know there is an excellent work done right now - but how is the future? And how can we reduce the workload and turn-around times for that?) 4) Users and/or customers Those surely will require very different styles of documentation: - A university-Prof studding the possibilities of FlightGear - The FAA, that should be convinced to issue some approvals - other engineers that cooperate within FlightGear - real pilots that want to train - grown ups - or kids that want to play (and which we maybe able to convince to start simulating in FlightGear instead of playing killing-games) And guess where my priorities are! Still I am looking for a compromise for most of those actors! Very simply said: Look at the opening question of this thread, and tell me what you would answerer! (Maybe even considering that question came from your own kid or friend or whatever!). Would you point to the existing manual for an answer? Did you, yourself read the complete manual at least once? I did not see any answers to these issues in this thread -- and that is my big concern! -- I do not care if one of the tools used will be LaTex or something else! And let me assure you: I fully understand that FlightGear is much more then a game and thus it is no Kids-Stuff - but I would like to use it to convince people to use it and grow with it. For the time being I am interested to see how my proposed Manual gets out of this process, how long that takes, and how it gets accepted by the customers (and the community). In todays environment! joe -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
On Wed, Sep 14, 2011 at 10:31 AM, Jörg Emmerich wrote: 1) Writer, Poet, Engineering, Marketing, etc. Most of those surely do not want to be bothered with the final looks of their design - but surely some do (and then run into problems). (I think the Marketing person here is part of the second group, as they would want to be consistent with the Corporate Identity, or brand). I would argue that Writer, Poet, Engineer _shouldn't_ be bothered by the final look of their design. Surely much better to have that look and design handled by someone else, allowing them to concentrate on the content. 2) Publisher and Corporate identity They definitely will support to use LaTex 3) Maintainer One of the questions I raised but did not yet get an answer for: How can all the many developers input there updates into the existing document? Martin and I have always accepted text updates to The Manual, either in the form of pure textual corrections, or patches to the Latex source. And how often? Not very, admittedly. Outside of the updates that Martin and I make, I think we get a couple every year. (We have the GIT for the design - but descriptions for the users in real time updates?) I'm not quite sure of the question here. Certainly any changes will take a long time (the next release) before they are published in a release. Do we have a publishing department in FlightGear? (I know there is an excellent work done right now - but how is the future? And how can we reduce the workload and turn-around times for that?) For The Manual, it's Martin and myself. For the wiki, mainly Gijs I think. 4) Users and/or customers Those surely will require very different styles of documentation: - A university-Prof studding the possibilities of FlightGear - The FAA, that should be convinced to issue some approvals - other engineers that cooperate within FlightGear - real pilots that want to train - grown ups - or kids that want to play (and which we maybe able to convince to start simulating in FlightGear instead of playing killing-games) Agreed - they are different target audiences. As it currently stands, The Manual is targeted at the following people from your list: - A university-Prof studding the possibilities of FlightGear - real pilots that want to train - grown ups - or kids that want to play (and which we maybe able to convince to start simulating in FlightGear instead of playing killing-games) The other two (FAA, FG engineers) require a completely different, much more detailed set of documentation. Frankly I don't think we should be looking to address that while we struggle to address the above users. Very simply said: Look at the opening question of this thread, and tell me what you would answerer! (Maybe even considering that question came from your own kid or friend or whatever!). Would you point to the existing manual for an answer? Did you, yourself read the complete manual at least once? Yes - I regularly point users on the Forum to The Manual to answer their questions. Yes - I've read it completely multiple times (but I don't count ;) ) I did not see any answers to these issues in this thread -- and that is my big concern! -- I do not care if one of the tools used will be LaTex or something else! And let me assure you: I fully understand that FlightGear is much more then a game and thus it is no Kids-Stuff - but I would like to use it to convince people to use it and grow with it. For the time being I am interested to see how my proposed Manual gets out of this process, how long that takes, and how it gets accepted by the customers (and the community). In todays environment! joe -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
Thanks for the info - that confirms what I noticed: After Installing and doing some tests with LaTex and LyX I did not find a feasible way to import the newly designed appearance - seems you really have to just extract everything except the plain text and and build it up new - without the support of a WYSIWYG-system! And if you wanted to change the appearance of the manual you first would have to build up new predefined structures (comparable to the CSS-Structures in HTML). That sounds like a whole lot of work - and I wonder how I or anybody else can help with that! Is there a description of that process? As a long time LaTeX user, let me comment on a few points. LaTeX is not a word processor, it is a professional typesetting tool. I don't know about fiction books, but the vast majority of science books you can buy is done with LaTeX. If you know how to work with it (rather than against it), the layout you can get is orders of magnitude better than anything else. If you want to work with LaTeX, you have to think in a new way about things. You're talking about support of a WYSIWYG-system - but in reality, there is no such thing - it doesn't really support you with anything. As an author of a text, I should not micromanage the layout - my task is to define what is in what section, what is figure caption, what is footnote, and so on. Based on that, the publisher does the layout. You may design the manual in 12pt fonts and an a4 page format so that people can print it. I may rather want to change it into two column, 10 pt fonts and a B4 format to make a hardcover book out of it. To do so with a properly designed LaTeX file costs me 5 lines in the header, and just maybe less than 10 minutes optimizing figure placement manually. To do so in a WYSIWYG word processor is a nightmare, to say the least. You have to rethink your task as author - it's just to identify the function of all text elements and to trust LaTeX to do the rest (it's *really* good doing that). There are numerous manuals around in the web - www.ctan.org is as good a starting point as any. In case there is a specific question not covered in the manual, you can also ask me - there's hardly anything about LaTeX which I don't know (or can't find out within 10 minutes). Cheers, * Thorsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
Am 13.09.11 10:46, schrieb thorsten.i.r...@jyu.fi: LaTeX is not a word processor, it is a professional typesetting tool. I see all the reasons to keep the docs in LaTex (like keeping the process efficient at the moment), but this sentence here about professional tools is probably not that serious as I read it, right ? Cheers, Yves -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
Hi Joerg, Stuart, others, I'll just add a few ideas, as most of the relevant stuff has already been said. Jörg Emmerich wrote: joacher@gm.. now proposed the link to www.lyx.org and I had a short look: - seems you can even import HTML into that system Personally I doubt that importing HTML is worth the effort, and I'll try to let you know, why :-) Upon importing whichever structured format, LyX (or whichever processor) will try to make a sense out of the current formatting and in most cases you'll have to fine-read the output anyway in order to make it fit the style of the current getstart manual. Thus, instead of spending effort on removing obsolete formatting from the import, it would be easier just to dump the HTML as plain text and add LaTeX formatting only where appropriate. BTW, in order to import HTML, LyX relies on having htmltolatex installed, which probably isn't the case on every system/distro which has LaX available. So I could imagine to structure like: 1) Start as is Much of the structure of The Manual was designed when pre-built packages were a rare species and you had to accustom with different graphics card drivers. Stuart did a great job cleaning up in order to keep up with recent changes, but I have to admit there's always a lot to improve Did I shock you now ??? No :-) I am not a Profi on that: But is that still a problem with todays PC's, that are running FlightGear? I thought the standard allowable transmission size today is about 20 MB. I still think we should not stress people's sympathy by growing the PDF too large. If the current setup grows too large, there'll be the option to split the PDF into different files and just have people start with the intro and the summary. Internal HTML symlinks will do the take care about referncing the remaining parts. [... GPL ...] My concerns result out of the many discussions in the forums about our competitors that earn money with what we are doing. Everything in FlightGear, the software and the data directory you use is distributed under an OpenSource license ((L)GPL). This is the foundation of the entire project and therefore I think it's just a logical consequence to distributing The Manual under the same license. Just let me beg for one last wish: Please spend that now getstart at least a little cosmetic treatment! Somehow I do not believe that the pictures shown in it represent todays FlightGears possibilities, Agreed ! In fact, it's up to everyone here to create and submit better images, screenshots. Basically this is a the communit gets what they deserve-situation ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
Agreed ! In fact, it's up to everyone here to create and submit better images, screenshots. Basically this is a the communit gets what they deserve-situation ;-) Quick note: I'd be happy to provide some high quality screenshots if desired. Just let me know what kind of images are required. I have a huge surplus of images left over from generating material for the official gallery, and would be happy to go out for a few more. Cheers durk -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
Durk Talsma wrote: [...] I have a huge surplus of images left over from generating material for the official gallery, [...] I know - yet I'd dare to note that illustrating a manual is slightly different from just dropping a few nice images here and there ;-) Thus, if someone has an eye for placing the right images into The Manual, please shout and advise which image should go into which place. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
Hi Martin as you probably have seen, I am eager to help in supporting the update of the Manual. Please see some questions to your remarks: On Mon, 2011-09-12 at 10:33 +, Martin Spott wrote: Personally I doubt that importing HTML is worth the effort, and I'll try to let you know, why :-) Upon importing whichever structured format, LyX (or whichever processor) will try to make a sense out of the current formatting and in most cases you'll have to fine-read the output anyway in order to make it fit the style of the current getstart manual. Thus, instead of spending effort on removing obsolete formatting from the import, it would be easier just to dump the HTML as plain text and add LaTeX formatting only where appropriate. Thanks for the info - that confirms what I noticed: After Installing and doing some tests with LaTex and LyX I did not find a feasible way to import the newly designed appearance - seems you really have to just extract everything except the plain text and and build it up new - without the support of a WYSIWYG-system! And if you wanted to change the appearance of the manual you first would have to build up new predefined structures (comparable to the CSS-Structures in HTML). That sounds like a whole lot of work - and I wonder how I or anybody else can help with that! Is there a description of that process? Could several people cooperate in changing the contents as well as the looks of it? I am eager to learn how that can be done, in what time, and how to maintain it in the future! I still think we should not stress people's sympathy by growing the PDF too large. If the current setup grows too large, there'll be the option to split the PDF into different files and just have people start with the intro and the summary. Internal HTML symlinks will do the take care about referncing the remaining parts. I agree, that very big PDF-files are not the best solution, based on download and response-times. That is one of the reasons, why even the proposed HTML has 10 parts - which are all linked together and which all have References between them all, so that it looks like 1 piece. I hope that LaTex can do something similar - and then even add a Word-Index to the end, that covers all parts in one index! In todays computer-technology I really would hate to tell anybody: We want to tell you everything about the system, but we cannot because we are limited by the file-size! I see the future user/reader of that manuals as customers whom we want to sell something (Or better: Beg them to to read it!). Agreed ! In fact, it's up to everyone here to create and submit better images, screenshots. Basically this is a the communit gets what they deserve-situation ;-) Is there any description of how that process works? Can anybody change/update or whatever into the source (e.g. comparable to the WIKI-process, but limited to a unique group)? Or is it more sent to ..., and somebody will work it in (from time to time)? regards joe -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
Hi Stuart Thanks - that offer was a nice surprise Surely I want to work together with all of you to get the best, up to date Manual/PDF possible. And surely I am highly interested in integrating what I have into any company-wide release system. joacher@gm.. now proposed the link to www.lyx.org and I had a short look: - seems you can even import HTML into that system - and sftw.-download for UBUNTU is available (ver.2.0.0) So I will have a closer look next week and try what I can do with it. In parallel I am still in the final review of my proposal (wording, spelling, comparing EN/DE, links, etc) - hope to have that done within the next 2 weeks - and surely you can help improving - I will check how to grant excess (either on my UBUNTU-cloud or homepage). Pls see my answers to your points inserted in the following. I am positive we can arrange a common understanding and work-line. I am looking forward to it! joe On Sat, 2011-09-10 at 00:05 +0100, Stuart Buchanan wrote: On Mon, Sep 5, 2011 at 2:45 PM, I wrote: More comments when I get the time once I'm back. Hi Jomo, I finally got the time to look at your work in detail. I think there's a lot of really good work here, and it obviously represents a lot of time and effort. Thanks again. I _really_ like a number of things you've done with the structure. The following comments look at what you've done as a contrast to the existing Manual, and with a view to changing The Manual: 1) The Briefing section (which covers some of the Take-off and In-Flight sections of the existing manual) looks like it is designed to get the first time FGer up and running quickly. I really like it as a concept, and it's something that the existing Manual doesn't provide. I think it goes into a bit too much detail (e.g. covering the keyboard XML format), and could be cut down still further to provide a simple introduction to choosing and aircraft, airport and setting the time/weather for a flight, along with an introduction to the controls. My basic thought was indeed (see Start - For the most impatient (uuups: I just notice: My wording there is not perfect)): If the new guy has installed FlightGear by whatever means - let him start exercising it - and have the referencing system explain him any questions popping up. i.e. start with SOLO Flight as a first introduction. That way I hope to keep his attention - which i am afraid will not last long when I first try to explain all the Basics. I am even thinking about putting the Installation + Briefing into the Appendix and just start with Solo! That other stuff is boring - let him start with using and then explain him what he then, later may want to know! The whole FlightGear principle is like that: Start with one small area and a few aircraft - he will then develop his appetite for more some time - for sure! And then he will look for those infos! I know: That is not how you (should) study something - but most of our customers are young and want to fly - not study! And somehow I understand those people: I always was more the trying then the theory guy! So I could imagine to structure like: 1) Start as is 2) Flight-Manuals (Solo up to Features + Briefing 1st part Starting Up only 3) Technical References (Installation + Briefing-rest) 4) Appendix mostly as is Did I shock you now ??? 2) The First Solo complements the existing tutorials well. Nice work! 3) Moving some of the detailed reference material (e.g. command-line options) to an appendix makes a lot of sense. 4) Your work highlights the importance of providing better navigation between sections. We should certainly be looking at how we can improve navigation within the HTML version of The Manual. It would be great if we could have each chapter in the bar on the top, along with a section drop-down to provide straightforward navigation. Taking a step back, IMO there should be three separate sections to The Manual: a) A Getting Started Guide b) A Reference Guide c) Tutorials In fact I think that was the plan ages ago, but initially only the first was created (hence the filename - getstart.pdf), and over time its scope expanded to cover all three. At present the first two are combined, but your work shows that we really should be separating them more, so that the first Getting Started section covers the basics, and provides references to the detailed documentation in the Reference Guide. I am not sure what those initially thought areas actually should have covered, seeing it from today i would suggest 3 FlighTgear-Manuals 1) Flying: We are working on it. Here I would suggest a Manual! 2) Designing and modeling: I could see it going through some modeling-examples and by that introducing the existing programs, procedures, books and wikis. It should cover the whole design aspects and may even include the Program itself. Not a programming manual - but something showing the major tools in action - and where to start and
[Flightgear-devel] Links for new FlightGear pilots
Well - yes - I am rather disappointed Especially because i looked again, but cannot find any of my suggested improvements in the latest getstart, in regards to structuring, referencing, and looks. In addition I did not really see an answer to Curtis question, that started that all - I get that kind of questions every week during my ATCing - and hoped I had an answer. But as I said at the beginning: Our dev.group had done quite some job designing the getstart quite some time ago - which I thought I could contribute to, especially from a more USERs-viewpoint. But I surely will not set up a competitive environment against that basically good work. Just let me beg for one last wish: Please spend that now getstart at least a little cosmetic treatment! Somehow I do not believe that the pictures shown in it represent todays FlightGears possibilities, especially in regards to scenery! Look e.g. the title-picture - but also several others inside. (Yes - I know: The work that counts is the (hidden) engineering - but what sells it, is the (outside visible) marketing!). I will now complete my announced task to finalize the German translation, based on the getstart. And I will keep the EN/version as is on my homepage - but will not provide a direct link to it for standard users. If anybody anytime wants to use it or parts of it for FlightGear - he is welcome to do so. I hope: No harm done joe -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
Am Sat, 10 Sep 2011 10:18:27 +0200 schrieb Jörg Emmerich j-emmer...@online.de: Well - yes - I am rather disappointed That is not surprising! Technically seen, it is correct that Latex is the most flexible format, from which you can derive most other types, but that doesn't lessen the nice content you provided, imho. I think you overestimate the effort to convert to Latex. Have a look at http://www.lyx.org ! Maybe you can just copypaste your text to this opensource WYSIWYG Editor, eleminate the glitches and save it as latex? Since lyx doens't hide the generated latex code from the user, it is even a good tool to learn latex (and latex, btw, is always a good thing to know!). If nothing helps, don't resignate, but be keen to provide your work as an external documentation. There are aircrafts at individual hangars all around the net, why shouldn't there be a third party manual? But, admitted, one merged uber manual would be a nice thing! Regards, Joe -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
On Mon, Sep 5, 2011 at 2:45 PM, I wrote: More comments when I get the time once I'm back. Hi Jomo, I finally got the time to look at your work in detail. I think there's a lot of really good work here, and it obviously represents a lot of time and effort. Thanks again. I _really_ like a number of things you've done with the structure. The following comments look at what you've done as a contrast to the existing Manual, and with a view to changing The Manual: 1) The Briefing section (which covers some of the Take-off and In-Flight sections of the existing manual) looks like it is designed to get the first time FGer up and running quickly. I really like it as a concept, and it's something that the existing Manual doesn't provide. I think it goes into a bit too much detail (e.g. covering the keyboard XML format), and could be cut down still further to provide a simple introduction to choosing and aircraft, airport and setting the time/weather for a flight, along with an introduction to the controls. 2) The First Solo complements the existing tutorials well. Nice work! 3) Moving some of the detailed reference material (e.g. command-line options) to an appendix makes a lot of sense. 4) Your work highlights the importance of providing better navigation between sections. We should certainly be looking at how we can improve navigation within the HTML version of The Manual. It would be great if we could have each chapter in the bar on the top, along with a section drop-down to provide straightforward navigation. Taking a step back, IMO there should be three separate sections to The Manual: a) A Getting Started Guide b) A Reference Guide c) Tutorials In fact I think that was the plan ages ago, but initially only the first was created (hence the filename - getstart.pdf), and over time its scope expanded to cover all three. At present the first two are combined, but your work shows that we really should be separating them more, so that the first Getting Started section covers the basics, and provides references to the detailed documentation in the Reference Guide. Martin has always been (rightly) keen to limit the PDF size of The Manual to ~ 5MB, on the basis that if it is any larger it becomes difficult to download and browse. It may be the case that we should look at splitting the tutorials off from the main manual, either as a single PDF containing all the tutorials, or as individual PDFs. This would have the advantage of allowing additional graphics withought impacting the main manual filesize. Food for thought! In terms of contents, I spotted the following issues on a quick skim through: - The FlightGear-Manual should be The FlightGear Manual - In English we don't use the subscript quotation mark „. - The default Windows directory on an Engish system will be under Program Files, rather than Programm Files - Installation needs to cover the (newish) FG_AIRCRAFT environmental variable. (Yes - The Manual doesn't cover that either at present ;) ) - VFR X-Country refers to KRHV as the destination airport in Merge into the pattern - In general there's an assumption that the user is going to use the command-line interface. I'm not sure that is valid - we should be trying to describe how to perform an action using either the command-line or GUI if possible. I also spotted a bunch of minor typos and places where the the English phraseology would be slightly different from the translation from German. To be honest, it's more hassle than it is worth typing them out here for you to transcribe them again into your HTML - they aren't major issues but small readability improvements. With access to the source code I could spend a good couple of hours going through and making minor corrections. I hope this helps. Finally, I think there are two related issues we need to address before we go any further: 1) You have a concern about copyright and presumably licensing, and from your previous email don't seem very keen to have your work released under the GPL. Can you explain in a bit more detail what your concerns are please? The Manual, like the rest of the FG base package, is released under the GPL, so this may stop any integration work in its tracks. 2) You've obviously put a lot of work into this. Martin and I have presented our view of why integrating this into the latex source of The Manual is the best way forward, but that is going to involve further work and will inevitably mean re-doing some of the work you've already done. What is your view - do you have any appetite for integrating this, or do you think there is a better way forward? Best regards, -Stuart -- Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability.
[Flightgear-devel] Links for new FlightGear pilots
On 5 Sep 2011, Stuart Buchanan wrote: . One immediate question is how you see your changes being incorporated into to latex source code? Producing a nice PDF is quite important for a lot of people so I wouldn't want to lose that. On 5 Sep 2011, Peter Morgan wrote: . I still like Jomo idea of a flight school very much.. starting from the bottom up.. from a cadet to a commander, atc et all Certainly though, looking toward the future and more usage.. and more eyes.. we should plan for that, not only in printed media.. but in game help of ipods of a website browsing on an olde retired FG machine The main issue to consider is whether is actually a flight manual of now to fly an aircaft, or the simulation .. or both We'd need to make it original and copyrightable to every contibutor to make it 100% proof.. Thank you both very much for your interest and encouragement I have to admit: I did not yet look into the current release and update process of the getstart. Martin Spott mentioned that latex system about a year ago, but to that time I planned just a pure translation, and thus saw that as a minor problem for me. Especially I did not see a major dependency on a PDF-base for my German version. Till now I saw that relatively blue-eyed. Let me just outline my process-environment: One guy with NO budget and no records department, using a single PC running Ubuntu, all tools are Multiplatform, OS, no charge: - the HTMLs are made with KompoZer, a very nice and easy WYSIWYG HTML-editor - pictures are edited with GIMP - PDFs are made by: Open the *.html with LibreOffice Writer (former OpenOffice), convert the page-format to Landscape and push the PDF-button -- and that's it. -- see 2 examples of the output (just converted as is!): http://www.emmerich-j.de/Handbuch/EN/B3_intro.pdf http://www.emmerich-j.de/Handbuch/EN/B8_IFR.pdf On first sight those prints look pretty good to me. (The location/size of some graphics could be relocated/sized already in the source! Maybe even add header/footer or so - but all in all ??) I agree: That is a very-very cheap and dirty approach - I hope you can help me finding something more adequate - based on your experiences. I mainly hang on the following questions: 1) I am sure that most of our customers/users today rather read/search online in a WIKI and/or Forum - but I also see that some people still prefer a hardcopy to study. (Is there an additional requirement for a hardcopy for advertisement and or selling?) 2) What customers/users are we addressing? Till now I mainly address - the FGFS-newbies that want to learn - and the FGFS-users that want to look up or refresh some basics 3) Is the PDF just used for Hardcopies or also for Online-Viewing? - If just a Hardcopy the above primitive conversion could be tuned to be good enough -- but all the extended internal and external linking would be lost in the hardcopy! -- would we then need the old style Index at the end? That would be a major effort! - Or do we need Softcopy PDF's to distribute for local off-line viewing -- then all the links still show up correct - but look for a html file - not a PDF. So that links would have to be edited. Personally I would guess that would not be a big effort with todays find/replace possibilities. 3a) or would it be easier to distribute the Handbook as html in a subdirectory to $FG_ROOT/data/docs, instead of the now getstart.pdf? The security/copyright problems would not change, because everybody can copy also a central HTML via todays browsers! Those browsers even have no problem in directly printing the HTML (If e.g. a user wants only some parts of it printed)! Maybe (in some future) that manual could even reside (controlled) in the GIT and thus would be a compromise to the WIKI-process. Everybody could input at any time (in normal text) and the responsible guy integrates that into the Manual. Again: I have no experience in that area and look for help. One word to Copyright and so. After finding out how easy it is nowadays to just copy the HTML-source from a browser and change and sell it - I am worried what to do against it. Right now I guess I have some private protection as the originator. But surely I would like to put it (some day?) into the ownership of FlightGear. In some of the discussions here I noticed there are quite some lawyers around - maybe someone can advise what to do. (I hope such a document must not be GNU/GPL like: Free!). And no big hurry: I still have to review (links, spelling, wording,..)! End of the month I want to link it on may homepage - and am sure that will not be the end of my work! Thank You for Your interest joe -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your
Re: [Flightgear-devel] Links for new FlightGear pilots
Jörg Emmerich wrote: 1) I am sure that most of our customers/users today rather read/search online in a WIKI and/or Forum - but I also see that some people still prefer a hardcopy to study. From my perspective the difference between a Wiki and a Manual is not so much about the format of distribution, instead it's a matter of being more up to date in contrast to having a structured document whereas it would be preferred to have a structured document which is up to date :-) 3) Is the PDF just used for Hardcopies or also for Online-Viewing? Both ;-) BTW, given the fact how little support there is for building structured and consistent documentation for FlightGear I think it's really sad having two competing efforts, both targeting the same audience, instead of joining forces. More than a decade ago LaTeX was chosen as the source format for the Getting Started Manual for different reasons: First, the quality of typesetting in its formatted output on the printer or in PostScript/PDF was unchallenged in OpenSource land and it still is. As an additional feature LaTeX allows you to export the document into almost every format you could think of (and maybe even more), including but not limited to HTML and PDF. Last but not least, and this is a really important point, LaTeX allows you to maintain the document as if it were just source code. It's just plain text, it's almost as easy to write as HTML, it allows adding incremental changes, thus you don't have to load a large document just to fix a typo, it allows everyone to track these changes and submit their own changes and it allows easy versioning using the tools we already have. The Manual has been available via CVS and later via GIT for years - that's collaboration made easy for everyone who's concerned about it. you're guessing right: I'm seriously asking why we should drop our current Manual in favour of a different one which probably has the same amount of drawbacks, just different ones. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
On 6 Sep 2011, at 09:12, Jörg Emmerich wrote: Thank you both very much for your interest and encouragement No problem. It is great that someone is interested in the docs. Unfortunately I think you could have saved yourself a lot of effort if you'd posted 6 months ago :( As you'll see from my answers below, all the issues you raise have already been handled by The Manual. I really think you need to be thinking about how to integrate your changes with what we already have rather than reinventing the wheel. I have to admit: I did not yet look into the current release and update process of the getstart. Martin Spott mentioned that latex system about a year ago, but to that time I planned just a pure translation, and thus saw that as a minor problem for me. Especially I did not see a major dependency on a PDF-base for my German version. Till now I saw that relatively blue-eyed. I suspected that might be the case. Let me just outline my process-environment: One guy with NO budget and no records department, using a single PC running Ubuntu, all tools are Multiplatform, OS, no charge: So is the toolchain for the existing manual - completely free and multi-platform. - the HTMLs are made with KompoZer, a very nice and easy WYSIWYG HTML-editor - pictures are edited with GIMP - PDFs are made by: Open the *.html with LibreOffice Writer (former OpenOffice), convert the page-format to Landscape and push the PDF-button -- and that's it. -- see 2 examples of the output (just converted as is!): http://www.emmerich-j.de/Handbuch/EN/B3_intro.pdf http://www.emmerich-j.de/Handbuch/EN/B8_IFR.pdf On first sight those prints look pretty good to me. (The location/size of some graphics could be relocated/sized already in the source! Maybe even add header/footer or so - but all in all ??) I agree: That is a very-very cheap and dirty approach - I hope you can help me finding something more adequate - based on your experiences. Easy - use the toolchain we already have! I mainly hang on the following questions: 1) I am sure that most of our customers/users today rather read/search online in a WIKI and/or Forum - but I also see that some people still prefer a hardcopy to study. (Is there an additional requirement for a hardcopy for advertisement and or selling?) We don't sell a hardcopy of the manual but people do print it out, so it is a requirement. PDF fulfils this requirement for The Manual. 2) What customers/users are we addressing? Till now I mainly address - the FGFS-newbies that want to learn - and the FGFS-users that want to look up or refresh some basics That's about right and matches the manual. 3) Is the PDF just used for Hardcopies or also for Online-Viewing? It needs to be viewable online as it is delivered with the release and people read it on their computer. - If just a Hardcopy the above primitive conversion could be tuned to be good enough -- but all the extended internal and external linking would be lost in the hardcopy! -- would we then need the old style Index at the end? That would be a major effort! Indeed it was! The Manual includes a comprehensive index that we have kept up to date over the years. - Or do we need Softcopy PDF's to distribute for local off-line viewing Yes. We need both. -- then all the links still show up correct - but look for a html file - not a PDF. The Manual uses internal links. In the PDF they are links within the PDF, and in the HTML version they are HTML. Very simple. So that links would have to be edited. Not if you are using The Manual toolchain. Personally I would guess that would not be a big effort with todays find/replace possibilities. Yes it would. 3a) or would it be easier to distribute the Handbook as html in a subdirectory to $FG_ROOT/data/docs, instead of the now getstart.pdf? Is the Handbook the work you've done? If so - no. We would be losing a huge amount of function as detailed above, quite apart from any issues of content, grammar etc. Plus there is the whole area of long term maintainability. To be brutally honest we've already got a manual that represents a huge amount of work and maintenance and I would be loath to lose it. The security/copyright problems would not change, because everybody can copy also a central HTML via todays browsers! Those browsers even have no problem in directly printing the HTML (If e.g. a user wants only some parts of it printed)! Maybe (in some future) that manual could even reside (controlled) in the GIT and thus would be a compromise to the WIKI-process. The source Latex code, build tools etc are already under Git! (We have been working on this for a number of years!) Everybody could input at any time (in normal text) and the responsible guy integrates that into the Manual. We already have this and have integrated a number of people's changes over the years. The only issue we've had has been that
Re: [Flightgear-devel] Links for new FlightGear pilots
Emmerich.. maybe we need a new documentation plan.. so u start it in your mother tounge.. I thinks this agood idea as your have a determined mind and idea I think the best way is to write paragraphs in plain text and later we can all convert... This is better than tryiing to update the original as is a better plan.. IMHO.. at least u are movvayed to do this... and wish to help./// pete On Sun, Sep 4, 2011 at 4:31 PM, Jörg Emmerich j-emmer...@online.de wrote: Hi Gijs, thank you very much for that detailed and competent analysis in such a short time-frame. Let me comment the most difficult question first: Should it be a WIKI? My many links for further details see: WIKI... and also several articles from me in the FGFS/wiki should reveal me as a big believer in WIKI's, as well FGFS as also WIKIPEDIA. I even have extracted some parts of the current getstart.pdf and put them into the FGFSwiki (and just reffed them with a few words in the manual). And I do want to do more of those! That way I also hope to get the valuable WIKI-idea promoted to be used even more, which would get them more attention and thus more chances to get them updated in reasonable time-spans. On the other hand: I believe WIKIs have their very big advantage in unique details - not really in manuals! In my eyes each product does need a manual that explains the Basics to the customer and then shows him where to get more infos.(Yes: I belong to the people looking into the manuals when buying a PC, TV, Auto, etc.!). And that basics (in my eyes) should express the company's (i.e. FlightGears inner devel circle) involvement/direction/supervision! My concern is, that many small pieces may be able to replace a manual at the beginning - but over a longer timeframe they will change, specialize, and lose their connecting identities! See the Curtis opening problem! And also see todays WIKI: All the informations are there - often in multiple versions and/or with different focuses. They are fantastic for the guys knowing the basics and thus what to look for - but difficult to select what is needed by a newbie! Surely it will be a big effort for anybody to keep it updated to all future FGFS-changes! But I believe those are easier to control in one single document under the Development responsibility and a defined content in unique chapters - then when the content is distributed in many small pieces without defined ownership and/or responsibility. (Does anybody have the slightest idea how many WIKIS are affected by the latest 2.4.0 changes??) Based on that fear I tried to structure the Basics in some unique Chapters that contain more technical dependencies and those that are more for teaching and looking. So with a new version you do not need to update everything - and what needs to be updated is at one known location only - not distributed in many uncontrollable pieces! And still it would be relatively easy to convert that manual to WIKI - if needed! Right now I would vote against it! And yes, sorry: I have forgotten to mention the very useful forums - - I will correct that! One more hot item I would like to sell: Sidebars or drop downs I decided against sidebars because of: 1) I wanted that book to be without any need for executable, supporting sftw. like e.g. java (virus-prone) 2) I tried it with sidebars - but then it becomes again very confusing if headers are more than just one short word. I hate indexes like now in the getstart.pdf - where you have long headers going over several lines. I like my solution that allows long, ease readable titles -- and still have room for a nice picture to it! 2) There are still many customers with old tiny screens - I rather wanted that valuable side-space for big illustrations 4) Those top/sidebars become pretty much a standard for industries and business pages - I thought my way gives more the feeling of private pilot to private pilot (I just did not yet find a place for the beer-can!) So I came up with that top menu-bar that stays there all the time. From wherever you are in the text, you can always just select any part in the bar (including the current one) and have that index in an easy to read fashion. I know it is unusual and may be one more mouse-click - but I personally like that more private atmosphere. But I would like to hear more
Re: [Flightgear-devel] Links for new FlightGear pilots
On 1 Sep 2011, at 08:37, Jörg Emmerich wrote: I wanted to introduce that outcome about end of this month to the dev-team, to see especially whether the Originators of the getstart still find their share in what I did, and concur to this change. I hope nobody feels offended by my partly drastic changes to their origin. You will see that I still list the Originators and just claim the Revision for myself. Any comments, critics, suggestions, improvements, etc. are highly welcome. joe (jomo) Hi jomo, Firstly, thanks very much for looking at improving The Manual. I'm currently on vacation so haven't had the chance to look at your work in detail but thought I should comment in case you thought you were being ignored by the maintainers. One immediate question is how you see your changes being incorporated into to latex source code? Producing a nice PDF is quite important for a lot of people so I wouldn't want to lose that. More comments when I get the time once I'm back. Best regards -Stuart -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
anyone looked at docbook. It would solve the problem.. but its a horrible to use.. but there again that was with my experience a few years ago doing a major update to smarty.php (had to it as my team was using it and was paid as thus by my boss) I certainly think that a html5/xml approach is cool approach.. nowadays and wish to help... I dont like pdf's when I try to mix or even knock them off from the server live, unlike other archived docs... pdf editing to me is an art form.. But IMHO we would need to take the markup approach from now.. maybe even a fresh start... and cut and paste stuff across.. eg article section land=enthis is english, and maybe the source/section section lang=dethis a lang section but also maybe this last line a source/section section lang=edthis aanother lang section/section /article certainly having files side by side can be a good way of translating.. eg a geman commit - to /ils/glideslope.en.html !-- please fix spelling mistake... ;-) -- /ils/glideslope.ge.html !-- correcting english mistake... ;-) -- and thus an observation by another to translate file in same patch and topic... ALso.. me need to structure the manual into chapters.. but obvious ones in directories that diectly map to url's eg /aiports/atc /airport/runway/papi /glossay/atc, papi, I still like Jomo idea of a flight school very much.. starting from the bottom up.. from a cadet to a commander, atc et all Certainly though, looking toward the future and more usage.. and more eyes.. we should plan for that, not only in printed media.. but in game help of ipods of a website browsing on an olde retired FG machine The main issue to consider is whether is actually a flight manual of now to fly an aircaft, or the simulation .. or both We'd need to make it original and copyrightable to every contibutor to make it 100% proof.. just some thoughts... pete On Mon, Sep 5, 2011 at 2:45 PM, Stuart Buchanan stuar...@gmail.com wrote: On 1 Sep 2011, at 08:37, Jörg Emmerich wrote: I wanted to introduce that outcome about end of this month to the dev-team, to see especially whether the Originators of the getstart still find their share in what I did, and concur to this change. I hope nobody feels offended by my partly drastic changes to their origin. You will see that I still list the Originators and just claim the Revision for myself. Any comments, critics, suggestions, improvements, etc. are highly welcome. joe (jomo) Hi jomo, Firstly, thanks very much for looking at improving The Manual. I'm currently on vacation so haven't had the chance to look at your work in detail but thought I should comment in case you thought you were being ignored by the maintainers. One immediate question is how you see your changes being incorporated into to latex source code? Producing a nice PDF is quite important for a lot of people so I wouldn't want to lose that. More comments when I get the time once I'm back. Best regards -Stuart -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Links for new FlightGear pilots
Hi Gijs, thank you very much for that detailed and competent analysis in such a short time-frame. Let me comment the most difficult question first: Should it be a WIKI? My many links for further details see: WIKI... and also several articles from me in the FGFS/wiki should reveal me as a big believer in WIKI's, as well FGFS as also WIKIPEDIA. I even have extracted some parts of the current getstart.pdf and put them into the FGFSwiki (and just reffed them with a few words in the manual). And I do want to do more of those! That way I also hope to get the valuable WIKI-idea promoted to be used even more, which would get them more attention and thus more chances to get them updated in reasonable time-spans. On the other hand: I believe WIKIs have their very big advantage in unique details - not really in manuals! In my eyes each product does need a manual that explains the Basics to the customer and then shows him where to get more infos.(Yes: I belong to the people looking into the manuals when buying a PC, TV, Auto, etc.!). And that basics (in my eyes) should express the company's (i.e. FlightGears inner devel circle) involvement/direction/supervision! My concern is, that many small pieces may be able to replace a manual at the beginning - but over a longer timeframe they will change, specialize, and lose their connecting identities! See the Curtis opening problem! And also see todays WIKI: All the informations are there - often in multiple versions and/or with different focuses. They are fantastic for the guys knowing the basics and thus what to look for - but difficult to select what is needed by a newbie! Surely it will be a big effort for anybody to keep it updated to all future FGFS-changes! But I believe those are easier to control in one single document under the Development responsibility and a defined content in unique chapters - then when the content is distributed in many small pieces without defined ownership and/or responsibility. (Does anybody have the slightest idea how many WIKIS are affected by the latest 2.4.0 changes??) Based on that fear I tried to structure the Basics in some unique Chapters that contain more technical dependencies and those that are more for teaching and looking. So with a new version you do not need to update everything - and what needs to be updated is at one known location only - not distributed in many uncontrollable pieces! And still it would be relatively easy to convert that manual to WIKI - if needed! Right now I would vote against it! And yes, sorry: I have forgotten to mention the very useful forums - - I will correct that! One more hot item I would like to sell: Sidebars or drop downs I decided against sidebars because of: 1) I wanted that book to be without any need for executable, supporting sftw. like e.g. java (virus-prone) 2) I tried it with sidebars - but then it becomes again very confusing if headers are more than just one short word. I hate indexes like now in the getstart.pdf - where you have long headers going over several lines. I like my solution that allows long, ease readable titles -- and still have room for a nice picture to it! 2) There are still many customers with old tiny screens - I rather wanted that valuable side-space for big illustrations 4) Those top/sidebars become pretty much a standard for industries and business pages - I thought my way gives more the feeling of private pilot to private pilot (I just did not yet find a place for the beer-can!) So I came up with that top menu-bar that stays there all the time. From wherever you are in the text, you can always just select any part in the bar (including the current one) and have that index in an easy to read fashion. I know it is unusual and may be one more mouse-click - but I personally like that more private atmosphere. But I would like to hear more comments to that. Thank you very much for the many other hints - they all seem very valuable - I will update accordingly. And surely we will talk again when I have a feeling for how that new style gets accepted inside the community. Thank you joe -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better
Re: [Flightgear-devel] Links for new FlightGear pilots
Hi Jörg! I only checked the English manual and did not read it thoroughly (way too much text. I got my (aerospace engineering!) study books last week and I decided that I should save my eyes/mind for the millions of pages (those books are way too heavy!) that I'll have to read the upcoming five years :P). Some comments though: What I miss:a link to the forum, for further support (when the wiki/manual are not sufficient).an index that can be viewed anywhere on the page. Right now it's just at the top of each chapter. I don't want to scroll up, just to skip some subjects. Maybe a dropdown list from the main menu? Or some Adobe Reader-like sidebar. Just thinking out loud here ;)most screenshots have no description. As an user I'd like to know the name of the aircraft I'm seeing; so I can launch it up in FlightGear!capital consistency in enumerations. If your second point starts with a lower font, the third should as well. A good example can be seen under Takeoff at http://www.emmerich-j.de/Handbuch/EN/4_Solo.html 1,4,5,6 start with a capital letter, while 2 and 3 don't.would be nice if clicking an abbreviation doesn't bring you to a long list, instead show a little popup/hover explaining the abbreviation. Typos/faults/mistakes I found:at http://www.emmerich-j.de/Handbuch/EN/2_Install.html the image description is Deutsch :)links to the wiki link to German articles. For example: http://www.emmerich-j.de/Handbuch/EN/B9_Features.html#mozTocId507437the appendix doesn't list all the contributors. Better list none then some IMO. Rather than giving an incomplete list of The following individuals have contributed to the scenery object database you might link to the authors page of the database. What I am worried about:Altough I really like this manual, I have some worries on how you'll keep it up to date. As we see at the wiki, it's very hard to keep up with FlightGear's pace. And that's on a place anyone can edit easily...Your version is much more up to date than the current manual, but I wonder if that's just because you spend so much time on writing it (I guess you won't spend that much time updating it on every release). If this doesn't end up being used as an official manual in the base package, do consider copying stuff to the wiki. You've got some subjects that aren't covered there as of yet ;) Thanks a lot for the hardwork! It's really appreciated (I do at least)! I'm sure we'll be able to use most of it (if not all) in some way or another! Cheers,Gijs -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Links for new FlightGear pilots
Curtis actually your question hits me about 1 month too early! I am in the midst of a final checkout of my proposal for a newly styled getstart. But you asked now - so I guess I ask everyone if my proposal could be seen as what you are asking for. Pls have a look at http://www.emmerich-j.de/Handbuch/EN/1_Start.html and/or http://www.emmerich-j.de/Handbuch/DE/1_Start.html Again: I planned to introduce this end of the month - but if people believe it could be useful I welcome all help I can get to finalize it! To the History: I am not sure anybody still remembers that I announced about 1.5 years ago to translate the existing getstart.pdf into German. In the meantime I did that - 3 times: 1. Attempt While translating I noticed very often that I was not sure if that, what I was reading was fitting all environments or just MAC or .. or. Also the MakeUp was not really fitting any more the current modern FlightGear. So my major change was to define one central chapter (Installation) in which all OS-Dependencies are covered by defining the Variables $FG_... for all OS's - and referred to those throughout the book. Also I tried to remove several long listings of Options, Possibilities etc. out of the text into the Appendix or special chapters! 2. Attempt After having tested that I still was not satisfied with how to use it as a Reference. i.e. it was nice to read from the beginning to the end - but if you had a unique question after that, I found it very difficult to find an answer for a unique detail in the getstart. So I restructured that whole thing in the hope of getting a Manual to read, being also for the inpatient newbie and also as a Reference for all Basics. 3. Attempt That 2. I liked better - and thought it might be useful also for the people with an English Tongue - so now I translated that German one back to English. And tried to use as much of the English Original speech as possible -- that then made me adapting my German version again - so both are now equal. I wanted to introduce that outcome about end of this month to the dev-team, to see especially whether the Originators of the getstart still find their share in what I did, and concur to this change. I hope nobody feels offended by my partly drastic changes to their origin. You will see that I still list the Originators and just claim the Revision for myself. Any comments, critics, suggestions, improvements, etc. are highly welcome. joe (jomo) -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
Jörg wrote Curtis actually your question hits me about 1 month too early! I am in the midst of a final checkout of my proposal for a newly styled getstart. But you asked now - so I guess I ask everyone if my proposal could be seen as what you are asking for. Pls have a look at http://www.emmerich-j.de/Handbuch/EN/1_Start.html and/or http://www.emmerich-j.de/Handbuch/DE/1_Start.html Again: I planned to introduce this end of the month - but if people believe it could be useful I welcome all help I can get to finalize it! To the History: I am not sure anybody still remembers that I announced about 1.5 years ago to translate the existing getstart.pdf into German. In the meantime I did that - 3 times: 1. Attempt While translating I noticed very often that I was not sure if that, what I was reading was fitting all environments or just MAC or .. or. Also the MakeUp was not really fitting any more the current modern FlightGear. So my major change was to define one central chapter (Installation) in which all OS-Dependencies are covered by defining the Variables $FG_... for all OS's - and referred to those throughout the book. Also I tried to remove several long listings of Options, Possibilities etc. out of the text into the Appendix or special chapters! 2. Attempt After having tested that I still was not satisfied with how to use it as a Reference. i.e. it was nice to read from the beginning to the end - but if you had a unique question after that, I found it very difficult to find an answer for a unique detail in the getstart. So I restructured that whole thing in the hope of getting a Manual to read, being also for the inpatient newbie and also as a Reference for all Basics. 3. Attempt That 2. I liked better - and thought it might be useful also for the people with an English Tongue - so now I translated that German one back to English. And tried to use as much of the English Original speech as possible -- that then made me adapting my German version again - so both are now equal. I wanted to introduce that outcome about end of this month to the dev-team, to see especially whether the Originators of the getstart still find their share in what I did, and concur to this change. I hope nobody feels offended by my partly drastic changes to their origin. You will see that I still list the Originators and just claim the Revision for myself. Any comments, critics, suggestions, improvements, etc. are highly welcome. Spelling the title correctly in the English version would be a huge improvement. Vivian -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
Am 01.09.11 10:24, schrieb Vivian Meazza: Spelling the title correctly in the English version would be a huge improvement. Vivian Hi Jörg I hope Vivians English style is not the only feedback you get about your work here. Your contribution is welcome, at lest for me, and maybe others can say something about how your work becomes part of FlightGear user documentation ? Cheers, Yves -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Links for new FlightGear pilots
I'd like to find a few really good quality links (web pages really) that are especially helpful for new FlightGear pilots. I get quite a few questions from people who fire up FlightGear for the first time and have little aviation experience and zero prior FlightGear experience. They need really basic help, like how do you start the engine. Or they need basic description of how to install aircraft or scenery. I know some of this is scattered around on the wiki and the manual ... but I'm hoping people can send me some really good links for basic beginners -- nothing is too obvious here, assume I know nothing. :-) - basic engine startup and taking off. - basic installation of aircraft / scenery - good tutorials targeted towards new pilots The goal here is to get a brand new user over the very first hump and see some initial success very quickly. Thanks! Curt -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
Curtis Olson wrote: I get quite a few questions from people who fire up FlightGear for the first time and have little aviation experience and zero prior FlightGear experience. They need really basic help, like how do you start the engine. I think you're looking for a concise manual :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
