Use scaling to reduce file size

[jamesvitali]

In order to reducing the gds file size, so construct gds hierarchically with CellReferences, but it is still to big, so plus to use magnification parameter to reduce the amount of cell . Expect the size become smaller but the result is opposite.
Does it mean that it is not a good way to use the same block to create another block by multiplying its width with a number to make it smaller or larger?

with magnification and its size is around 4M ; however but without magnification parameter and its size is around 2.7M
Cell ("cell_span_5", 0 polygons, 0 paths, 0 labels, 9612 references)
Cell ("cell_span_6", 0 polygons, 0 paths, 0 labels, 9902 references)
Cell ("cell_span_7", 0 polygons, 0 paths, 0 labels, 7179 references)
Cell ("cell_span_8", 0 polygons, 0 paths, 0 labels, 7089 references)
Cell ("cell_span_9", 0 polygons, 0 paths, 0 labels, 2924 references)
Cell ("cell_span_11", 0 polygons, 0 paths, 0 labels, 3945 references)
Cell ("cell_span_13", 0 polygons, 0 paths, 0 labels, 5627 references)
Cell ("cell_span_17", 0 polygons, 0 paths, 0 labels, 4714 references)
Cell ("cell_span_19", 0 polygons, 0 paths, 0 labels, 3134 references)
Cell ("cell", 0 polygons, 0 paths, 0 labels, 54126 references)

[heitzmann]

Depending on the contents of the cell, a reference can be larger than a full copy. That's even more likely when a transform (magnification, reflection or rotation) are applyed, sin e they increase the size of the reference.

Without knowing exactly what the contents of tour cells are, it's hard to guess the best strategy.

For regularly displaced copies, cell arrays are the best option. Otherwise, the OASIS format, supported by gdstk, supports irregular arrays that should be able to greatly reduce the final file size, if you can use that.