Replies: 11 comments 33 replies
-
Write a one line test document using the same font in each, then change up the font and check the size changes in each. That will tell you. I'm guessing you are embedding a full CJK character set font in one situation and not the other. In other words apples and oranges. Report back here if there is an oranges to oranges comparison with a significant difference. |
Beta Was this translation helpful? Give feedback.
-
My guess (I have only quickly looked at the PDF in a Text Editor):
Possible solution: |
Beta Was this translation helpful? Give feedback.
-
I think that while of the above things are true, in this case it's pretty much just fonts. The rest is really very small in comparison, typically. Note that XMP Metadata shall be uncompressed so that other programs can find it in the file without understanding the PDF. |
Beta Was this translation helpful? Give feedback.
-
I, too, noticed this. And indeed, the problem is only with |
Beta Was this translation helpful? Give feedback.
-
I'm currently using |
Beta Was this translation helpful? Give feedback.
-
I just found that a 33-page paper I wrote was 28 MB. I put it through smallpdf.com, which resulted in a 1.1 MB file that looks the same, has the same hyperlinks etc. In other words, I see no difference, but the file is around 4% of the size. This makes me feel like there is some low-hanging fruit for compression that could and should be applied by default. For comparison, another paper I wrote a semester before in Overleaf (LaTeX) is 44 pages, but only 4.3 MB. Both papers contain pictures, but I would say the amount and resolution is comparable. This indicates, as people have pointed out above, that LaTeX performs more compression by default. I am not sure what the downsides are to adding compression, so please point them out. But the benefit does seem rather huge. I discovered this issue because I could not send the paper over facebook messenger due to the 25 MB file size limit. I can also imagine that cloud-storages with PDFs will fill up significantly quicker for typst-users. This kind of practical inconvenience is bound to make the user experience of using typst worse, so the downsides to adding compression should be pretty large before it does not make sense to compress by default. |
Beta Was this translation helpful? Give feedback.
-
This turned out to 100% be the case. I had a 17.2 MB PNG file in the report. When I replaced it with a 4.8 MB JPG, the final file size ended up being 4.9 MB. I am not sure how that works out, as the difference between the JPG and the entrite document is only 0.1 MB, and I have a bunch of text and other pictures as well. Perhaps JPG is somehow compressed by default, as unlike PNG, it is already a lossy format? So yes, it seems like this one is entirely on me, and that the indication I had for saying that typst produces large PDF's was unfounded. I do have to say that it would be great to be able to opt-in to some amount of compression, as I think for most users the only noticable difference would be smaller files. |
Beta Was this translation helpful? Give feedback.
-
I just ran a sample test with typst using the example from https://github.com/caffeinatedgaze/bare-bones-cv. The resulting PDF from typst is 44790 bytes while compressing it losslessly using HexaPDF leads to a file with just 35097 bytes, i.e. a 22% smaller file. The main difference here is the use of object streams to compress PDF object and to compress streams that aren't yet compressed like the ToUnicode CMap stream. So adding compression for all streams and adding support for object streams could be an easy fix for larger-than-necessary files. |
Beta Was this translation helpful? Give feedback.
-
Just adding another data point for this discussion. Below you will find the result of a benchmark I created for HexaPDF that shows the running time as well as memory usage and resulting file size for outputting the Gutenberg text of the 'Odyssey' on pages with a width of 100pt and 50pt and a height of 1000pt (granted, this is a very specific benchmark for testing how long words that need to be broken on short lines affect the runtime/memory usage but nonetheless interesting, I think):
As you can see HexaPDF produces a file that is markedly smaller than the others, in both cases (still need to optimize the 50pt width case in terms of performance and memory usage, though). This is achieved by compressing all streams and making sure that the output of PDF objects is as compact as possible. |
Beta Was this translation helpful? Give feedback.
-
I found a very simple way to compress PDFs. I just use this ghostscript command:
It works great on a resume PDF which went from 9 MB to just over 100 KB. I also found that pdfcpu didn't decrease the file size on my PDF but ghostscript did. |
Beta Was this translation helpful? Give feedback.
-
I don't mind makes pdf more editable if they contain more info (which can be more accessible to people with for example screenreaders), but I can see why you would dislike it, I guess we can have an optimize flag or something like that |
Beta Was this translation helpful? Give feedback.
-
Recently, I started using typst to write my assignments. However, I quickly noticed that the PDF generated by typst is considerably larger (~1.9MB) compared to TeX's output (~120KB).
I am curious if this difference in file size is due to the different fonts used (SourceHansSerif in typst and Fandol series in TeX) or if it is an issue with typst itself?
Beta Was this translation helpful? Give feedback.
All reactions