PDF Export does not peserve Drawing Order

[mme1950]

The entities inside a BlockRecord and the SortEntitiesTable were cloned from a template drawing.

Entities received new entity handles. The so-called sort handles inside the SortEntitiesTable still contain the old values from the template (original entity handles). We assumed that the sort handles are arbitrary integers that define the draw order.

In AutoCAD the draw order appears correct.
When I export a drawing that contains blocks with a SortEntitiesTable to PDF from AutoCAD, the draw order is sometimes incorrect.

[mme1950]

Question to ChatGPT

What happens during the PDF export? Why is the draw order being destroyed?
Is it possible that the PDF (or ODF) exporter explodes the blocks and then must rebuild the draw‑order table?
Does it matter that the Sort Handles no longer match the entity handles after cloning?

---

💬 Answer

There are no official Autodesk sources that fully document this internal mechanism, but the behavior can be reliably inferred from:

• ObjectARX documentation
• Observed runtime behavior
• Reproducible test cases
• Autodesk forum statements

The following explanation summarizes what is known.

---

✔️ 1. AutoCAD uses the SortEntitiesTable only inside the BlockTableRecord.

As long as you are editing or viewing the block inside AutoCAD, the SortEntitiesTable determines the draw order correctly — even if the Sort Handles no longer correspond to the actual entity handles after cloning.
AutoCAD does not require the Sort Handles to match the entity handles, as long as the table’s relative order remains consistent.

---

✔️ 2. During PDF export AutoCAD explodes all BlockReferences.

The exporter flattens the drawing:

• BlockReferences are expanded into their contents
• Everything becomes part of a single global entity list
• A global draw order must be reconstructed

At this stage, the original SortEntitiesTable is no longer directly usable.

---

✔️ 3. If Sort Handles no longer match the cloned entity handles, AutoCAD cannot map them.

When the Sort Handles contain outdated values (e.g., still holding the original handles from the template drawing), AutoCAD cannot associate them with the new entities.

In this case the PDF exporter falls back to alternative ordering:

• entity handle order
• creation/insertion order
• sometimes object type grouping

This results in a different draw order in the exported PDF.

---

✔️ 4. This behavior is reproducible.

• Original block + valid SortEntitiesTable → PDF correct
• Cloned block with outdated Sort Handles → PDF incorrect
• Rebuilt SortEntitiesTable with new stable values → PDF correct again

This strongly suggests that the PDF exporter expects Sort Handles to be valid identifiers for the actual entities.

---

📌 Conclusion

Yes — it matters when Sort Handles no longer match the current entity handles after cloning.
During PDF export AutoCAD reconstructs the unified draw order after exploding blocks.
If Sort Handles cannot be mapped to actual entities, the export process produces an incorrect draw order.

Fix:
After cloning, rebuild the SortEntitiesTable and assign fresh, unique, consistent Sort Handles.

[mme1950]

Hi @DomCR,

I hope the conclusion of ChatGPT is reliable, at least ChatGPT had read much more information than I did.

Maybe it helps when we map sort handles from the original handle-like values to the new handles of the cloned bloc-record handles.

This may be difficult when a sort handle does not refer to to an entity because this entity was removed from the block.

[DomCR]

Hi @mme1950,

The info from ChatGpt makes some sense, I guess that we can test it by ourselves, the problem that I see here is the loss of information during the cloning, when all the handles take the 0 value.

I think that to fix this instead of focusing on the handles, which they will be reset or changed, it would be more useful to create active relationships between the entities that "swap" places during the drawing order. If that relationship is kept during the cloning, it will take effect regarding the handle that has assigned.

The problem with this approach is the complexity, it need to keep track fo the added/removed entities, create the relationship when the table is build and keep it when it's cloned or changed.

[mme1950]

Conclusion(?):
At least temporarily we should create an entity-entity relation table. The "left" entity represents the sort handle, the "right" entity is the entity of the block to be sorted.

If the sort handle cannot be resolved to an entity the "left" entity must default to the next or previous entity depending on ?

[mme1950]

Hi @DomCR,

what do think of this approach for BlockRecord.Clone()
If a SortEntitiesTable exists:

• Create a complete list of sorters with the original entity handles, (existing sorter entries + additional sorter entries for entities missing in the SortEntitiesTable (entity, entity.Handle).
• Sort this list and get a sorted list of entities
• Use the sorted list of entities instad of the original entities list to clone the entities.
• Build a new SortEntitiesTable with sorters(entity, 0)
• Replace 0-SortHandles in AssignDoument by actual entity handles.

It may also be valid to remove the SortEntitiesTable.

I applied this procedure when I clone the entities of a dynamic-block state into a new block record. This seems to work well.
The drawing seems to be OK in PDF.

[mme1950]

This works well in the Clone -> AssignDocument process.

In SortEntitiesTable.AssignDocument the Sorter entries have to be updated. SortHandle is set to entity.Handle.

The UnassignDocument process requires some attention.
When the BlockRecord and the SortEntitiesTable were modified the entities of the BlockRecord must be reordered explicitly and the FULL SortEntitiesTable with 0-SortHandles must be created.

[mme1950]

Hi @DomCR,

we found, that the sort handles can be arbitrary integers to define a draw order for AutoCAD.
But we learned that for the export as PDF the sort handles must be values that are in the range of the handles of the entities of the block record. I do not know whether the handles must be resolvable to entities.

We found out that

• the SortEntitiesTable does not necessarity contains entries for each entity.
• the SortEntityTable may contain entries with sort handles that do not resolve to an entity.
• if the sort order defined by a SortEntityTable with "strange" sort handles is changed AutoCAD rebuilds the SortEntitiesTable with resovable sort handles.

Conclusion:

• Probably a SortEntitiesTable must have resovable sort handles representing handles of the entities of the block record.
• The BlockRecord.Clone() - AssignDocument process must create a SortEntitiesTable that conforms to this requirement.
• The SortEntitiesTable with (entity, sort handle) entries cannot be set up as long no valid handles exist.
• Since the values of the sort handles are crucial, methods to create and change the drawing order should be used
  • InitializeSortEntitiesTable(IList<Entity> entities)
  • MoveToBottom(Entity entity)
  • MoveToTop(Entity entity)
  • OneStepUp(Entity entity)
  • OneStepDown(Entity entity)

Solution Scenarios:
Represent the sort entries as entity-entity associations

• entity-entity entries must be built in the template.Build method.
  This requires special logic in case the existing table has unresolvable sort handles.
• The drawing order can be changed by modifying the SortEntityTable, also when the BlockRecord is not associated with a document.
• The writeSortEntitiesTable method must be changed.

BlockRecord.Clone() creates a block record with explicitly ordered entities

• The definition of the sort entries (entity, sortHandle) is kept. It can be read and written as it is.
• In the BlockRecord.Clone() method the entities are ordered according to the existing SortEntitiesTable.
  The SortEntityTable is removed.
• When the drawing order is to be changed while the block record is not associated with a document the sort order cannot be defined by a SortEntitiesTable. Instead the explicit order of the entities must be modified.
• When the block record is attached to a document handles are assigned to the entities. We are sure that the entities are explicitly ordered. We still do not need a SortEntitiesTable but we could create one.
• When the drawing order is to be changed while the block record is associated to a document the SortEntitiesTable must be modified.

Which Scenario do you prefer?

[DomCR]

Hi @mme1950,

I will start working on the first steps which it would be to change the sort table to an entity-entity relationship and see how it works when is created, modified or cloned.

After that we can implement the methods that you propose:

• MoveToBottom(Entity entity)
• MoveToTop(Entity entity)
• OneStepUp(Entity entity)
• OneStepDown(Entity entity)

I'll take a look as soon as I can.