A look at ShrinkPDF on FreeBSD | A No Commentary Quickie

A simple wrapper around Ghostscript to shrink PDFs (as in reduce filesize).
The script feeds a PDF through Ghostscript, which performs lossy
recompression by such methods as downsampling the images to 72dpi. The
result should be (but not always is) a much smaller file.
This is another No Commentary Quickie, so if music and no talking is not
your thing, I apologise beforehand and ask for your forgiveness :-)
---------------------------------------
---------------------------------------
----------------------------------------
#RoboNuggie #FreeBSD #GhostBSD #helloBSD #NomadBSD #BSD

[DebGoodkin]

I love your FreeBSD videos and tutorials! I hope you continue producing them.

[BSDJedi]

Cool. I do use PDF a lot, and did not know about this tool! Thanks for the tip :-)

[mirror]

It is certainly handy to have tools like this if in a bind to make things a little smaller for sending by email or packing on a disk that is too small. The "text" should be just as crisp start to finish as its the same font (usually on your system, though PDFs can bundle the used fonts for more reliable portability at the cost of a larger filesize & font license complications). Photographs quality is being reduced and when you have photographs of text then those too are impacted. If a creator cares about file size then they always put text in the file as text, vector art if they need more artistic flexibility, and pictures of text last. FreeBSD Handbook screenshots of terminals could certainly be replaced+optimized with a better workflow to make things smaller + more compatible with terminal users who also can benefit from a handbook's contents.
There are tools available that can lead to lossless modification too. If you built the PDF yourself then you can look into options like graphics/jpeg-turbo for jpegtran to losslessly recompress jpeg files or graphics/optipng, graphics/oxipng, graphics/pngrewrite, for png files and then build the PDF from the more optimized copies.
If doing lossy compression, you can consider converting images to jpeg2000 if you have a reader that supports PDF standards from 2003+. You can also consider using a lossy jpeg encoder like jpegli that makes smaller jpeg files of comparable quality (currently found in graphics/libjxl but don't be surprised if it gets moved to its own port). Again, consider a pass the jpeg through jpegtran to see if there are savings to be had. Other tools could be experimented with such as graphics/imageworsener to preemptively distort the image in ways that may be beneficial to the final encoder. Hopefully we will get support for jpeg-xl images in PDF files soon enough which has estimates claiming lossless jpeg recompression at 20% savings or lossy compression of an image from original source at comparable quality to jpeg at 50% savings.
If you don't have the original source to recreate the PDF and it has text as photos or simple graphics then you may consider passing the images through OCR software to make text or image processing software that makes scalable vector graphics (SVG) formatted data copying it. Both likely need manual cleanup to truly optimize their output.
Windows users are spoiled in that they can just pass the complete pdf, or pieces it is built form, into the free fileoptimizer from nikkhokkho.sourceforge.io which has a large number of filetypes supported by a large number of opensource and closed source plugins. That has options for whether or not to allow lossy changes, changes that make editing in the future hard/impossible as a result of the shrinking, whether to keep metadata, whether to make changes that are likely to impact compatibility like arithmetic encoding for jpegs, etc. It also handles files inside files so can work on some of these scenarios like a pdf with other types internally contained in it. After all that, its worth having a Windows machine/partition, virtual machine, or (if it works, I haven't tested it) Wine to run it. If you can figure out a pipeline used by a filetype, you may be able to use native tools outside of it and pushing some tools hard enough can exceed what file optimizer accomplishes.
As a catch to all of these, sometimes bugs happen and the new file should be confirmed before replacing the old. fileoptimizer has some issues detected and skips processing but isn't perfect.
Once you have your final file, you can consider compressing it with a compressor of desired computational complexity (look in /usr/ports/archivers for zstd, xz, bzip2, bzip3, zpaqfranz, etc).
If you use ZFS, you can have compression turned on for the dataset, but ZFS currently has a limited compression algorithm selection, outdated compressors that are outperformed by newer versions, is limited to compression chunks not exceeding record size (larger=better compression), doesn't support as many settings as using a compressor directly, and multiple files datastreams are always handled separately. This compression gets lost if the data leaves the pool and system. On the plus side, you save disk space without having to perform a compress/decompress step manually when working with the data.
After all this effort, it still doesn't compare to what a TeX/LaTeX file takes for disk space which can be used to create a PDF when needed for viewing and delete it again to get that back. Create an efficient workflow for graphics generation from the data used to generate them for small graphics storage. Again, you can save further by using a general compressor/archiver on these source files for storage too. Disadvantage is the PDF has to be built to view it so you are trading time for space.

[sonphantrung]

Will you continue uploading, it's been more than a week. I want more of FreeBSD content D: (though if you're busy, it's fine).