X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Mon, 30 Apr 2018 19:45:54 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: [geda-user] [pcb-rnd] native file format doc available now Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: geda-user AT delorie DOT com Hi all, A few months back I got a request on this mailing list for "increasing the font size" (which was 0) of the file format specification for pcb-rnd's native, lihata based file formats. (I can't refernece to this mail unfortunately: I failed to search the mailing list archives. Web search engines don't index it, the mailing list archive site doesn't allow search that far into the past.) I've finished increasing the font size. It is certainly a convenient positive number by now. The pcb-rnd file format specification is accessible at: http://repo.hu/projects/pcb-rnd/developer/lihata_format/ The svg drawings are clickable. Please note: the document focuses on how the lihata document is structured. It does not explain lihata basics, because lihata has a file format spec already; it also doesn't explain how objects in pcb-rnd work, as the user documentation has a detailed data model description (both documents are linked from the above URL). So in a sense the above native format spec is rather boring: it's just a dry list of tree nodes, data types and short explanations on the payload encoding. It is also important to undestand the role of the native formats vs. alien formats. More on this topic: http://repo.hu/cgi-bin/pool.cgi?cmd=show&node=alien Specifically, about generating footprints and auto-editing boards (which is probably the main use case of such a file format spec). By now pcb-rnd supports a wide range of different file formats, loading kicad, eagle, protel/autotrax, gEDA/PCB boards and footprints. The user is free to use any of these formats - for example our stock parametric footprints are still generating the old gEDA/PCB element format, and the user doesn't see the difference (the generated footprints appear as subcircuits). Which demonstrates the user has the freedom to chose the format, and is not forced to use any specific format. However it is important to understand that the purpose of the native file format is to closely track the internal data model of the software. As our data model is very generic and flexible now, the native file format that can track it needs to be able to capture a lot of new details - and need to stay extensible for future improvements. Thus the lihata based file fromats are more verbose than some of the alien formats (e.g. gEDA/PCB's formats). The idea is: - If you want to generate or parse a footprint with minimal effort, you should use tEDAx - that format is specifically designed to be easy to parse or generate. The tradeoff is that it can not capture as many details as the lihata formats can - If you need something special, like proper padstacks, you will have to use lihata. The reason is that by now pcb-rnd's data model has much less restrictions and is more generic than most other EDA's we can import from. So using another format means accepting some arbitrary restrictions imposed by that format. Regards, Igor2