Sometimes it’s useful or necessary to post a PDF file or a ZIP file with a project or some other stuff, but it’s currently not allowed. I can upload it if I just add .png (classic), but it is being removed right away due to not being able to immediately render the image or something (and it doesn’t show any error, which is bad UX). I don’t know what is the current limit on file image size, but I assume it’s at least 5 MiB, which means a PDF/archive of the same size is no difference, so server storage capacity is not a concern. I don’t see any other reasons not to allow them.
Right now, I have to use some third-party service for this (potentially requiring creating an account), which means that if I want to clear it after a while (otherwise eventually I will run out of space myself), the link on the forum will become broken.
I’m not an admin here, but usually attachment restrictions are put in place to prevent a) misuse of a service as general file storage or b) usage of undesired file formats (e.g. submitting an exercise as docx instead of pdf) - maybe there are other reasons too, idk.
Since these are the legitimate reasons not to allow this, what was your concrete need for a zip/pdf attachment? If you have a legitimate use case to attach something other than an image that is actually part of the post it may be worth considering, but if you want to share something like a Showcase that requires a zip file to be complete, maybe a public github repo or similar would be more sensible.
(PS: obviously agree that there should be an error on failed attachment)
I’ve also wished sometimes that such uploads were permitted. I think ZIP files would be especially useful for sharing a project structure easily. Currently people often describe the structure laboriously, and to run the MWE I have to recreate the structure myself locally, again a laborious process.
Two related downsides I can think of:
The current system encourages people to make the effort of posting a nice screenshot showing just the relevant part of the output. This is great for readers of the forum. If we allow PDF, people might get lazy and just upload the whole document. Most often this would result in poorer experience when reading the post.
People might be less motivated to write a proper MWE if they can just upload the whole project as it is.
hmm, for an MWE that is supposed to contain multiple files it kinda makes sense… usually, it can still be reduced down to two files, and putting them inline should be ok.
And I agree with @sijo that it would encourage people posting non-minimal code without outlining the important parts directly in the post.
In the specific case, the problem is fairly easy to identify; I’ll comment there.
The 2 lazy points can be canceled by enforcing the proper use.
PDF: only if it’s not reproducible, but helpful when debugging something that is not possible through the screenshot
ZIP: only if you need to provide font files or some other binary files that are required for MRE, or if you need to provide a project structure that can’t be shown through a tree-like output, or if providing the sources for all files is too verbose.
In theory, I can just <detail> 6 files, but copying them all one by one to recreate the project structure is rather tedious, and the main point in that topic is reproducible example, which archive is perfect for. So the line is very thin, but the more files you actually need to share, the more it’s obvious. Or if you have to share some binary files.
Also, if only ZIP file is allowed, then it would slightly discourage people to send PDFs, because you would have to archive it first.
There are a ton of use cases where an archive would really help, so it’s definitely should be added. I don’t know if it makes sense to instead allow all types of font files instead.
I just fear that once that door is open, it will be too convenient and misused, so the enforcement is more work than we’d like.
This feels very niche; do you know of any cases where the PDF helped debugging more than the Typst code producing it? I can think of printer problems, but that’s better suited for Github issues than the forum, since it’s about a Typst bug and not user error (granted, that may not be clear from the beginning).
For font-specific problems I indeed can’t think of an alternative. For MREs: unless you’re struggling with include, import or paths in general, the code can be put into a single file as well. Images can usually be replaced with #rect() or something. In the example you showed, one including file and one included file would have been sufficient, and then I think it’s ok to have to paste them both as snippets instead of being able to add a zip.
Since I still haven’t read through 948 unread topics, I don’t know if anyone posted any issue here, but if someone will, then that means that they would have to potentially create a GitHub account to post an issue there, rather than using already existing Typst account. And all answers would be “post issue on github”. But I agree that for bugs, you better directly open an issue.