liZe
commented
3 months ago Thanks a lot for this very clean pull request. ❤️
I’m sorry because of the too long comment I’m about to write. This is not against you (you fully understand the problem), this is about how the system works.
This is not fair. At all.
Your commit is about to be the third one in less than a month (after ff2acf1 and 2c4351e) to "fix" a "problem" with macOS Preview. Designing a PDF rendering engine is complicated, for sure. It’s normal to have bugs, and it’s normal for some of these bugs not to be fixed for a long time. macOS Preview has quite a lot of problems displaying PDFs, at least a bit more than many other implementations. And it’s OK, Apple software is not perfect, no software is perfect.
What’s not OK is that Apple relies on other developers to handle their own bugs. There’s a bug in WeasyPrint? Let’s open an issue on WeasyPrint’s bug tracker. There’s a bug in Preview? Then, let’s open a bug on Preview’s bug tracker! But, wait… Where is Preview’s bug tracker? I’ve found this:
That’s beautiful, Apple. But… How am I supposed to report a bug? How am I supposed to see if a bug is already open for this case? How can I know if this bug is fixed to remove this extra code from WeasyPrint when it’s not needed anymore? I want to open an issue on a public bug tracker, follow the advancement of the fix, and lead other people with this problem to this issue’s URL.
(I am genuinely interested to learn how it works.)
This is how the system works: when there’s a bug in macOS Preview, we have to fix it in WeasyPrint. A small team of 2 people helped by amazing unpaid contributors has to take the burden of fixing, documenting and maintaining extra code, because a company with 160000+ employees and 380+ billion dollars of revenue doesn’t want to share a list of public issues for their software.
And Apple is not the only one. We also have to explain users that when Microsoft’s browser is not able to print WeasyPrint documents correctly (#2129), it’s not WeasyPrint’s fault, it’s not WeasyPrint developer’s job to handle the problem.
Since this change shouldn't change how the resulting PDF appears visually in general, I wasn't sure how to write a meaningful regression test.
I’m really grateful you thought of that, but the answer is that you can’t write a regression test without checking that the PDF internals please macOS Preview’s limitations. And we don’t want do do this.
Here we’re stuck. There’s nothing more we can do than committing this code in WeasyPrint’s repository and hope that it won’t cause other bugs that we’ll have to fix in the future. But I want to be clear that we won’t do this forever. One day, someone will have to explain these big companies that relying on open source software developers to fix their bugs is not fair. Just as the amazing Daniel Stenberg did.
This comment is only written as a reminder than in the future, when I say "no" to another pull request, I’ll be able to add a link to this comment instead of sharing my distress privately with @grewn0uille (who doesn’t deserve this). 😄
xavidotron
This one's a bit weird, so feel free to let me know if this doesn't feel suitable to upstream or if you would prefer a different approach.
WeasyPrint uses PDF patterns for background images, which is a reasonable choice. However, a PDF viewer I frequently use, Preview.app on MacOS, doesn't handle vector images in patterns as well as it does when those images are drawn not via a pattern, leading to unnecessary pixelation when zooming in. Adobe Acrobat Reader doesn't have this issue, so I think this is just a shortcoming of Preview.app. But, at least when the background-image is no-repeat, there doesn't seem to be any advantage to having it in a pattern.
Thus, this pull request draws the background image directly (without a pattern) in the case where the background image is no-repeat in both directions, while leaving other cases unchanged. This is sufficient for my use-case. While it would be possible to avoid using a pattern in more cases by drawing the image directly repeatedly, that would add complexity and so I wasn't sure whether it would be desirable.
Since this change shouldn't change how the resulting PDF appears visually in general, I wasn't sure how to write a meaningful regression test. Attached are screenshots of the same source zoomed in via Preview.app, to show you what I'm talking about.