GDS Element Properties (PROPATTR/PROPVALUE)

GDSII lets any BOUNDARY, BOX, PATH, TEXT, SREF or AREF element carry arbitrary key/value metadata as a trailing PROPATTR/PROPVALUE pair — an integer attribute index plus an ASCII string, repeated as many times as the authoring tool likes, right before the element's ENDEL. Nothing in GDSII's own geometry model uses this channel, which is exactly why real files lean on it for things geometry can't say: a foundry's PDK-specific device tag, an LVS/schematic pin number, a dose-class annotation for a multi-pass e-beam job, a foundry's own internal part ID.

Before v0.137.0, opening such a file in Glyph and saving it back out silently dropped every one of those pairs — the geometry survived, the metadata didn't, and nothing said so. This guide is a straight answer to "will my properties still be there after I edit this in Glyph": what's kept, what isn't, and the honest boundary around a preserve-only feature with no editing UI.

Time: ~6 min. You'll need: nothing to download — this is a reference walkthrough of a round-trip behaviour, not a build-along. If you want to see it for yourself, any GDS file with PROPATTR/PROPVALUE records — from a PDK export, from KLayout's own property editor, or from another tool's device-tagging feature — will do.

What Glyph preserves, and how

Every property Glyph doesn't itself interpret is carried through byte-for-byte, in the order it arrived, duplicates included — GDSII allows more than one PROPATTR/PROPVALUE pair with the same attribute index on one element, and both the order and the duplication are spec-legal and significant, so Glyph doesn't dedupe or reorder them. This applies to every element type that can carry them: BOUNDARY, BOX, PATH, TEXT, SREF and AREF. properties is undefined on a Glyph-authored element that never carried any — the field only appears on elements that arrived with real data attached, so an ordinary drawn shape doesn't grow an empty array it has to drag around.

This is GDS → GDS only. Open a .gds with properties attached, edit the geometry around them, save it back to .gds, and the properties are still on the same elements, in the same order. Export that same document as OASIS, CIF, DXF, SVG or EPS, and the properties are gone — same as every other GDS-only field in Glyph's format comparison table (library name aside, none of GDSII's structural extras survive a lossy interchange format either). OASIS has its own, separate S_GDS_PROPERTY mechanism that carries a narrower set of things (text size, font, and PRESENTATION justification — see the next section) — that one does round-trip through Glyph's OASIS reader/writer, but it isn't the same channel as an arbitrary foreign GDS property, and the two shouldn't be conflated.

The attribute indices that don't mean what you'd expect

Two things are genuinely worth knowing before you rely on this for anything load-bearing:

• Attribute indices 124 and 125 are the two Glyph reserves for itself — they are ignored on import rather than preserved as foreign properties. GDSII already carries text size and justification in dedicated native records (MAG and PRESENTATION); these two attribute numbers only exist because a .gds that round-trips through OASIS (which has no such fields) comes back with the same information re-emitted as element properties on these indices. Glyph reads the native records as authoritative and skips 124/125 as redundant duplicates — no data is lost and no warning fires, but a foreign tool that happened to pick those two numbers for its own unrelated purpose would find them silently absent after a round trip (unlikely, but not impossible in a 16-bit index space nobody centrally allocates). Two nearby indices are conditionally consumed rather than reserved: 126 is read as a font-family name when it arrives on an element (with no element in scope it lands in the reported-loss bucket below), and 127 is consumed only inside Glyph's own internal font-manifest cell — on an ordinary element in a foreign file, a 127 property is preserved verbatim like any other.
• A property that arrives with no element in scope to carry it — before any element has opened, after one has already closed, or on a magic internal cell Glyph uses for its own font manifest — is genuine, reported data loss, not silent: Glyph's import warnings name the attribute index and the count, and state plainly that the metadata is not in the document and will not be written back. This is a different bucket from ordinary loss: a property that correctly attaches to an in-scope element is preserved and never warns at all, because there's nothing to warn about.

One more honest wrinkle, purely about file compatibility rather than data loss: GDSII strictly expects a property's PROPATTR/PROPVALUE pair to appear after the element's coordinate (XY) record. Some real files put it before instead — spec-legal but out of the field order KLayout enforces strictly enough to refuse such a file outright. Glyph reads it leniently either way and attaches the property correctly; if this happens, the import warnings say so, because it's the only signal you'd otherwise get that the file you just opened is more fragile against a stricter reader than it looks. Re-saving from Glyph always writes properties in the standard, after-XY position, so a round trip through Glyph alone fixes that fragility rather than propagating it.

The honest boundary: preserve-only

There is no editor UI in Glyph to view, add, or edit a foreign element's properties — no panel row, no dialog field, nothing in the Properties panel. If you need to inspect what a file actually carries, a tool built for it (KLayout's property editor, or gdstk/gdspy from a script) is the right instrument; Glyph's job here is narrowly to not lose the data while you edit the geometry around it, not to give you a second properties browser. That's a deliberate scope line, not a gap waiting to be filled by accident — every command that duplicates an element (cloneShape, cloneSref, cloneAref in Glyph's own undo/redo machinery) deep-copies its properties array explicitly, so a copy-paste or an undo/redo cycle keeps them attached to the right instance without ever surfacing them for editing.

Quick reference

Next steps

See the GDSII file format reference for where PROPATTR/PROPVALUE sit in the record catalogue, and Open and save GDS files for everything else Glyph's native round trip preserves — library name, cell order, timestamps. Export to your toolchain covers exactly what survives when you leave GDS for CIF, OASIS or DXF, property metadata included in that accounting. Then open the editor and open a PDK export with real device tags on it to see this for yourself.