Re: [Kicad-developers] Documentation format is AsciiDoc
On 9 February 2015 at 12:46, Brian Sidebotham wrote: > I didn't see an /official/ announcement so I wanted to just put it out > there clearly, that AsciiDoc is the chosen format for KiCad's > documentation (user manuals and the like). > > More information about asciidoc can be is available from the asciidoc > homepage: http://www.methods.co.nz/asciidoc/ Jeez, I should take more time to proof-read emails! More information about asciidoc is available from the asciidoc homepage: http://www.methods.co.nz/asciidoc/ Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Documentation format is AsciiDoc
I didn't see an /official/ announcement so I wanted to just put it out there clearly, that AsciiDoc is the chosen format for KiCad's documentation (user manuals and the like). More information about asciidoc can be is available from the asciidoc homepage: http://www.methods.co.nz/asciidoc/ ..and also see the more active asciidoctor implementation which is written in Ruby and is providing things like direct PDF compilation of asciidoc documents: http://asciidoctor.org/ NOTE: asciidoctor-pdf is currently considered alpha stage. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
On Fri, Feb 06, 2015 at 11:55:58AM +1300, Blair Bonnett wrote: > On 6 February 2015 at 02:52, Wayne Stambaugh wrote: > > > > Marco, you may want to enlist some help. Once all of the documentation > > and build configuration is ready to go, I expect that there will be a > > lot of pull requests to get the documentation ready for the stable > > release. > > > > Some form of task list will be vital here. good idea > Even something like getting a > list of all chapter (or section?) titles and putting them into a wiki page. as you suggest... (see below) -> > Then get people to put their name beside what they are working on. Being a > text format, merging edited sections from different people *shouldn't* be > too tricky, but we don't want multiple people working on the same thing. right > For simplicity, I'd put it on the GitHub wiki for the documentation project > and stick a link to it in the readme. That way, anybody who has a GitHub > account (i.e., anybody who can send a pull request to the project) can edit > the list. -> ...here. It is just a very good idea! Cheers -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
On 6 February 2015 at 02:52, Wayne Stambaugh wrote: > > Marco, you may want to enlist some help. Once all of the documentation > and build configuration is ready to go, I expect that there will be a > lot of pull requests to get the documentation ready for the stable release. > Some form of task list will be vital here. Even something like getting a list of all chapter (or section?) titles and putting them into a wiki page. Then get people to put their name beside what they are working on. Being a text format, merging edited sections from different people *shouldn't* be too tricky, but we don't want multiple people working on the same thing. For simplicity, I'd put it on the GitHub wiki for the documentation project and stick a link to it in the readme. That way, anybody who has a GitHub account (i.e., anybody who can send a pull request to the project) can edit the list. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
On Wed, Feb 04, 2015 at 01:31:25AM +, John Beard wrote: [...] Well, I could not have said it better. We can choose a format now, knowing that eventually it will not be so difficult to change again into another format in the future if we decide to do so. And if I have done some work I have to thank those people that helped me like John, Alexander and others. Having said so I would like to express my preference to maintain the multiple output format. That could help greatily to lower the barrier to diffuse our beloved CAD. Of course I will be doing my best to maintain the toolchain neccessary to this aim nevertheless the html format alone is easier to use (by just substitute the pdf viewer with a browser) and to maintain (html generation is less error prone than docbook->latex->pdf|ebook). I LOVE read technical books away from the distracting keyboard of a PC and pdf and ebook are perfect for those handy ebook readers like Kindle and iPad. I have seen that there are more and more IT manuals and guides developed with similar toolchains; that could a day produce (why not?) some serious KiCad manual on the shelf of an electronic bookstore. For now I have to port the rest of the docs into the choosen format and to format / improve the existing docs. So lets choose the format and go on! -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
On 2/5/2015 9:45 AM, Fat-Zer wrote: > 2015-02-05 16:52 GMT+03:00 Wayne Stambaugh : >> On 2/5/2015 5:03 AM, Fat-Zer wrote: >>> 2015-02-04 19:52 GMT+03:00 Wayne Stambaugh : CMake should be used as the build configuration tool which is used to verify all of the required tools are installed on the system and automatically generate the appropriate Makefiles. CMake files would go in the kicad-doc repo and replace the current Makefiles. It would be nice if everything was in one place. That may be a goal for the distant future. For now, we have more important issues to worry about. >>> Hi, I've done some cmake macro scripting for building asciidoc based >>> on Marco's repository some time ago: >>> https://github.com/Fat-Zer/kicad-doc >>> It's ready to use for generate output in several formats like docbook, >>> pdf, html and other. >>> But, by the word, it doesn't check some special additional >>> dependencies for specific formats... may be I'll add a test if >>> specified format may be build in future... >> >> This is important. The build configuration should always test for >> dependencies and fail during the configuration rather than fail during >> the build for missing dependencies. Brian has graciously offered to >> help with the CMake stuff. He has a lot of experience in this area. >> Brian, would you please take a look at the CMake stuff and see what >> needs to be done to get this production ready? Once it's cleaned up, it >> should be merged into Marco's branch so that the documentation and the >> build configuration is in the same place. > Yep, I like your concerns about failings and performing as much tests > as possible during the configuration time, because IMO it's an > important part of the build QA. On the other hand it's hard to track > what specific dependencies are missing because a2x uses them > indirectly. But that's about only formats processed by a2x like pdf > epub etc. Docbook and html supposed to work whenever asciidoc works > correct. The solution is to create a small test doc and call a2x with the appropriate switches and verify a2x doesn't fail. You should be able to test for all of the required a2x dependencies this way. It's kind of like writing a small C or C++ program to test if a compiler supports a given feature. This is one of the most accurate ways to test for features. The beauty of this method is that it will work for any platform. > >> >> Marco, you may want to enlist some help. Once all of the documentation >> and build configuration is ready to go, I expect that there will be a >> lot of pull requests to get the documentation ready for the stable release. >> >> I haven't had time to look but is there any documentation on how to >> contribute and create translations using the CMake configuration? It >> might be a good idea to provide this for new contributors. I'm guessing >> not all of our documentation folks are familiar with using cmake, git, >> and github. We want to make sure that it is as easy as possible for >> folks to contribute documentation. > Do you mean build translated documentation? Yes, they are build by > default... you can alter the KICAD_DOC_TRANSLATIONS var to set the > list of whatever specific languages you want to build. > The translation process by it self is handled with an utility set > called po4a. The creation of new and update of the existing > translations is not yet supported by my cmake scripts. > I just ant to make sure it's obvious to the documentation devs what files to edit and how to build the documentation so they can verify their work. Using LibreOffice writer is pretty straight forward for most of our translators. There may be some who are not comfortable running CMake and 'make foo' to build the documentation. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
2015-02-05 16:52 GMT+03:00 Wayne Stambaugh : > On 2/5/2015 5:03 AM, Fat-Zer wrote: >> 2015-02-04 19:52 GMT+03:00 Wayne Stambaugh : >>> >>> CMake should be used as the build configuration tool which is used to >>> verify all of the required tools are installed on the system and >>> automatically generate the appropriate Makefiles. CMake files would go >>> in the kicad-doc repo and replace the current Makefiles. >>> >>> It would be nice if everything was in one place. That may be a goal for >>> the distant future. For now, we have more important issues to worry about. >>> >> Hi, I've done some cmake macro scripting for building asciidoc based >> on Marco's repository some time ago: >> https://github.com/Fat-Zer/kicad-doc >> It's ready to use for generate output in several formats like docbook, >> pdf, html and other. >> But, by the word, it doesn't check some special additional >> dependencies for specific formats... may be I'll add a test if >> specified format may be build in future... > > This is important. The build configuration should always test for > dependencies and fail during the configuration rather than fail during > the build for missing dependencies. Brian has graciously offered to > help with the CMake stuff. He has a lot of experience in this area. > Brian, would you please take a look at the CMake stuff and see what > needs to be done to get this production ready? Once it's cleaned up, it > should be merged into Marco's branch so that the documentation and the > build configuration is in the same place. Yep, I like your concerns about failings and performing as much tests as possible during the configuration time, because IMO it's an important part of the build QA. On the other hand it's hard to track what specific dependencies are missing because a2x uses them indirectly. But that's about only formats processed by a2x like pdf epub etc. Docbook and html supposed to work whenever asciidoc works correct. > > Marco, you may want to enlist some help. Once all of the documentation > and build configuration is ready to go, I expect that there will be a > lot of pull requests to get the documentation ready for the stable release. > > I haven't had time to look but is there any documentation on how to > contribute and create translations using the CMake configuration? It > might be a good idea to provide this for new contributors. I'm guessing > not all of our documentation folks are familiar with using cmake, git, > and github. We want to make sure that it is as easy as possible for > folks to contribute documentation. Do you mean build translated documentation? Yes, they are build by default... you can alter the KICAD_DOC_TRANSLATIONS var to set the list of whatever specific languages you want to build. The translation process by it self is handled with an utility set called po4a. The creation of new and update of the existing translations is not yet supported by my cmake scripts. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
On 2/5/2015 5:03 AM, Fat-Zer wrote: > 2015-02-04 19:52 GMT+03:00 Wayne Stambaugh : >> >> CMake should be used as the build configuration tool which is used to >> verify all of the required tools are installed on the system and >> automatically generate the appropriate Makefiles. CMake files would go >> in the kicad-doc repo and replace the current Makefiles. >> >> It would be nice if everything was in one place. That may be a goal for >> the distant future. For now, we have more important issues to worry about. >> > Hi, I've done some cmake macro scripting for building asciidoc based > on Marco's repository some time ago: > https://github.com/Fat-Zer/kicad-doc > It's ready to use for generate output in several formats like docbook, > pdf, html and other. > But, by the word, it doesn't check some special additional > dependencies for specific formats... may be I'll add a test if > specified format may be build in future... This is important. The build configuration should always test for dependencies and fail during the configuration rather than fail during the build for missing dependencies. Brian has graciously offered to help with the CMake stuff. He has a lot of experience in this area. Brian, would you please take a look at the CMake stuff and see what needs to be done to get this production ready? Once it's cleaned up, it should be merged into Marco's branch so that the documentation and the build configuration is in the same place. Marco, you may want to enlist some help. Once all of the documentation and build configuration is ready to go, I expect that there will be a lot of pull requests to get the documentation ready for the stable release. I haven't had time to look but is there any documentation on how to contribute and create translations using the CMake configuration? It might be a good idea to provide this for new contributors. I'm guessing not all of our documentation folks are familiar with using cmake, git, and github. We want to make sure that it is as easy as possible for folks to contribute documentation. Thanks, Wayne > > I've gonna to report it after I'll add some macro to update the *.po > files but have not finished it yet... > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
On 5 February 2015 at 10:54, Miguel Ángel Ajo wrote: > https://github.com/Fat-Zer/kicad-doc/tree/cmake > > It’s in a separate branch :-) > > Miguel Ángel Ajo Ah, I was missing something! lol. Thanks Miguel... Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
https://github.com/Fat-Zer/kicad-doc/tree/cmake It’s in a separate branch :-) Miguel Ángel Ajo On Thursday, 5 de February de 2015 at 11:53, Brian Sidebotham wrote: > On 5 February 2015 at 10:03, Fat-Zer (mailto:fatz...@gmail.com)> wrote: > > 2015-02-04 19:52 GMT+03:00 Wayne Stambaugh > (mailto:stambau...@gmail.com)>: > > > > > > CMake should be used as the build configuration tool which is used to > > > verify all of the required tools are installed on the system and > > > automatically generate the appropriate Makefiles. CMake files would go > > > in the kicad-doc repo and replace the current Makefiles. > > > > > > It would be nice if everything was in one place. That may be a goal for > > > the distant future. For now, we have more important issues to worry about. > > > > > > > Hi, I've done some cmake macro scripting for building asciidoc based > > on Marco's repository some time ago: > > https://github.com/Fat-Zer/kicad-doc > > It's ready to use for generate output in several formats like docbook, > > pdf, html and other. > > But, by the word, it doesn't check some special additional > > dependencies for specific formats... may be I'll add a test if > > specified format may be build in future... > > > > I've gonna to report it after I'll add some macro to update the *.po > > files but have not finished it yet... > > > > > Hi Fat-Zer, > > I cannot see any CMakeLists.txt in that repo, am I missing something? > > Best Regards, > > Brian. > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > (mailto:kicad-developers@lists.launchpad.net) > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
On 5 February 2015 at 10:03, Fat-Zer wrote: > 2015-02-04 19:52 GMT+03:00 Wayne Stambaugh : >> >> CMake should be used as the build configuration tool which is used to >> verify all of the required tools are installed on the system and >> automatically generate the appropriate Makefiles. CMake files would go >> in the kicad-doc repo and replace the current Makefiles. >> >> It would be nice if everything was in one place. That may be a goal for >> the distant future. For now, we have more important issues to worry about. >> > Hi, I've done some cmake macro scripting for building asciidoc based > on Marco's repository some time ago: > https://github.com/Fat-Zer/kicad-doc > It's ready to use for generate output in several formats like docbook, > pdf, html and other. > But, by the word, it doesn't check some special additional > dependencies for specific formats... may be I'll add a test if > specified format may be build in future... > > I've gonna to report it after I'll add some macro to update the *.po > files but have not finished it yet... Hi Fat-Zer, I cannot see any CMakeLists.txt in that repo, am I missing something? Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
2015-02-04 19:52 GMT+03:00 Wayne Stambaugh : > > CMake should be used as the build configuration tool which is used to > verify all of the required tools are installed on the system and > automatically generate the appropriate Makefiles. CMake files would go > in the kicad-doc repo and replace the current Makefiles. > > It would be nice if everything was in one place. That may be a goal for > the distant future. For now, we have more important issues to worry about. > Hi, I've done some cmake macro scripting for building asciidoc based on Marco's repository some time ago: https://github.com/Fat-Zer/kicad-doc It's ready to use for generate output in several formats like docbook, pdf, html and other. But, by the word, it doesn't check some special additional dependencies for specific formats... may be I'll add a test if specified format may be build in future... I've gonna to report it after I'll add some macro to update the *.po files but have not finished it yet... ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
Sorry, I believe I understood wrong previous Nick suggestion about hosting stuff at the current kicad servers. I’m all for doing CI, and rendering the documentation out to: http://doc.kicad-pcb.org or the chosen subdomain. If that was the suggestion, that’s only static file serving, which is cheap and with 0 maintenance. If the suggestion was “let’s install something like github” to do SCM & collaboration, that’s another beast (installs, upgrades, fighting spammers…). Best regards, Miguel Ángel. On Wednesday, 4 de February de 2015 at 21:12, Bob Gustafson wrote: > > On 02/04/2015 10:13 AM, Nick Østergaard wrote: > > > > I'll put a CMake build system in place on the documentation and make > > > > > > sure it works on Windows + Linux. OSX guys will have to help me in > > > > > > making sure it works there. It shouldn't be a problem though. > > > > > > > > > > > > > > > > > > > > > > > > > > What does this cmake include? Does it reside in the kicad-doc repo or > > in the kicad repo? > > > > On OSX, I am shooting for a directory structure like so: > > KiCad > Common > Help > Doc > Libraries > Legacy > Fp.. > > ProjectNumber1 > ProjectNumber1.pro > ProjectNumber1.cmp > ProjectNumber1.pcb > . > > ProjectNumber2 > ProjectNumber2.pro > ProjectNumber2.cmp > ProjectNumber2.pcb > . > > ProjectNumber3 > ProjectNumber3.pro > ProjectNumber3.cmp > ProjectNumber3.pcb > . > > But whatever - but so far the Help and Docs are not hooked up to my GUI > > Best Regards > > Bob G > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > (mailto:kicad-developers@lists.launchpad.net) > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
On 02/04/2015 10:13 AM, Nick Østergaard wrote: I'll put a CMake build system in place on the documentation and make >>sure it works on Windows + Linux. OSX guys will have to help me in >>making sure it works there. It shouldn't be a problem though. What does this cmake include? Does it reside in the kicad-doc repo or in the kicad repo? On OSX, I am shooting for a directory structure like so: KiCad Common Help Doc Libraries Legacy Fp.. ProjectNumber1 ProjectNumber1.pro ProjectNumber1.cmp ProjectNumber1.pcb . ProjectNumber2 ProjectNumber2.pro ProjectNumber2.cmp ProjectNumber2.pcb . ProjectNumber3 ProjectNumber3.pro ProjectNumber3.cmp ProjectNumber3.pcb . But whatever - but so far the Help and Docs are not hooked up to my GUI Best Regards Bob G ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
On Wed, Feb 04, 2015 at 05:13:05PM +0100, Nick Østergaard wrote: > I think HTML and PDF is what is required, I guess some people would > like epub, but that is basically not much different to HTML in > structure, hence I think that should look equally fine in HTML as in > epub. AFAIK epub is more or less html in a zipfile, so it should work fine. And anyway it wasn't meant for technical documentation, but for prose... I think that kicad manual isn't a leisurely read during commuting :P -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
On Wednesday, 4 de February de 2015 at 17:52, Wayne Stambaugh wrote: > On 2/4/2015 11:13 AM, Nick Østergaard wrote: > > 2015-02-04 15:06 GMT+01:00 Wayne Stambaugh > (mailto:stambau...@gmail.com)>: > > > On 2/4/2015 7:10 AM, Brian Sidebotham wrote: > > > > On 4 February 2015 at 00:14, Wayne Stambaugh > > > (mailto:stambau...@gmail.com)> wrote: > > > > > We need to make a decision soon if we want to get the documentation > > > > > conversion completed in time for the next stable release. I'm still > > > > > not > > > > > sure we can build on Windows. Neither the MSYS2 asciidoc or sphinx > > > > > implementations worked correctly the last time I tried them and I have > > > > > no way to test any of this on OSX. Cygwin may work but the last time I > > > > > tried to build kicad on cygwin, it was more trouble than it was worth. > > > > > This would limit us to building the documentation only on linux which > > > > > I'm not terribly thrilled about. This means if you wanted to build a > > > > > windows installer you would have to run linux in a VM to build the > > > > > documentation. That would be painful for our auto builders folks. If > > > > > we get much further along, we may just have to live with the > > > > > documentation we have now and convert to a plain text format for the > > > > > next release. > > > > > > > > > > > > > > > > > I think we're pretty much decided already on asciidoc - it just takes > > > > someone to say so. I've included Marco on this email so perhaps he > > > > could give us his up-to-date conclusion and we can make the decision > > > > now. > > > > > > > > As for being able to build, well, we need to decide on an output > > > > format. I think we've previously been hinting at html rather than PDF. > > > > We don't need to support a million output formats. PDF is much harder > > > > to support compared to HTML for example. > > > > > > > > > > > > > > > > I think HTML and PDF is what is required, I guess some people would > > like epub, but that is basically not much different to HTML in > > structure, hence I think that should look equally fine in HTML as in > > epub. > > > > > > However, nothing requires a POSIX shell, so we definitely don't need > > > > to add-in cygwin, MSYS2 or anything else as a dependency for building > > > > docs. > > > > > > > > asciidoc works okay for me under windows, but a2x for PDF conversion > > > > doesn't work. However, projects like asciidoctor-fopub and > > > > asciidoctor-pdf are well underway to sort that problem out. > > > > > > > > I'll put a CMake build system in place on the documentation and make > > > > sure it works on Windows + Linux. OSX guys will have to help me in > > > > making sure it works there. It shouldn't be a problem though. > > > > > > > > > > > > > What does this cmake include? Does it reside in the kicad-doc repo or > > in the kicad repo? > > > > > CMake should be used as the build configuration tool which is used to > verify all of the required tools are installed on the system and > automatically generate the appropriate Makefiles. CMake files would go > in the kicad-doc repo and replace the current Makefiles. > > > > > > > So decide input and output formats and we can start implementing the > > > > CMake build system on the Github repo. > > > > > > > > Best Regards, > > > > > > > > Brian. > > > > > > Brian, > > > > > > Thank you for stepping up to write the CMake build system. This is what > > > I was looking for. I didn't want to start down that path without the > > > resources in place to get the work done. I would like to hear from the > > > auto builder folks to see what impact it will have on what they are > > > doing. I'll give asciidoc my official blessing (it seems funny to me > > > saying that) so we can get moving on it. The following tasks will need > > > to be completed before the stable release: > > > > > > - Set up repo on some git hosting sight. I heard some negative feedback > > > at FOSDEM about using github since apparently it is not free software so > > > I'm open to suggestion on this. If github is the best choice then I'm > > > OK using it but it might be worth exploring other git based hosting > > > alternatives. > > > > > > > > > Ohh well, it is just a git repo, where exactly it is located does not > > really matter IMHO. What matters is that pull requests are easy to > > perform, but I think it is no fault to put it on github for the > > forseeable future at least. We have the "official" libs there anyway, > > please don't do any unnessesary fragmentation of the project. By > > saying this, I don't want to close the discussion of alternative > > places. One is hosting it together with kicad-pcb.org > > (http://kicad-pcb.org) if ajo want to > > support and help maintain that. > > > > > > Sorry, I missed that part, I really believe externally provided solutions are going to be more reliable and work better. I prefer to spe
Re: [Kicad-developers] documentation format
On 2/4/2015 11:13 AM, Nick Østergaard wrote: > 2015-02-04 15:06 GMT+01:00 Wayne Stambaugh : >> On 2/4/2015 7:10 AM, Brian Sidebotham wrote: >>> On 4 February 2015 at 00:14, Wayne Stambaugh wrote: We need to make a decision soon if we want to get the documentation conversion completed in time for the next stable release. I'm still not sure we can build on Windows. Neither the MSYS2 asciidoc or sphinx implementations worked correctly the last time I tried them and I have no way to test any of this on OSX. Cygwin may work but the last time I tried to build kicad on cygwin, it was more trouble than it was worth. This would limit us to building the documentation only on linux which I'm not terribly thrilled about. This means if you wanted to build a windows installer you would have to run linux in a VM to build the documentation. That would be painful for our auto builders folks. If we get much further along, we may just have to live with the documentation we have now and convert to a plain text format for the next release. >>> >>> I think we're pretty much decided already on asciidoc - it just takes >>> someone to say so. I've included Marco on this email so perhaps he >>> could give us his up-to-date conclusion and we can make the decision >>> now. >>> >>> As for being able to build, well, we need to decide on an output >>> format. I think we've previously been hinting at html rather than PDF. >>> We don't need to support a million output formats. PDF is much harder >>> to support compared to HTML for example. > > I think HTML and PDF is what is required, I guess some people would > like epub, but that is basically not much different to HTML in > structure, hence I think that should look equally fine in HTML as in > epub. > >>> However, nothing requires a POSIX shell, so we definitely don't need >>> to add-in cygwin, MSYS2 or anything else as a dependency for building >>> docs. >>> >>> asciidoc works okay for me under windows, but a2x for PDF conversion >>> doesn't work. However, projects like asciidoctor-fopub and >>> asciidoctor-pdf are well underway to sort that problem out. >>> >>> I'll put a CMake build system in place on the documentation and make >>> sure it works on Windows + Linux. OSX guys will have to help me in >>> making sure it works there. It shouldn't be a problem though. > > What does this cmake include? Does it reside in the kicad-doc repo or > in the kicad repo? CMake should be used as the build configuration tool which is used to verify all of the required tools are installed on the system and automatically generate the appropriate Makefiles. CMake files would go in the kicad-doc repo and replace the current Makefiles. > >>> So decide input and output formats and we can start implementing the >>> CMake build system on the Github repo. >>> >>> Best Regards, >>> >>> Brian. >>> >> >> Brian, >> >> Thank you for stepping up to write the CMake build system. This is what >> I was looking for. I didn't want to start down that path without the >> resources in place to get the work done. I would like to hear from the >> auto builder folks to see what impact it will have on what they are >> doing. I'll give asciidoc my official blessing (it seems funny to me >> saying that) so we can get moving on it. The following tasks will need >> to be completed before the stable release: >> >> - Set up repo on some git hosting sight. I heard some negative feedback >> at FOSDEM about using github since apparently it is not free software so >> I'm open to suggestion on this. If github is the best choice then I'm >> OK using it but it might be worth exploring other git based hosting >> alternatives. > > Ohh well, it is just a git repo, where exactly it is located does not > really matter IMHO. What matters is that pull requests are easy to > perform, but I think it is no fault to put it on github for the > forseeable future at least. We have the "official" libs there anyway, > please don't do any unnessesary fragmentation of the project. By > saying this, I don't want to close the discussion of alternative > places. One is hosting it together with kicad-pcb.org if ajo want to > support and help maintain that. > >> - Convert all the existing documentation to asciidoc format. This >> includes any manual fixes due to incorrect translation. At some point I >> would also like to see the image file names changes to something >> meaningful rather than 1040001FB5B88EB2.png. This can >> be done as images are changed. > > I see Marco have done that with a few of the images. > >> - CMake configuration to check for all build dependencies, build all >> required output types, and handle translations. We will most likely >> have to support PDF output for the next release. I don't know if html >> help is supported in kicad. If it is, I'm open to the possibility of >> using html help instead of pdf. > > Even if PDF is us
Re: [Kicad-developers] documentation format
On Wednesday, 4 de February de 2015 at 15:06, Wayne Stambaugh wrote: > - Set up repo on some git hosting sight. I heard some negative feedback > at FOSDEM about using github since apparently it is not free software so > I'm open to suggestion on this. If github is the best choice then I'm > OK using it but it might be worth exploring other git based hosting > alternatives. > > I’m very positive about github, even if it’s not free software, they support very well lots of open source communities, and in the end it’s just git with a nice web interface, and a nice API. If something goes wrong git github is just a matter of pushing it somewhere else and repointing our git origins... We already depend on github for the online libraries, and we own a kicad project for that (btw, I believe dick was set as administrator, but not sure if you’re not, let me know if that’s the case as I have permissions). But of course, it’s worth exploring other alternatives (specially if they are free and open and we could eventually replicate them if something goes wrong about github). A plus of github is that it integrates very well with Jenkins to do Continuous Intregration, and checking pulls requests automatically. > > - Convert all the existing documentation to asciidoc format. This > includes any manual fixes due to incorrect translation. At some point I > would also like to see the image file names changes to something > meaningful rather than 1040001FB5B88EB2.png. This can > be done as images are changed. > > - CMake configuration to check for all build dependencies, build all > required output types, and handle translations. We will most likely > have to support PDF output for the next release. I don't know if html > help is supported in kicad. If it is, I'm open to the possibility of > using html help instead of pdf. > > > > Once the initial translation is complete and the repo is set up so > people can submit patches, I will make an announcement that the official > documentation has moved and see if I can configure the existing repo on > launchpad as read only so no one can commit changes. > > Cheers, > > Wayne > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > (mailto:kicad-developers@lists.launchpad.net) > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
2015-02-04 15:06 GMT+01:00 Wayne Stambaugh : > On 2/4/2015 7:10 AM, Brian Sidebotham wrote: >> On 4 February 2015 at 00:14, Wayne Stambaugh wrote: >>> We need to make a decision soon if we want to get the documentation >>> conversion completed in time for the next stable release. I'm still not >>> sure we can build on Windows. Neither the MSYS2 asciidoc or sphinx >>> implementations worked correctly the last time I tried them and I have >>> no way to test any of this on OSX. Cygwin may work but the last time I >>> tried to build kicad on cygwin, it was more trouble than it was worth. >>> This would limit us to building the documentation only on linux which >>> I'm not terribly thrilled about. This means if you wanted to build a >>> windows installer you would have to run linux in a VM to build the >>> documentation. That would be painful for our auto builders folks. If >>> we get much further along, we may just have to live with the >>> documentation we have now and convert to a plain text format for the >>> next release. >> >> I think we're pretty much decided already on asciidoc - it just takes >> someone to say so. I've included Marco on this email so perhaps he >> could give us his up-to-date conclusion and we can make the decision >> now. >> >> As for being able to build, well, we need to decide on an output >> format. I think we've previously been hinting at html rather than PDF. >> We don't need to support a million output formats. PDF is much harder >> to support compared to HTML for example. I think HTML and PDF is what is required, I guess some people would like epub, but that is basically not much different to HTML in structure, hence I think that should look equally fine in HTML as in epub. >> However, nothing requires a POSIX shell, so we definitely don't need >> to add-in cygwin, MSYS2 or anything else as a dependency for building >> docs. >> >> asciidoc works okay for me under windows, but a2x for PDF conversion >> doesn't work. However, projects like asciidoctor-fopub and >> asciidoctor-pdf are well underway to sort that problem out. >> >> I'll put a CMake build system in place on the documentation and make >> sure it works on Windows + Linux. OSX guys will have to help me in >> making sure it works there. It shouldn't be a problem though. What does this cmake include? Does it reside in the kicad-doc repo or in the kicad repo? >> So decide input and output formats and we can start implementing the >> CMake build system on the Github repo. >> >> Best Regards, >> >> Brian. >> > > Brian, > > Thank you for stepping up to write the CMake build system. This is what > I was looking for. I didn't want to start down that path without the > resources in place to get the work done. I would like to hear from the > auto builder folks to see what impact it will have on what they are > doing. I'll give asciidoc my official blessing (it seems funny to me > saying that) so we can get moving on it. The following tasks will need > to be completed before the stable release: > > - Set up repo on some git hosting sight. I heard some negative feedback > at FOSDEM about using github since apparently it is not free software so > I'm open to suggestion on this. If github is the best choice then I'm > OK using it but it might be worth exploring other git based hosting > alternatives. Ohh well, it is just a git repo, where exactly it is located does not really matter IMHO. What matters is that pull requests are easy to perform, but I think it is no fault to put it on github for the forseeable future at least. We have the "official" libs there anyway, please don't do any unnessesary fragmentation of the project. By saying this, I don't want to close the discussion of alternative places. One is hosting it together with kicad-pcb.org if ajo want to support and help maintain that. > - Convert all the existing documentation to asciidoc format. This > includes any manual fixes due to incorrect translation. At some point I > would also like to see the image file names changes to something > meaningful rather than 1040001FB5B88EB2.png. This can > be done as images are changed. I see Marco have done that with a few of the images. > - CMake configuration to check for all build dependencies, build all > required output types, and handle translations. We will most likely > have to support PDF output for the next release. I don't know if html > help is supported in kicad. If it is, I'm open to the possibility of > using html help instead of pdf. Even if PDF is used "inside" kicad, HTML is still nice when linking sections to people online. > Once the initial translation is complete and the repo is set up so > people can submit patches, I will make an announcement that the official > documentation has moved and see if I can configure the existing repo on > launchpad as read only so no one can commit changes. Well, the repo is already set up by Marco on github, https://github.com/ciampix
Re: [Kicad-developers] documentation format
On 2/4/2015 7:10 AM, Brian Sidebotham wrote: > On 4 February 2015 at 00:14, Wayne Stambaugh wrote: >> We need to make a decision soon if we want to get the documentation >> conversion completed in time for the next stable release. I'm still not >> sure we can build on Windows. Neither the MSYS2 asciidoc or sphinx >> implementations worked correctly the last time I tried them and I have >> no way to test any of this on OSX. Cygwin may work but the last time I >> tried to build kicad on cygwin, it was more trouble than it was worth. >> This would limit us to building the documentation only on linux which >> I'm not terribly thrilled about. This means if you wanted to build a >> windows installer you would have to run linux in a VM to build the >> documentation. That would be painful for our auto builders folks. If >> we get much further along, we may just have to live with the >> documentation we have now and convert to a plain text format for the >> next release. > > I think we're pretty much decided already on asciidoc - it just takes > someone to say so. I've included Marco on this email so perhaps he > could give us his up-to-date conclusion and we can make the decision > now. > > As for being able to build, well, we need to decide on an output > format. I think we've previously been hinting at html rather than PDF. > We don't need to support a million output formats. PDF is much harder > to support compared to HTML for example. > > However, nothing requires a POSIX shell, so we definitely don't need > to add-in cygwin, MSYS2 or anything else as a dependency for building > docs. > > asciidoc works okay for me under windows, but a2x for PDF conversion > doesn't work. However, projects like asciidoctor-fopub and > asciidoctor-pdf are well underway to sort that problem out. > > I'll put a CMake build system in place on the documentation and make > sure it works on Windows + Linux. OSX guys will have to help me in > making sure it works there. It shouldn't be a problem though. > > So decide input and output formats and we can start implementing the > CMake build system on the Github repo. > > Best Regards, > > Brian. > Brian, Thank you for stepping up to write the CMake build system. This is what I was looking for. I didn't want to start down that path without the resources in place to get the work done. I would like to hear from the auto builder folks to see what impact it will have on what they are doing. I'll give asciidoc my official blessing (it seems funny to me saying that) so we can get moving on it. The following tasks will need to be completed before the stable release: - Set up repo on some git hosting sight. I heard some negative feedback at FOSDEM about using github since apparently it is not free software so I'm open to suggestion on this. If github is the best choice then I'm OK using it but it might be worth exploring other git based hosting alternatives. - Convert all the existing documentation to asciidoc format. This includes any manual fixes due to incorrect translation. At some point I would also like to see the image file names changes to something meaningful rather than 1040001FB5B88EB2.png. This can be done as images are changed. - CMake configuration to check for all build dependencies, build all required output types, and handle translations. We will most likely have to support PDF output for the next release. I don't know if html help is supported in kicad. If it is, I'm open to the possibility of using html help instead of pdf. Once the initial translation is complete and the repo is set up so people can submit patches, I will make an announcement that the official documentation has moved and see if I can configure the existing repo on launchpad as read only so no one can commit changes. Cheers, Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
On Wed, Feb 04, 2015 at 12:10:25PM +, Brian Sidebotham wrote: > I think we're pretty much decided already on asciidoc - it just takes > someone to say so. I've included Marco on this email so perhaps he > could give us his up-to-date conclusion and we can make the decision > now. I'm pretty sure that asciidoc was the decided format, too! -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
On 4 February 2015 at 00:14, Wayne Stambaugh wrote: > We need to make a decision soon if we want to get the documentation > conversion completed in time for the next stable release. I'm still not > sure we can build on Windows. Neither the MSYS2 asciidoc or sphinx > implementations worked correctly the last time I tried them and I have > no way to test any of this on OSX. Cygwin may work but the last time I > tried to build kicad on cygwin, it was more trouble than it was worth. > This would limit us to building the documentation only on linux which > I'm not terribly thrilled about. This means if you wanted to build a > windows installer you would have to run linux in a VM to build the > documentation. That would be painful for our auto builders folks. If > we get much further along, we may just have to live with the > documentation we have now and convert to a plain text format for the > next release. I think we're pretty much decided already on asciidoc - it just takes someone to say so. I've included Marco on this email so perhaps he could give us his up-to-date conclusion and we can make the decision now. As for being able to build, well, we need to decide on an output format. I think we've previously been hinting at html rather than PDF. We don't need to support a million output formats. PDF is much harder to support compared to HTML for example. However, nothing requires a POSIX shell, so we definitely don't need to add-in cygwin, MSYS2 or anything else as a dependency for building docs. asciidoc works okay for me under windows, but a2x for PDF conversion doesn't work. However, projects like asciidoctor-fopub and asciidoctor-pdf are well underway to sort that problem out. I'll put a CMake build system in place on the documentation and make sure it works on Windows + Linux. OSX guys will have to help me in making sure it works there. It shouldn't be a problem though. So decide input and output formats and we can start implementing the CMake build system on the Github repo. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
And with the CI build, I mean, windows builders could just fetch documentation in rendered format from our build system, and then just package it. Miguel Ángel Ajo On Wednesday, 4 de February de 2015 at 13:02, Miguel Ángel Ajo wrote: > We currently have a CI build for the asciidocs, nickoe took care > of setting up the CI job. > > [2] http://ci.kicad-pcb.org/job/kicad-doc-testing/ws/src/asciidoc/KiCad/ > > Definitely, having a docker image should make it easier to replicate, > as setting up the job required a lot of dependencies to be manually > compiled (from a centos 6.5 point of view). > > > > Miguel Ángel Ajo > > > On Wednesday, 4 de February de 2015 at 06:42, John Beard wrote: > > > On Wed, 2015-02-04 at 01:31 +, John Beard wrote: > > > On Tue, 2015-02-03 at 19:14 -0500, Wayne Stambaugh wrote: > > > > > > I think the availability of tools on those platforms is actually not of > > > huge significance. The worst case is that the docs are built for every > > > commit by something like Jenkins, and the binary files are packaged for > > > the "bad" platforms, as well as put up online (any code or file host > > > would do) so you don't need to install KiCad to read the docs. > > > > > > > Here [1] is a pull request for Marco's docs repo, which adds a Docker > > build environment description. It's not very complex, but it means a > > Windows user or a Jenkins could build using Linux tooling. Also any > > Linux user can partition their working space so they don't need all the > > packages on their machine. > > > > This approach might also be useful for providing an easy-to-set up build > > environment for KiCad in general? > > > > Cheers, > > > > John > > > > [1] https://github.com/ciampix/kicad-doc/pull/7 > > > > > > > > > > ___ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : kicad-developers@lists.launchpad.net > > (mailto:kicad-developers@lists.launchpad.net) > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > > > > > > > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
We currently have a CI build for the asciidocs, nickoe took care of setting up the CI job. [2] http://ci.kicad-pcb.org/job/kicad-doc-testing/ws/src/asciidoc/KiCad/ Definitely, having a docker image should make it easier to replicate, as setting up the job required a lot of dependencies to be manually compiled (from a centos 6.5 point of view). Miguel Ángel Ajo On Wednesday, 4 de February de 2015 at 06:42, John Beard wrote: > On Wed, 2015-02-04 at 01:31 +, John Beard wrote: > > On Tue, 2015-02-03 at 19:14 -0500, Wayne Stambaugh wrote: > > > > I think the availability of tools on those platforms is actually not of > > huge significance. The worst case is that the docs are built for every > > commit by something like Jenkins, and the binary files are packaged for > > the "bad" platforms, as well as put up online (any code or file host > > would do) so you don't need to install KiCad to read the docs. > > > > Here [1] is a pull request for Marco's docs repo, which adds a Docker > build environment description. It's not very complex, but it means a > Windows user or a Jenkins could build using Linux tooling. Also any > Linux user can partition their working space so they don't need all the > packages on their machine. > > This approach might also be useful for providing an easy-to-set up build > environment for KiCad in general? > > Cheers, > > John > > [1] https://github.com/ciampix/kicad-doc/pull/7 > > > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > (mailto:kicad-developers@lists.launchpad.net) > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
On Wed, 2015-02-04 at 01:31 +, John Beard wrote: > On Tue, 2015-02-03 at 19:14 -0500, Wayne Stambaugh wrote: > > I think the availability of tools on those platforms is actually not of > huge significance. The worst case is that the docs are built for every > commit by something like Jenkins, and the binary files are packaged for > the "bad" platforms, as well as put up online (any code or file host > would do) so you don't need to install KiCad to read the docs. > Here [1] is a pull request for Marco's docs repo, which adds a Docker build environment description. It's not very complex, but it means a Windows user or a Jenkins could build using Linux tooling. Also any Linux user can partition their working space so they don't need all the packages on their machine. This approach might also be useful for providing an easy-to-set up build environment for KiCad in general? Cheers, John [1] https://github.com/ciampix/kicad-doc/pull/7 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
On Tue, 2015-02-03 at 19:14 -0500, Wayne Stambaugh wrote: > On 2/3/2015 6:55 PM, Cirilo Bernardo wrote: > > It has been some time since Marco has done an evaluation of document > > format alternatives. Has any decision been made yet about what format we > > shall use, or are there still some other alternatives which are being > > investigated? > > > > - Cirilo > > > We need to make a decision soon if we want to get the documentation > conversion completed in time for the next stable release. I'm still not > sure we can build on Windows. Neither the MSYS2 asciidoc or sphinx > implementations worked correctly the last time I tried them and I have > no way to test any of this on OSX. Cygwin may work but the last time I > tried to build kicad on cygwin, it was more trouble than it was worth. > This would limit us to building the documentation only on linux which > I'm not terribly thrilled about. This means if you wanted to build a > windows installer you would have to run linux in a VM to build the > documentation. That would be painful for our auto builders folks. If > we get much further along, we may just have to live with the > documentation we have now and convert to a plain text format for the > next release. I think the availability of tools on those platforms is actually not of huge significance. The worst case is that the docs are built for every commit by something like Jenkins, and the binary files are packaged for the "bad" platforms, as well as put up online (any code or file host would do) so you don't need to install KiCad to read the docs. However, I think that it is _extremely_ important to get the docs into a useful state ASAP. As it stands, they are not really usable because: * The initial download is several hundred of MBs (maybe GBs) due to the binary compressed data being stored - every change produces a whole new (zipped) ODT and PDF. A lightweight checkout is better, but you can't commit changes to a Bazaar lightweight checkout (other DVCS may allow it) * It's ugly, because it's in office software, and that always ends up with sqiffy documents because things get out of line, and so on * All the icons and common images are embedded in these binary blobs and therefore replicated thousands of times * Translation is impossible without rewriting the document from scratch, so divergence is inevitable * It's un-versionable, even if the ODTs weren't compressed, they are still extremely complex XML formats. This means you can't submit a change to it easily, all you see is binary diffs, and that's not a good way to manage changes, on a mailing list, Launchpad or elsewhere! All the above mean that the docs are falling into disrepair, and the talk of the new format means no one wants to do anything. I'd love to write some documentation, but I have to say, in the current state, I don't even know where to go, let alone want to do it 4 times in 4 formats. My vote is for asciidoc - it works and it's readable. Marco has done and is doing a great job of the conversion into three concurrent formats, but that will all start to go wrong if the originals start to change underfoot. The other factor in this decision is that it's not a disaster if a better option comes up later - asciidoc (and the other new formats) are all machine-parseable, that's the point. So they are designed to be convertible. The critical thing is to choose one, ASAP, and get people using it and work out a workflow that isn't "here's a new version of the whole file attached to an email, please commit, and no you can't see what I changed easily". No format will be perfect, so I think it's more important to get the bikes out of the rain than discuss the colour of the shed! If we get focus onto a single format, we are more likely to be able to find a solution. As I said the worst case for other platforms is what we have now, with an online binary depository of documentation that is kept up to date by others. Github, at least, can parse asciidoc and present it without even needing to compile[1], and there are also Firefox and Chrome plugins[2] that are (I think) platform independent. People can still write the (underlying, English) docs, even if they can't compile to every format. The translation can also be done without any special software, though the end result won't be compiled. Still, it's better than tabbing between two ODTs! Remember, if no one can contribute, it doesn't matter which platform they are using to not contribute! Cheers, John [1] https://github.com/ciampix/kicad-doc/blob/master/src/asciidoc/CvPcb/CvPcb.adoc [2] https://addons.mozilla.org/en-US/firefox/addon/asciidoctorjs-live-preview/ ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.n
Re: [Kicad-developers] documentation format
We need to make a decision soon if we want to get the documentation conversion completed in time for the next stable release. I'm still not sure we can build on Windows. Neither the MSYS2 asciidoc or sphinx implementations worked correctly the last time I tried them and I have no way to test any of this on OSX. Cygwin may work but the last time I tried to build kicad on cygwin, it was more trouble than it was worth. This would limit us to building the documentation only on linux which I'm not terribly thrilled about. This means if you wanted to build a windows installer you would have to run linux in a VM to build the documentation. That would be painful for our auto builders folks. If we get much further along, we may just have to live with the documentation we have now and convert to a plain text format for the next release. On 2/3/2015 6:55 PM, Cirilo Bernardo wrote: > It has been some time since Marco has done an evaluation of document > format alternatives. Has any decision been made yet about what format we > shall use, or are there still some other alternatives which are being > investigated? > > - Cirilo > > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] documentation format
It has been some time since Marco has done an evaluation of document format alternatives. Has any decision been made yet about what format we shall use, or are there still some other alternatives which are being investigated? - Cirilo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
