Answer by Ilya Zakharevich for Change color in finished pdf file

Yesterday, I have been fighting a similar problem: while xelatex of TeXLive2018 was producing PDF files without hard-stored blacks, it turned out that TeXLive2021 produces files with immutable blacks. (This may be due to xdvipdfmx's version change 20180217 → 20210318. This broke my usage scenario of my “Emoji-includer”.)

The difference is due to the following change in the generated PDF file (with added spaces):

- q 1 0 0 1 72 -62.967 cm 0 G 0 g 0 g 0 G BT /F1 9.9626 Tf -72 64.65 Td[<1841>]TJ ET Q+ q 1 0 0 1 72 -62.967 cm                 BT /F1 9.9626 Tf -72 64.65 Td[<1841>]TJ ET Q

inside a stream in a PDF object which is the content of every PDF object of /Type /Page (the page above contains only a glyph indexed by[<1841>]).

My work-around

After uncompression, run

perl -wpe "BEGIN{binmode STDIN; binmode STDOUT} s/(?<!\S)(0\s+[gG])(?!\S)/q( ) x length $1/ge" emoji-from-list-uncompress.pdf >emoji-from-list-nocolor.pdf

This follows — in general — the Heiko’s answer on this pageand sebschub’s comment on this answer. However, we edit away g and G commands instead of rg, RG, k and K from this comment.

The editing command above may have a chance to be not specific enough. In the file I can see, the g/G⸣s come in long groups.So the command

    perl -wpe "BEGIN{binmode STDIN; binmode STDOUT} s/(?<!\S)((0\s+[gG]\s*?){2,})(?!\S)/q( ) x length $1/ge" emoji-from-list-uncompress.pdf >emoji-from-list-nocolor.pdf

may be much more robust. It looks for at least 2 black-g-or-G commands in a row .(These perl commands are in Windows’ shellsyntax. Change "⸣s to '⸣s on Unixy systems.)

Warning: the resulting PDF file is still uncompressed. Without compressing it,including it in other files increases their sizes (unnecessarily). (Use the pdftk command in Heiko’s answer with compress instead of uncompress.)