Now I generated netlist file and there are not at least the following fields: TITLE_BLOCK.GetTitle() TITLE_BLOCK.GetComment1() TITLE_BLOCK.GetComment2() TITLE_BLOCK.GetComment3() TITLE_BLOCK.GetComment4() and so on. These fields and many other are necessary for GOST-doc-gen. All the necessary fields are easily accessible inside of KiCad eeschema. "And yes, using this approach is fully transparent to the user, once the comand line is initialized (see the netlist dialog). Only one click to generate the file. And the user does not know there is an intermediate file" And what is next? 1) A user clicked 2) the user does not know there is an intermediate file 3) and what is next? Where are the resultant GOST documents? "Yours cons are irrelevant: 1 - the guy has not even had a look to files in kicad (kicad/python) 2 - there is no setting (just a command line which could be predefined) 3 - intermediate file does not change as fast as the kicad internal code." 1,2 - explain, please, the whole picture in detail (from the click up to getting the resultant GOST documents). 3 - file formats of KiCad change quite often. In case of embedding GOST-doc-gen inside of eeschema sources, any changes in eeschema will be synchronously made in both the eeschema and GOST-doc-gen part. And it is transparent to a user because a user does not need to search for compatible GOST-doc-gen executible if such even exists. Taking the same benefit for pcad2kicad into a account I agreed with Wayne to transform standalone executable into pcad2kicad Pcbnew plugin. And I do not understand why you are so insisting on separating everything from KiCad. According to your logic, may be let us remove Gerber or VRML generation from Pcbnew? Because it is enough to have the external kicad_pcb file format? May be let us have external tools to generate Gerber and so on? By the way, where is pcad2kicadsch in the KiCad source tree? The whole year has already passed however pcad2kicadsch still lives as a separate project. And all this despite all your and the rest of KiCad admin caprices were satisfied! "About Russian literals, one time more, I am saying I am talking about internal Kicad code. Your patch come with not comments, and many sentences not readable for non Russian contributors It means this work cannot be modified and used by some other contributor which want mo modify the BOM to make their own BOM format. Each company has its BOM format, therefore GOST format is only one of multiple existing formats." Once more again, "Your patch come with not comments" is not the truth. There are comments but in not all places. I am going to add more comments. I doubt that adopting my work by other non Russian speaking contributors for countries which do not use the GOST makes sense. I mean the specific part of code which implements GOST requirements and contains Russian literals. I suggest you to compile KICAD_GOST version and take a look at generated forms (no source dependencies, only OpenOffice or LibreOffice needs to be installed). There is a sample circuit in demos (demos/GOST/multivibrator.sch). If you really thinks that such forms of documents can be adopted then no problem, I, of course, provide internationalization for the literals. At least I believe that OpenOffice/Libreoffice interaction approach I came to and I am using now can be leveraged. Moreover, I developed common document interface (COMMON_DOC_IFACE class) so it can help to implement other than GOST standards. Also I am implementing a component manager for eeschema-GOST-doc-gen making circuit variants possible. Indeed this component manager could be really not only for GOST-doc-gen (KICAD_GOST build) but for any user of official KiCad build as well. And now this component manager and the GOST-doc-gen core are as one whole entity inside of eeschema. And it is not possible to extract the component manager from eeschema and use an intermediate file for interaction. (Note: I have not yet uploaded sources of the component manager). "Creating code which cannot be understood by contributors is not the spirit of free open source software." What about people who does not know English? According to this logic most of open source software is not in the spirit. And once more, all my code is in English. Only some literals are in Russian. "Besides, the patch creates a heavy dependance of Kicad sources with openoffice/libreoffice sdk. This is a *major drawback*. This can be easily avoided by a fully external script." It's not the truth. Look at CMakeLists.txt: "option(KICAD_GOST "enable/disable building using GOST notation for multiple gates per package (default OFF)") option(USE_RPC_DOC_SERVER "enable/disable building GOST document generator using RPC document server (default ON)" ON) option(USE_OPENOFFICE_SDK "enable/disable building GOST document generator with use of OpenOffice/LibreOffice SDK (default OFF)") # USE_RPC_DOC_SERVER and USE_OPENOFFICE_SDK are suboptions of KICAD_GOST option. # These suboptions select an approach how to interact with OpenOffice / LibreOffice. # It is recommended to set the suboptions as follows: USE_RPC_DOC_SERVER=ON and USE_OPENOFFICE_SDK=OFF. # Other suboption combinations suffer from building and incompatibility issues. They are kept as spare approaches." During the development I passed through the next attempts: 1) OpenOffice SDK: can not build in Windows OS because OO SDK libraries are only for MSVC. I tried hard however I was not able to build KiCad by means of MSVC Toolkit 2003, MSVC 2008 and 2010. 2) embedded Python + odfpy: does not support named cell addressing and odfpy biases odt templates after saving back to odt file. 3) embedded Python + Python UNO: issues with embedded Python-to-OpenOffice/LibreOffice UNO libs incompatibility (an arbitrary KiCad build does not work with an arbitrary Office build because they are linked with different Python versions) 4) RPC document server: is the current implementation which is in use by default in KiCad RPC document server is my own term. This approach works as follows: 1) KiCad GOST-doc-gen starts some version of OpenOffice/LibreOffice in the listening mode. 2) KiCad GOST-doc-gen starts Python of the OpenOffice/LibreOffice and invokes uno_iface.py module (It is not embedded-into-KiCad Python interpreter. It is separate Python which is distributed with Office together and this separate Python is compatible with UNO libs from the Office ) 3) KiCad GOST-doc-gen connects to uno_iface.py via TCP connection 4) KiCad GOST-doc-gen sends commands to uno_iface.py saying what to do 5) uno_iface.py takes the commands and executes them through Python-UNO bridge 6) and there is the backward path for acknowledges The described scheme is totally free of any source dependencies and even of binary dependencies. Any version of KiCad should work with any version of OpenOffice/LibreOffice.