The blog you were inspired from shows the following graphics to explain the PKCS#7 signature container structure

Actually, though, this represents only the most simple structure defined by PKCS#7. If you look at the SignerInfo specification (content - signerInfos - SignerInfo), you'll see

   SignerInfo ::= SEQUENCE {
     version Version,
     issuerAndSerialNumber IssuerAndSerialNumber,
     digestAlgorithm DigestAlgorithmIdentifier,
     authenticatedAttributes
       [0] IMPLICIT Attributes OPTIONAL,
     digestEncryptionAlgorithm
       DigestEncryptionAlgorithmIdentifier,
     encryptedDigest EncryptedDigest,
     unauthenticatedAttributes
       [1] IMPLICIT Attributes OPTIONAL }

(RFC 2315 section 9.2 "SignerInfo type")

In particular there are the OPTIONAL authenticatedAttributes which you don't find in the sketch above. But in any current signature profile to be taken seriously these authenticatedAttributes (aka signed attributes) are actually required!

Furthermore, if there are authenticatedAttributes in a PKCS#7 signature container signer info object, the encrypted digest is not the digest of the document data but instead the digest of the authenticatedAttributes structure. In this case the digest of the document data is stored as the value of a specific signed attribute, the "messageDigest" attribute. Thus, in this case you try to extract the wrong value to compare the document digest with.

For example in case of the example document you shared in your follow-up question there are authenticatedAttributes, so the inspiring blog led you astray.