Is there a way to produce a decrypted output with the same size as the input message?
Yes, CTR mode should work for that. You must have a broken implementation as there is no padding required for CTR mode. You could simply use the leftmost bytes of the ciphertext though. If decryption fails because of that then you could simply pad the ciphertext with zero's, decrypt, and remove the number of (now random) padded bytes so your plaintext length matches the ciphertext length.
Note that often an IV is send as well. The IV needs to be unique for CTR mode (in such a way that the counter is always unique). This is even more troublesome for 8 byte block ciphers such as Blowfish than for 16 byte block ciphers such as AES. You would need to use a counter IV or establish the IV otherwise to make the ciphertext the same length as the plaintext.
A way to calculate the length of zero-padding at the end (so that I can cut them off in the end).
For plaintext ASCII text you can simply remove all zero bytes at the end; zero is a control character called NUL which should not appear in printable text.
Note that there are two forms of zero-padding: one that always pads and one that doesn't always pad (which is more often used). You could encrypt a 8 byte block of plaintext to see which one you got.
Note that for binary messages that may contain a zero byte at the end that zero-padding is not deterministic, meaning that you cannot determine the exact amount of padding. You would need to implement a padding mode such as PKCS#5/PKCS#7 padding yourself if you require that.
Do not use Blowfish, use a 16 byte block cipher, preferably AES in an authenticated mode such as GCM (which does add the authentication tag as overhead though). Even Bruce Schneier - the inventor - doesn't recommend Blowfish anymore.
An 8 byte block cipher is especially harmful for CTR mode. You'd better use CFB or OFB mode if you have to stick to Blowfish. Those are also modes that turn the block cipher into a stream cipher, so they do not require padding.