A few major misunderstandings here.
First of all, that book is just wrong. Signing is not a form of encryption, nor verifying a form of decryption. In the specific case of RSA, signing is mathematically the equivalent operation to "encrypt with the private key", but this is more a coincidence than an inherent property of digital signatures. Some digital signature algorithms don't support actual encryption at all! (DSA and ECDSA being the obvious ones.) Conceptually, the two operations (sign vs. encrypt) are used very differently, and practically there are many considerations for an implementer (padding, length, etc.) that apply to one operation but not the other, even for RSA.
Second, signing is never done in a way conceals the original message. This may be another way that book is misleading you: all signing operations, conceptually, take two inputs (a message and a private key) and produce one output (a short-ish string / huge number that is meaningless without the original message). The inputs - including the message - are not modified. Usually the actual operation of signing can only be done on a short piece of data, so the message is cryptographically hashed first (this is usually done automatically by the crypto toolkit when you say "sign M with K"), but some algorithms instead work on the whole message and internally are doing something akin to hashing while also producing the signature. From the user's perspective, this is still "sign M with K", just for a key K used with a different digital signature algorithm.
In any case, the practical output of a signing operation is that now you have two pieces of data - the message M and its signature S - in addition to your private and public key pair. Anybody with M, S, and the public key can verify that S was created from M using the corresponding private key if neither of M or S are modified, so of course you have to distribute M and S unchanged. Note that S is usually much smaller than M, and it is conceptually impossible to extract M from S.
Now, in practice, signing is often (not always!) used with encryption. When encrypting, you do modify M - or at least, you produce C, the ciphertext of M, and keep M secret - and then either the recipient must decrypt C (to get M) before they can verify the signature S, or you sign the encrypted message C rather than signing the plain text M and thus your S is verified against C not against M. Nothing in this paragraph is relevant to certificates, because certificates do not have any encryption!
With those cleared up, hopefully you understand why the question is trivial. A certificate consists of (arguably) four parts: data about the cert (when it was issued, by whom, for how long, for what purposes), data about the subject (who the cert is issued to), the subject's public key, and the issuer's signature of the previous three parts. The first three parts are plain text, and the last - the signature - is meaningless without that plain text.
So, you extract the public key from a self-signed certificate - or any other part, from any certificate - by parsing the certificate structure and reading the relevant part of the certificate (the one that contains the public key). That's it. The act of signing does not, and must not, modify any part of the certificate (except the part where the signature itself is stored).
