Why use base64 or hexadecimals for ciphertext? They are asking me to deliver encrypted text in ISO/IEC 8859-1. I have always encoded it to hexadecimal or base64. This text will be sent in a file with plaintext and encrypted text. In my opinion it won't work because of the non-visible characters.
I also wonder if there are characters that exist in hexadecimal and not in ISO/IEC 8815-1 (Western-Latin encoding). Am I right in assuming so?
When using standard encryption algorithms like AES-GCM, ciphertext is bytes that are approximately uniformly distributed among the 256 possible byte values. Since ISO/IEC 8859-1 allows like 191-byte values out of 256, it's extremely unlikely that any practical ciphertext will entirely consist of these 191 bytes, as would be the case if some appropriate Binary-to-text encoding was used, including Base64. In the rest, I'll assume it is not used such encoding.

The curious case is that within that file there are two lines in plain text (header and footer) and the rest encrypted.

That does not make it impossible for decryption of such files to works. Many modern file transfer methods, including USB thumb drives, attachments to email or messaging, network shared volumes, cloud storage, UNIX pipes, windows pipes opened in binary mode… will happily transfer any (contiguous and single fork/stream) file with all its data (if not metadata like file name, date and security attributes) unchanged. Thus the problem of allowing decryption boils down to locating the ciphertext in the file.
That can be dealt with with conventions. One possibility is that ciphertext starts after a header of fixed size in bytes that the decryption skips. Another is that it starts after the first occurrence of a fixed text sequence, e.g. &lt;-- ciphertext on next line --&gt; followed by a single LF character. The end of ciphertext can be dealt with by embedding the ciphertext length at the start of ciphertext. That can work if the file is correctly prepared, e.g. by a correctly written program; or by manually concatenating a header file, the ciphertext, and the footer file using bash on a Unix system; or using copy /b of cmd.exe on Windows.
Things that go wrong when that's attempted include: the file is opened and mistakenly saved with a text editor (perhaps to remove the header), and that particular text editor ruins the ciphertext (many do); the sender used CR LF as end-of-line and the decryption is unaware of that; the file is piped to a console display emulating some glass terminal (e.g. a VT100 itself emulating an ASR-33), which emits silly noises, locks, or act strangely because it entered an obscure mode.