Mail Archives: geda-user/2018/04/30/13:41:47
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
- Raw text -