I produced a flyer with a JPEG background and 2 SVG QR codes. The whole thing is repeated multiply in the document, for some variations of the flyer. It would seem that typst reembeds the images for every repetition.
ghostscript -dNOPAUSE -dBATCH -sDEVICE=pdfwrite recognised this, and manages to reduce the file size, by a quarter to almost a half, depending on the exact nature of the images. As a workaround this is ok. But it would be great if typst could match this out of the box.
Hi Daniel,
Could you rework your post a bit to better follow the forum guidelines? Specifically although this is in the Questions category, there doesn’t seem to be a question in the title or body.
Some other questions on the forum may offer some ways for you to decrease the PDF size:
The jpg is not reembedded normally:
#for i in range(10) {
image("4mb.jpg")
}
I’m not sure about the SVG, it maybe is. But: as I understand, your pdf size is only 2 times smaller after the gs command. This is not much and is trivial to achieve by compressing the image, which gs maybe does. Whether this is good is a different question.
Only 2x is not much, for real? Btw. I already used --no-pdf-tags. And upgrading to v0.15.1 gave a one percentish reduction, both before and after ghostscript.
Holding them side by side, I see no quality difference. But it’s a blurry background image in my case.
Do you know of a way of extracting the unmodified images, so I can analyze what changed?
I vaguely recall a issue with SVGs in Apple Preview. Typst worked around this issue and as a side effect SVGs are no longer deduplicated. Unfortunately I can’t find the issue right now, but I think the change was is v0.14.
It seems that by default, Ghostscript does not do anything to JPEG images (see the PassThroughJPEGImages parameter in High Level Devices — Ghostscript 10.09.0 documentation). This matches with my testing, where the file size didn’t change for jpegs.
For embedded pngs however, the file size indeed decreased. Extracting the images from the pdfs, it seems that the file size is dominated by the image size so I don’t think typst re-embeds the images.
For example, my original PDF has 60 pages all with the same image, and a size of 706KB. Each embedded image in the file has a size of 675KB (despite the original png only having a size of 64KB, but converting them to JPGs grows them by a factor of ~10, roughly consistent with the larger size of the embedded image)
After running GS, the size of the PDF decreased to 221KB again dominated by the compressed image size of 185KB. Despite this, the images are identical after extraction (not just visually, the files are the same. Funnily enough, the extracted PNGs both had a size of 721KB, larger than the original and the PDF files).
So, it seems to me that ghostscript just uses some smarter image compression algorithm.
btw, I used PDF x-change to inspect/extract the images. But I think it’s a paid app.
image (saved as PNG)
#set page(margin: 0pt)
#rect(width: 100%, height: 100%, fill: gradient.linear(..color.map.turbo))
#place(dy: -100%, rect(
width: 100%,
height: 100%,
fill: gradient.linear(..color.map.turbo.map(c => c.transparentize(50%)), angle: 90deg)
))
PDF:
#set page(background: image("gradient.png"))
#{pagebreak() * 60}
Yes. Factor 2 is not good. Unless we know that it includes the very same files.
Please, use mutool extract file.pdf and then compare the images.
If the images are really identical, then the reason is maybe the pdf object stream compression. I think typst does not support object stream compression currently. But maybe my knowledge is outdated here.
Exciting: mutool clean -gggg -Z does about as well as ghostscript on the typst output. But amazingly on the much reduced ghostscript output, it manages yet another sizable reduction. 
But, the assumption I read somewhere was wrong: all three PDFs contain the identical image*jpg once, unaltered from my original. The SVGs were apparently inlined. However the two font*cid became a few bytes bigger after ghostscript, while the four font*ttf shrunk by over 1kB each. (This hardly contributes, with my double-reduced file size still 1.2MB.) The fonts were not altered again by mutool.
Then it’s probably missing pdf object stream compression. You can get statistics about compression from
mutool audit file.pdf > audit.html
Additionally, you can also decompress the streams using clean -d and check if the file size becomes similar to typst pdf file size. Also make sure to try to use with and without -Z, as this was my second guess about the size difference.