Task submission PDFs strip out student annotations once uploaded

[JamesDale]

It appears as though uploading a PDF with annotations (from a tool such as preview on macOS) strips those annotations once a task has been submitted.

I've had a couple of tasks requested for resubmission as it appears on the tutors end that I have submitted nothing.

Figured out that this may be due to OnTrack/Doubtfire removing PDF annotations and not flattening them. I don't have Doubtfire setup locally, but after receiving a couple of requests to resubmit work, I gather this is the issue.

Take for instance the attached PDFs. A teacher may ask students to fill information in on a PDF, and upload the task.
If a student annotates on the PDF (say using the built in PDF tool "Preview" on macOS, and possibly with other tools such as Adobe, although untested), and uploads this PDF file, OnTrack/Doubtfire will remove the annotations when generating the submission PDF.

Workaround: If the student flattens/exports the annotated PDF beforehand, this issue does not persist.

I imagine this would be quite confusing though for students uploading tasks where they're editing a PDF provided by their teacher, as I would expect uploading a PDF (annotated or not) provides my tutor with a copy of the PDF that is visually similar/identical to what I see at upload time.

As you can see, both are PDF files. Both are visually identical when opened up in a PDF viewer. One has been flattened by the PDF viewer and works for submission purposes (_Exported.pdf), whilst the other, will have the question showing up with no answer in the submission pdf (_Annotated.pdf) causing a lot of confusion for both tutors and students alike :)

Hope this helps. If you'd like some other PDFs to try this out with, please reach out directly.

OnTrackSubmissionIssue_Annotated.pdf

OnTrackSubmissionIssue_Exported.pdf

[JamesDale]

FWIW, it appears this isn't an issue when you upload the PDF as an attachment to a comment - but this doesn't count as a task submission of course.

[JamesDale]

Probably related to #130 as well.

[jakerenzella]

Sorry @JamesDale, I missed this notification. I'll investigate this and see what we can do.

[ublefo]

I looked into this and the pdfpages package is the root cause of this issue, as well as #130. There is no convenient solution to this problem, as there doesn't seem to be much the TeX engine can do about annotations. https://mirror.aarnet.edu.au/pub/CTAN/macros/latex/contrib/pdfpages/pdfpages.pdf (page 2)
https://github.com/doubtfire-lms/doubtfire-api/blob/6.1.x/app/views/task/task_pdf.pdf.erb#L114=

The only viable option I found it to use the pax package which has recently been revived. https://www.ctan.org/pkg/pax This package requires an external Java program whose source is included in the source repo. I have tried Ghostscript and that stripped the annotations as well.

[ublefo]

I have identified a fix that does not require an external Java dependency, there is a package called newpax which extracts the annotations (including links). It's pax but rewritten in lua so it can be called in-line in a TeX file with the \directlua directive. I'll see if I can come with a fix in the upcoming weeks.

#130 can probably be closed since this is the same issue.
doubtfire-lms/doubtfire-web#337 refers to the same issue and should also be closed.

[ublefo]

Additionally, we need to do some tests on GhostScript to make sure the PDF compression function in FileHelper don't strip our annotations and links. https://github.com/doubtfire-lms/doubtfire-api/blob/c8e9eada7a23cf367055798e6a22dc3f898682ce/app/helpers/file_helper.rb#L222=

[jakerenzella]

Hey @ublefo sorry I've not had a chance to reply - thank you so much for looking into this and figuring out what's going on.

I have been thinking about this process in Doubtfire for a while - I am of the position that we should move away from compiling submission types into a single PDF for feedback.

What I think it would be good to discuss moving forward is a modular system wherein the raw-files are represented in their appropriate format.

This would mean that the submission window would consist of a series of components, for example a code window, an image, and a video file would all be displayed one after the other (as it's done now), however the video would be playable for example. For example Microsoft includes a javascript-based word document viewer (not editor) https://jsfiddle.net/gcuzq343/.

The other benefit is that we would not need to wait for the PDF to be processed.

Not to say this investigation isn't valuable, as I still think a way to export either the entire portfolio or individual tasks as a PDF is valuable.

Are you a user of Doubtfire? What do you think of a solution like this?

[ublefo]

I am of the position that we should move away from compiling submission types into a single PDF for feedback.

Moving away from PDF compilation is the right solution in my opinion, we can avoid a lot of breakage by simply not processing the PDF when we don't need to. The vast majority of the tasks I have submitted only require a single PDF file, and it makes very little sense to actually pass it through TeX again.

What I think it would be good to discuss moving forward is a modular system wherein the raw-files are represented in their appropriate format.

That would be absolutely fantastic, because more often than not shoving source code files into LaTeX isn't the best idea if you don't have control over the TeX source. I have seen quite a bit of submissions came up filled with completely broken syntax highlighting and red boxes everywhere in the PDF, that would certainly make it more annoying to read for the convenors.

So to break down the types of files we expect the students to submit:

• PDF: embed it like we already do in the convenor's task view
• Microsoft Office documents: the viewer you mentioned, or they can probably be converted to PDF by the students before submission
• Video: uploading the file is unrealistic since it would consuming a lot of storage, YouTube/Kaltura embed would be more practical
• Code: CodeMirror should be a very good fit for this, we can set it as read-only too. List of supported languages is very extensive and should cover everything we use.
• Image: display as-is

Anything else I'm missing?

Are you a user of Doubtfire?

I'm a student at Deakin University and I'm hoping to contribute to this project.

[jakerenzella]

@ublefo I agree with this all, and I think will really help to modernise the user experience of Doubtfire.

From memory, @macite agrees with the direction to, is this the case?

If so I will start up a little project on this, as part of the task-submission-viewer re-write.

Always keen to get more students involved @ublefo - if this is an area you're keen to work on we can start working on the file-type-specific components, such as an image-viewer, pdf-viewer, etc.

[ublefo]

I'd definitely be willing to give it a shot but I'm likely going to need some help and guidance on this to make any significant code contributions, given I have no experience in web development and I'm very new to programming in general. I can learn quite a bit on my own with some guidance, the fact that I managed to identify and pinpoint the source of this issue when I have no experience with anything in the tech stack you use should be a pretty good indication of this. Please let me know what you think.