OrCAD / Allegro - Export via Skill

[juulsA]

Hello,

I used the interactive bom in a kicad-project first, but since I usually work with orcad / allegro, I thought it would be nice to get it working for these projects too. Then I saw, that 3 years ago, there was an approach parsing a text file exported from allegro, which was never accomplished ?! ... anyway I tried it another way and got it working from allegro itself ... and I got a few things working and with some things I need a little bit help.

1. Everything I draw, is mirrored on the x-axis and the angle of my arcs are wrong. Is that, because kicad has an inverted y-axis? I just want to know why this is happening and maybe there is a much more easier solution, than swapping the sign of my y-coordinates?!

2. If I select top & bottom in the html, my bom-table, containing the components, is empty, but for top or bottom only, I can see components and highlight them. If I want to see them in the combined view, do I have to add them to the "both" array of the "bom"?

3. Drawing and highlight the pins of each footprint is working, but the red bounding box is not where it should be ... it would be nice, if you could explain me these fields a little bit more in detail, because obviously, I have not understand correctly what they are for. What exactly is described by "center" and what is the difference to "pos" and why there is also a "relpos"? Are some of these values optional?

4. I haven't tried to write any text so far. Is it a good idea to use the "font_data" used in the demos or is there a point, where it can crash?

If you're interested in supporting an allegro export, I will share my code of course, but I need to get a bit further, before I want to share it.

Many thanks and best regards, Julian

[qu1ck]

Hello

1. Did you mean mirrored on y axis? Short answer is yes, that's why. Read the note on conventions at the top of DATAFORMAT.md doc.
2. Yes.
3. Footprints don't actually have "center" field, sorry about that mistake in the doc. You can think of bbox.pos as position of the footprint "anchor" point or "center". bbox.relpos will be offset of the top-left corner of the bounding box relative to that "center" after the coordinate system is rotated by -bbox.angle. One of them is optional in the way that you can make bbox.pos or bbox.relpos 0,0 if you do some coordinate translations. For more details you can check drawFootprint() in render.js.
4. You can use either svg rendering or stroke font rendering (font_data), it will not crash. Just don't include any allegro proprietary fonts in the source code, generating it from pcb data is fine.

I can't support allegro export if you were to share your code because I don't use it and don't have a license. But I am open to merging it if you agree to support it.

[juulsA]

Hi,

thanks for your quick reply; this should help me fixing it!

[juulsA]

Hi,

thanks for your quick reply; this should help me fixing it!

I'm able to create the correct board outline and the bounding boxes are in place as well! But there's a little bit work to do, to get each pin shape drawn correctly ... you'll hear from me soon!

[juulsA]

Hi again,

I wrote many lines of code and I also prepared the code for custom integration. The last issues I'm dealing with, is that I can print reference designators in a small design ( up to ~5 components), but in a larger design the html does not show any geometry or symbol ... the log shows the following message:

_"Uncaugt TypeError: pcbdata.fontdata[txt[i][j]] is undefined"

Is that, because I copied the whole font_data={ ... } from an example design? Unfortunetly I can't create the font_data by myself ... so I need a default ...

Do you know, what has to be done to get is working?

Thanks for your help!

[qu1ck]

ibom only includes character data for characters that are actually used in the design. So if for example there is no '%' character anywhere on the board it will not be included to save space.

Look at FontParser class and how it's used in kicad.py, you should be able to easily reuse it.

[juulsA]

ok, this sounds reasonable ... meanwhile I found a way to extract the text as polygons, but - as you said - the file is getting big and it also doesn't look nice at the moment ... so I'll take a look at the FontParser

[juulsA]

I could create the font data via the FontParser, but I had some trouble with the characters \ " ' % ... they cause the html rendering to fail (.. expected : or unclosed ) ... ), therefore I excluded them in the data and replaced occurrences in the design with a whitespace. I don't know, if I did something wrong ... or maybe the characters are not escaped correctly ... ?! Anyway, I don't need these characters!

[juulsA]

I can export a json file and generate an interactive bom now, but there are a few things, that don't work and I don't understand:

1. I currently don't use the svgpath, but I use the parameters start, radius ... instead, but - as described - these parameters are ignored, if the svgpath is present. When I skip the svgpath, I get the following error :

File "...\InteractiveHtmlBom-master\InteractiveHtmlBom\ecad\common.py", line 104, in add_svgpath bbox.add_svgpath(drawing['svgpath'], width, self.logger) KeyError: 'svgpath'

Do I have to use the svgpath?

2. I have added data to the fabrication layer, but isn't displayed ( maybe the silkscreen data wouldn't be displayed either, but there is none ) ... I don't see what's wrong

I have already compared it to the schema, but I can't see, what's wrong ...

Below I have attached the generated data (of a useless test design, as I can't share any other designs): in the bom folder, there is the interactive bom generated by the json parser and the ibomtest.html is the data created by my code ( to see what is missing on the fabrication layer ).

Maybe anyone can see what I am doing wrong ... thanks!

Edit: It seems there is no font_data in the pcbdata ... this may be the reason, why the fabrication layer can't be displayed ... did I forgot to check anything in the config panel?!

bom.zip

[Funkenjaeger]

font_data has consistently been a challenge for implementing non-KiCAD parsers. It's not currently supported by the genericjson parser, because when I wrote the parser I was working with Eagle/Fusion 360, from which no font data is available, so I wasn't in a position to integrate or test it. Admittedly that's a gap (in both the parser and the schema), and support for font_data should be added as soon as there's a use case where such data is available.

It raises the question though - DO you have font data available, in order to populate a font_data object in the JSON in accordance with the pcbdata struct definition? Or are you expecting the parser to generate the font_data for you, using ibom's built-in font parser?
The trouble with the latter is that it will use KiCAD's font, which won't match the font from another EDA tool (and KiCAD apparently has some unique handling of special characters that you'd have to watch out for). That's the problem that I ran into when I more recently wrote the direct Eagle/Fusion 360 parser. Ultimately I compromised: I process reference designators using ibom's font parser, and omit all other text from the board.

I'm open to helping integrate font support into the genericjson parser if we can agree on how it should work.

[Funkenjaeger]

1. I currently don't use the svgpath, but I use the parameters start, radius ... instead, but - as described - these parameters are ignored, if the svgpath is present. When I skip the svgpath, I get the following error :

This is a bug in common.py, I'll work a fix.

[Funkenjaeger]

1. I currently don't use the svgpath, but I use the parameters start, radius ... instead, but - as described - these parameters are ignored, if the svgpath is present. When I skip the svgpath, I get the following error :

This is a bug in common.py, I'll work a fix.

Addressed in #342. I can expand the scope of the PR to include any other changes/fixes if desired, such as the font handling issue if we decide on a path forward.

As a test, I edited your JSON to remove all the fab data (so as not to run into the font handling issue) and removed the empty svgpath field entry from your one arc drawing object, and ibom runs without errors and handles your arc:

[juulsA]

Thanks for your fast reply! I don't know, if I got you right ... do you meant font_data, which can be extracted from allegro or in general, if I am able to populate the font_data?

I also can't extract the font_data (except as a polygon for each string, which looked terrible at this point), so I would expect the parser to generate the font_data ... but I'm more a hardware developer than I can write software ... so I'm really not sure about what is the best way to do this.

In my first approach, I was building the whole html in allegro itself and didn't made use of the python code, so I generated the font_data myself ( for all ascii signs ) using the ibom's font parser regardless, if the character is needed or not and included it ... which - I admit - isn't the fanciest way to do this.

What happens, if I add the font_data to the json file and convert it? Is it added to the pcbdata in the html or is this the point we are talking about, that needs to be implemented? Sorry for my confusion ...

[Funkenjaeger]

I also can't extract the font_data (except as a polygon for each string, which looked terrible at this point) That sounds similar to the situation I faced with Eagle. Within Eagle's script environment, I was able to access all the individual strokes (e.g. segments, arcs) making up every individual character of all the text appearing on the board. I didn't have access to the underlying font, and the font in Eagle isn't monospaced so simply having a set of strokes for each possible character wouldn't be adequate (e.g. wouldn't reflect kerning rules, etc) so I didn't use any text drawing objects at all, and therefore didn't need font_data at all. Instead I simply iterated through all of the strokes for all of the text and added each individual stroke as a drawing object (e.g. segment, arc) to the silkscreen and/or fab layers. As such, the ibom font parser isn't used at all and the silkscreen text on my board does faithfully reflect what's in the original Eagle board design.

If you're able to do the same thing in Allegro, that is probably the solution that would give the best results.

I wasn't able to do the same in my direct Eagle parser which I mentioned above, because the strokes for the text aren't available outside of Eagle's internal script environment.

I think what I would propose for ibom changes is the following:

• update genericjson parser to use font_data (i.e. include it in the resulting pcbdata object) if it has been provided in the JSON
• update json schema to reflect font_data (still optional, but validate it if it is there)
• update genericjson parser to use the ibom font parser if font_data hasn't been provided in the JSON - if and only if the user has requested it via some flag (either metadata in the JSON file, or a new command-line argument)
• if font_data hasn't been provided in the JSON and no 'parse fonts' flag was given, then no font_data will be generated and all text drawing objects will simply be skipped (so they don't cause errors downstream in the HTML/JS)

my feeling is that using the ibom font parser (which will generate fonts that don't match the original board from a non-KiCAD EDA tool) isn't a good default behavior, but ought to be reasonable if the user deliberately asks for it. I think I sort of prefer the metadata flag over a command-line argument, because then you can make that decision upstream in your JSON-generating code and it avoids adding a parser-specific command-line argument.

I'd like @qu1ck 's opinion before I go committing anything...

[qu1ck]

I think what I would propose for ibom changes is the following:

I agree with all of those except there is no need for explicit flag. The way I see it parser developers have 4 choices in order from best to worst user experience:

1. Add all text as polygons using svgpath. This allows exact text rendering respecting all original formatting.
2. Add all text and supply custom font_data. This allows exact character rendering, assuming it was in a hershey font originally. But it will break any special formatting like overbars etc. In fact because text rendering in ibom frontend uses kicad logic (unless it's svg) this may give some unexpected results because it uses kicad specific escaping.
3. Add only critical text like references and don't supply font_data, let ibom use kicad's font data. It's better than no text at all and is close enough for short texts like refdes.
4. No text at all

The explicit flag for "parse fonts" is not needed because result of it disabled is equivalent to option 4 in which case parser should not output text items at all.

I would not object to a flag that disables kicad specific tricks to minimize surprises for option 2 and 3.

I think @juulsA indicated that they want to go for option 3 and it is fine by me. But

I also can't extract the font_data (except as a polygon for each string, which looked terrible at this point)

Do you mean it looked terrible when rendered in ibom? Because if it's for developer reasons or output size reasons then I encourage you to go with svg route, that's what kicad uses since v6 as well. But if you can't make it render correctly then yeah other options are possibly better.

[Funkenjaeger]

Fair point - no flag required because the upstream tool should control what information it includes in the JSON.

I'll get working on the changes. I'll have to take a look at the kicad-specific tricks - beyond knowing that they exist, I'm not familiar with them or the code that handles them, since I've yet to run into any such surprises while sticking to options 1 and 3 myself.

[qu1ck]

I'll have to take a look at the kicad-specific tricks - beyond knowing that they exist, I'm not familiar with them or the code that handles them

See https://github.com/openscopeproject/InteractiveHtmlBom/blob/883d0f2dabd5038b0f914697973e8634769b7365/InteractiveHtmlBom/web/render.js#L39

There's overbar handling, tab alignment, justification, even minor coordinate shift depending on thickness. All kinds of little oddities.

V6 introduced even more stuff like super/underscript and v7 has even more formatting so I switched to polygon or svgpath based rendering.

[Funkenjaeger]

Still working #342, but case 3 (use ibom's font parser) is now implemented:

Still todo is case 2, handling kicad-specific stuff, error checking, etc.

[juulsA]

Sorry for my late reply ...

Do you mean it looked terrible when rendered in ibom? Because if it's for developer reasons or output size reasons then I encourage you to go with svg route, that's what kicad uses since v6 as well. But if you can't make it render correctly then yeah other options are possibly better.

The text was crossing itself or for example a zero was filled ... a picture would say more than 1000 words, but at the moment I have no access to my allegro installation, so I can't show what it looked like ... but this is something, I think, I could fix.

Still working #342, but case 3 (use ibom's font parser) is now implemented:

Very nice! Thank you so far!

[juulsA]

What just came to my mind ...

In allegro you can't specify different fonts, you only can specify the width, height, linewidth ... and so on ... the newstroke font looks very similar to the allegro's default font, but of course it's not exactly the same ...

Also I think it would be possible to export the text as polygons, I'm not sure, if the effort is in relation to the result, just because of some minor differences ... but this, of course, only affects allegro pcb exports ...

[Funkenjaeger]

Alright, I think I've covered everything most of it, except anything pertaining to kicad-specific escaping. I can look into that soon.

Attached are sample JSON files which test cases 1 through 4, as well as a defective file for case 2 which includes partial/incomplete font data which triggers the error checking I added. bom.zip

[juulsA]

Do you mean it looked terrible when rendered in ibom? Because if it's for developer reasons or output size reasons then I encourage you to go with svg route, that's what kicad uses since v6 as well. But if you can't make it render correctly then yeah other options are possibly better.

for the sake of completeness ... that's how it looked like when I tried to render the text as polygons ... for some reasons I'm not allowed to upload .png directly, so you have to look inside the .zip ... sorry for that!

text_as _poly.zip

[juulsA]

@Funkenjaeger I have just tried your modified code on a design with more than 2000 components and it works and looks great ... I wish I could show you the result ... the only thing is, that I'm getting an error

Failed to parse file ... cannot unpack non-iterable NoneType object

but the export continues successful! In the attached example the same error occurs ... any clue whats wrong? I only remove the lines adding the empty svgpath

pcbData.zip

[Funkenjaeger]

In the attached example the same error occurs ... any clue whats wrong? I only remove the lines adding the empty svgpath

I'm not able to reproduce the error you describe. The json file you provided parses successfully for me and no errors are indicated. In fact, it's identical to the test file I previously shared with the "_nofontdata" suffix, except for 3 strings in the metadata.

[Funkenjaeger]

I'm working on bypassing the kicad-specific logic, and one part of that is the tab-to-space conversion.

Trying to decide whether I should escape control characters (e.g. \t to \\t) so they get printed literally, or leave the tab logic as-is so it gets converted to 4 spaces (which probably wouldn't match the tab spacing in an arbitrary EDA tool) - or perhaps just drop control characters from text strings entirely.

Thinking about it a little bit more, I think that leaving the tab-to-space as-is is too presumptuous of an arbitrary EDA tool's intent... So of the other two options (escape vs. strip) I'm sort of inclined to just strip control characters rather than mess with escaping escape characters and such - and just document the behavior accordingly. I could be convinced either way though.

Thoughts?

[juulsA]

Is there any case, where the text is not a reference designator or a value? Maybe I'm beeing too uncreative - but I can't imagine of using tab in both cases ...

[Funkenjaeger]

Yeah, I don't know either, I'm at least a little surprised that kicad uses tab to begin with.

Anyway, I made the changes to just strip all control characters from text (including tabs), as well as bypassing the kicad-specific overbar handling using a flag that only the genericjson parser sets (not a command-line argument)

[qu1ck]

Example of tab usage in KiCad: if you put this text in with left justification:

Vcc\tGND
Tx\tRx

(\t are actual tab chars) Then it will look like this (frame added later):

Easier than adding 4 separate labels. Much easier than adding 40 as legend for big headers.

Here's another example of a design that uses text liberally: https://kitspace.org/interactive_bom/?github.com/joeycastillo/The-Open-Book/Open-Book-Abridged

Dropping control characters for generic json parser seems reasonable.

[Funkenjaeger]

Here's another example of a design that uses text liberally

Seems a bit ironic to use ibom on a board that's absolutely plastered with full instructions on both sides :)

[juulsA]

Here's another example of a design that uses text liberally: https://kitspace.org/interactive_bom/?github.com/joeycastillo/The-Open-Book/Open-Book-Abridged

Apparently I'm too uncreative ...

I've decided to waive the html generation with allegro completely and I'm using the interactive bom as it is intended to use instead ... I added some support for bom variants used in allegro ( each variant, a separate file ) and I've finally uploaded my code to github, which worked for all my test cases.

[juulsA]

I did some testing with some eval board design, such as the HW_U1_KCU1500_REV1.0_01_05162017, MCIMX8M-EVKB and the AD-FMComms3_revA ... all of them could be exported and converted to an ibom without any errors.

Since the AD-FMComms3_revA can be downloaded from analog devices directly, I used it as an example design and added it to my repository.

Is there anything else I should test or do? Otherwise I close this issue?!

[qu1ck]

I looked at the example and it looks good.

Maybe couple things you can look into:

• Text sizes seem kinda large. Is that close to actual size or maybe they need to be scaled a bit? Some fab texts seem very thin too, maybe as expected.
• TP246 bounding box is a lot bigger than others for some reason?
• There is net information but no tracks/zone. Is that not supported or just not enabled?

I will add your project to the wiki and mention Allegro support in readme as soon as I merge Funkenjaeger's changes. Just didn't have a chance to review the latest commits yet.

[juulsA]

Thanks for the hints ....

Text sizes seem kinda large. Is that close to actual size or maybe they need to be scaled a bit? Some fab texts seem very thin too, maybe as expected.

The text matches to the design. I think the one, who made the layout, doesn't spend much time on the text ... See the attached file ... ( sorry for the .zip, again ... obviously the direct file upload is blocked for some reason ... )

ad-fmcomms3.zip

TP246 bounding box is a lot bigger than others for some reason?

I think, this is because, there is no boundary defined for this symbol ( don't ask me why, but the other two have a boundary, this one doesn't ) ... if that's the case, I take the component's extents as the boundary. This includes everything related to the component ( refdes, value, silkscreen, ... )

When I replace the testpoint with the footprint of the others above, it seems to be correct. So I would blame this on the design.

tp246.zip

There is net information but no tracks/zone. Is that not supported or just not enabled?

I forgot to mention ... At the moment, this is not supported, but I have this on my plan, so maybe we keep this issue open until I added the track/zone support.

[qu1ck]

I think, this is because, there is no boundary defined for this symbol ( don't ask me why, but the other two have a boundary, this one doesn't ) ... if that's the case, I take the component's extents as the boundary. This includes everything related to the component ( refdes, value, silkscreen, ... )

I suggest only taking graphical items and pads into account in such case, not text. In most cases it results in much more accurate bbox. It is still strange that TP245 just above it is fine but TP246 isn't but ¯\_(ツ)_/¯

At the moment, this is not supported, but I have this on my plan, so maybe we keep this issue open until I added the track/zone support.

Sounds good.

[juulsA]

I suggest only taking graphical items and pads into account in such case, not text. In most cases it results in much more accurate bbox.

I will look into that after I've added the track / zones ... I chose this way, because this made it much easier, otherwise I had to do some additional filtering ... but I see your point ...

It is still strange that TP245 just above it is fine but TP246 isn't but ¯_(ツ)_/¯

I think the designer deleted the boundary by mistake, but if you create your symbols properly you won't have issues like that.

Anyway, I'm glad I could already handle the tracks as you can see in the attached example.

AD-FMComms3_revA.zip

[juulsA]

I need some help / information about how the zones are drawn: is there a way to create voids?

poly_voids.zip

As you can see in the attached image, the darker red shows the areas, which need to be a void.

[qu1ck]

You mean holes?

There are 2 ways: How KiCad does it: polygon fracturing. It connects a vertex of a hole outline to outer shell of the polygon. Here's a screenshot of a small zone with a cutout in gerber viewer that illustrates the idea. Note the connecting edge in top left. This can be a bit tricky geometry if you have to implement it yourself but the simple approach is to do this:

1. find the right most hole in the polygon
2. issue a ray in positive x axis direction from the right most vertex of that hole, find where it intersects the outer shell of the polygon
3. break the outer shell, connect it with an edge to the vertex you issued the ray from and connect it back to the shell thus combining two outlines
4. repeat until there are no more holes in the end you will have one fractured outline

2nd approach is the way EasyEDA does it. Generate svg path and let the browser handle holes for you using fill rules. Ibom currently uses the default nonzero rule so you have to be careful of the winding order of the holes and outlines. But it would be easy to pass even-odd param if that is easier to generate.

[juulsA]

Yes, that's what I meant.

I think the most "easiest" way ( for me ) is the 2nd approach, but I'm not familiar with the svg paths yet ... let's see, if I can do that.

Thanks for your help again!

[juulsA]

But it would be easy to pass even-odd param if that is easier to generate.

If I got it right, it would be much easier to use the even-odd param. But where does this parameter need to be passed? The fill rule is not inside the svg path or am I wrong?

[qu1ck]

Yes, it's not part of the path. We need to extend the json schema with an optional parameter "fillrule" for Zone object and the renderer needs to use it if it's defined. Relevant bits: https://github.com/openscopeproject/InteractiveHtmlBom/blob/ae27915f08a3f06ba4dc0a8360a181b96c442a8a/InteractiveHtmlBom/ecad/schema/genericjsonpcbdata_v1.schema#L567 https://github.com/openscopeproject/InteractiveHtmlBom/blob/ae27915f08a3f06ba4dc0a8360a181b96c442a8a/InteractiveHtmlBom/web/render.js#L443

[juulsA]

Ok, then I'll try to generate the zones as svgpaths first and maybe I'll find an easy way to implement it for the even-odd fill rule ... if not, I would appreciate, if we could extend the json schema.

[qu1ck]

Do whichever is easier for you, I can extend the schema, it's just a few lines.

[juulsA]

... then let us please extent the schema ... it doesn't look so bad, but there is something happening I don't understand ...

The voids or holes need to be part of each svgpath containing the outer boundary starting with M .... ?! as in my example?!

AD-FMComms3_revA.zip

[qu1ck]

In your example I see some glitches related to arcs. But it's too complex to look at data. I suspect you are also not closing paths before moving to holes.

See https://www.w3.org/TR/SVG11/paths.html#PathDataClosePathCommand

You should complete each outline (including outer shell) with Z and then do M to new hole. Note that subpath completion is always a straight line so it's best to add extra vertex at the end of each outline that is same as the start of the outline if straight line is not desired.

[juulsA]

Yes, there was no whitespace between the last coordinate and the Z. The paths should now be closed properly and I had also some mistake in setting the large-arc-flag as well as with the circles ...

I've exported the json and ibom, where the actual zones are the voids / holes ( just for checking, if they are drawn correctly ):

AD-FMComms3_revA_voids.zip

and this one containes both ( copper / voids ), but because both areas overlap, you can't see the voids:

AD-FMComms3_revA_copper.zip

Is there a way I can check, if the second dataset yields the correct result? ... by changing some lines in the html ( or wherever ) ?

[qu1ck]

I just pushed fillrule param support. You should be able to pass "evenodd" now.

[juulsA]

Thank you! As a short feedback: this seems to be working now ... I'll share some results later!

[juulsA]

I updated my code and my example ... I was just suprised, that there were some vias and tracks, that weren't included in the json. The explanation is, that these are some Dummy nets, which is a not connected net. These nets are not part of the net list, I retrieve from allegro, so I can't include them ... I hope this is fine for everyone ...

I still have some other questions about the variant handling ... I saw, that there are the placed checkboxes and also a DNP outlined option, but I don't really know how to handle them ... at the moment I just exclude a symbol, if it is not in the bom variant, but of course, the rendered pcb is not correct and doesn't look nice ... any suggestion how I should handle this?

[qu1ck]

These nets are not part of the net list, I retrieve from allegro, so I can't include them ... I hope this is fine for everyone ...

There should be a way to get all copper items, connected or not. Ideally the board on render looks exactly like in reality. But the example looks very good to me, it's entirely up to you if you want to figure out missing tracks and vias.

I saw, that there are the placed checkboxes

This is entirely end user (i.e. the one viewing html) focused feature. Intention is to mark components during assembly process. Or during component acquisition, or anything else, checkboxes are user configurable in html.

DNP outlined option

This one makes pads of components that ibom considers DNP to be rendered in outline mode. Which components ibom considers DNP is based on the pcbdata.bom.skipped field in DATAFORMAT. The whole pcbdata.bom field is generated by ibom itself, you can't influence it directly by contents of json because json is supposed to be raw data representing pcb and bom table is generated based on user's choices in config dialog. Things like which fields to show/group and which components are whitelisted, which ones are considered virtual, dnp field and also the variant field.

There are many ways to force component to be skipped. Search for "blacklist" here https://github.com/openscopeproject/InteractiveHtmlBom/wiki/Usage If you want variant system you should add extra fields to component structure with corresponding data. If you want opt-out DNP status you can set "attr" field of the component to "Virtual". If you want opt-in status then add a "DNP" extra field and set it accordingly.

[juulsA]

There should be a way to get all copper items, connected or not. Ideally the board on render looks exactly like in reality.

Yes, and I wasn't happy with just skipping those elements either ... but I found a solution! So now you can see the no-net elements in my example.

Moreover I added DNP as an extra_field to use the DNP outlined option and I added an additional option to exclude all texts of dnp-components ( refdes, value ), so there's just the outline left.

dnp_no_text.zip

Because not everyone expects or likes this behavior, the default includes all texts.

There are currently no open items from my side, so I think we can close this ( for now )!?

[qu1ck]

Well you could export custom fields too, if there is such a thing in allegro. Otherwise this is pretty much full featured support.