Unfortunately, adding opacities to gradients in PDF is much more complex than just adding an "opacity" value to it, so it's probably just not been implemented yet? @Dherse

It should be doable to implement it, it just isn't because it's a whole rabbit hole of its own

Supposedly this was implemented in 0.7, as per #79, but I'm also having the same issue

Supposedly this was implemented in 0.7, as per #79, but I'm also having the same issue

The 0.7 change brought alpha support in general, but not for gradients (which only came with 0.9).

I have a branch that sorts of work but it's far from merge ready.

@LaurenzV @Dherse

Thank you for your efforts regarding the complexities involved in adding opacities to gradients in PDFs. I understand that it's a challenging task, potentially involving more than just adding an "opacity" value, and it might not have been implemented yet due to the intricate nature of the issue.

The issue resonates deeply with me. The inconsistencies between PDF output and preview results, particularly concerning transparency and SVG image rendering, have caused me significant trouble. Just yesterday, after completing an extremely complex template for our company, I faced a heartbreaking moment. Despite everything looking perfect in the preview, the output PDF was a chaotic mess. It was already past midnight, and I had been working overtime for over seven hours. Now I have to tackle with more issue on weekends.

I fully appreciate the technical difficulties involved in implementing features like SVG and transparency in PDFs. However, I wonder if we might consider a compromise to ensure visual consistency. For instance, could we output high-resolution bitmap PDFs (suitable for printing, as the current default PNG output resolution is quite low) and attach the text information in a hidden layer within the PDF, similar to what OCR documents do, which can enabling text selection?

While I'm not deeply familiar with the technical intricacies of PDF implementation, my intuition suggests that this approach might provide a more unified solution to the discrepancies between preview and actual PDF output.

And for now, if you are facing the same trouble, consider output all files to the SVG format and convert these files to PDF with a headless Chromium, here is an example: https://github.com/Losses/pdf-postprocess

In theory, rsvg can also achieve this goal, but I haven't yet found a method for Rust binding to output PDF.

Thank you for the amazing effort on typst, I really appreciate it.

Despite everything looking perfect in the preview, the output PDF was a chaotic mess.

I mean, could you be a bit more specific? What exactly was wrong, apart from gradients with transparency not showing up correctly, which doesn't sound like something that should be that noticeable?

more specific

Thank you for your prompt response.

Recently, most of the issues I have encountered are related to gradient rendering problems. Regarding SVG, I have faced two issues. One was with the rendering of SVG patterns, which seems to have been fixed as I can no longer reproduce it. The other issue is that some images cannot be rendered correctly as vector graphics. Here is an example: https://typst.app/project/r8-jUq5xEOsa1q21pqBHEn

The reason this is happening is because your SVG contains filters. It's not possible to translate those to PDF, as PDF doesn't support them directly. So the only option is rasterizing the parts affected by the filter, which is what is happening here. You can try any other SVG to PDF converter, and you'll most likely see the same result, so there isn't much we can do here. It does look pixelated, so I guess we could provide an option to specify the resolution at which the parts should be rasterized.