PRC: PRC_TYPE_TOPO_BrepDataCompress / PRC_TYPE_TOPO_Context tailing 5 bits

[ralovich]

Additional context
This is written against the PRC ISO standard 14739-1, First edition, dated 2014‐12‐15.

Describe the bug
My test data collection has a few cases where parsing an additional 5 bits of (dummy) data at the tail end of PRC_TYPE_TOPO_BrepDataCompress (or at the tail end of PRC_TYPE_TOPO_Context - as PRC_TYPE_TOPO_Context.number_of_bodies is 1 in these samples) makes the parser succeed.

I am assuming that there are conditional field(s) in either PRC_TYPE_TOPO_BrepDataCompress or PRC_TYPE_TOPO_Context that my parser misses. Could you please attach a screenshot of PRC_TYPE_TOPO_BrepDataCompress and PRC_TYPE_TOPO_Context from the current working document of the spec?

Two of the offending samples are https://github.com/ralovich/prc-db/blob/main/prcs/3D_PDF_Engineering_Spec_Sheet.stream-348.prc and https://github.com/ralovich/prc-db/blob/main/prcs/3D_PDF_PROSTEP-Camera_Features-1.stream-134.prc.

[ralovich]

After further inspection the 5 bits of tailing "padding" is only necessary when the sum number of faces in the PRC_TYPE_TOPO_BrepDataCompress is 0.

[socrat74]

It sounds weird. Most likely, there is something you do not read in the other tables contained directly or indirectly in PRC_TYPE_TOPO_BrepDataCompress - connex, shell, faces, etc. This is quite a complex data structure.

[ralovich]

Agreed, however not sure how do better with the old specifications I have access to.

Could you please attach a screenshot of PRC_TYPE_TOPO_BrepDataCompress and PRC_TYPE_TOPO_Context from the current working document of the spec?

[socrat74]

As far as I can tell, they are the same as in the old spec:

[ralovich]

As far as I can tell, they are the same as in the old spec:

Yes, appears to be the same. Thank you for sharing!

[ralovich]

My suspicion is then on MultipleCompressedConnex, CompressedConnex, CompressedShell or BaseTopology. Could someone share the current definition of those too?

[t3dr0]

This is from the current draft (c. Nov 2025):

Table 200 — MultipleCompressedConnex

Name	Data Type	Data Description
number_of_connex	NumberOfBitsThenUnsignedInteger	(Required) Number of connex entities
connex	Array <CompressedConnex>[number_of_connex]	(Required) Array of compressed connex entities

7.9.21.3 CompressedConnex

The CompressedConnex structure represents all of the shells within a compressed connex entity (see Table 201).

Table 201 — CompressedConnex

Name	Data Type	Data Description
number_of_shells	NumberOfBitsThenUnsignedInteger	(Required) Number of shell entities
shells	Array <CompressedShell>[number_of_shells]	(Required) Array of compressed shells within a connex entity

7.9.21.4 CompressedShell

The CompressedShell represents the compressed data for a single shell (see Table 202).

Table 202 — CompressedShell

Name	Data Type	Data Description
single_face	Boolean	(Required) True if there is only a single face in the shell
number_of_faces	NumberOfBitsThenUnsignedInteger	(Optional; if single_face is TRUE) Number of faces in the shell if there is more than a single face.
faces	Array <CompressedFace>[number_of_faces]	(Required) Array of faces within the shell.
is_iso_face	Array <Boolean>[number_of_faces]	(Required) Array of Boolean values indicating if the face is an iso-face (TRUE) or not (FALSE). This is in the same order as the previous array of compressed faces.

Serialization Note: In serialized PRC all IsoFaces are stored before AnaFaces, regardless of the actual face ordering. To preserve the order of faces, this array stores which type of face should be stored in the correctly ordered shell.

---

EXAMPLE

An example of shells and how it would be serialized is shown in Table 203.

Table 203 — Example of Shell Serialization

Shell	Serialized
I	I	1
A	I	0
A	I	0
I	I	1
I	A	1
A	A	0
I	A	1

Key

• A: Anaface
• I: IsoFace

[ralovich]

It appears MultipleCompressedConnex.number_of_connex and CompressedConnex.number_of_shells were changed from UnsignedInteger to NumberOfBitsThenUnsignedInteger in the errata.

[t3dr0]

Yes, I see that (and in several other places) however I wonder if it would be clearer if the data type was returned to UnsignedInteger (for use as size counter), with a descriptive note about how this is stored using NumberOfBitsThenUnsignedInteger? i.e. separate semantic meaning of the value from the data structure representation. Any thoughts?