Deprecate the watermarking APIs and remove fonts from the image

[dhruvkb]

The API for watermarking with a frame around the image should be deprecated and removed. It's not used from the frontend and the major migration to Openverse allows us to deprecate a lot of infrequently used code to streamline the repo.

openverse-api/api/catalog/api/utils/watermark.py

Line 161 in 59f9092

def _print_attribution_on_image(img, image_info):

The associated font must be removed from the repository and the Docker image.

openverse-api/api/Dockerfile

Line 49 in 59f9092

ADD catalog/api/utils/fonts/SourceSansPro-Bold.ttf /usr/share/fonts/truetype/SourceSansPro-Bold.ttf

[RishiKumarRay]

@dhruvkb Do we have to remove both the codes given above?

[dhruvkb]

Let's also wait for some more opinions to weigh in on removing the functions based on their low usage.

[AetherUnbound]

Hmm, this seems like a useful feature and it would be cool to add it to the frontend! But it's also more for us to maintain so I'm fine with deprecating it.

[zackkrida]

I would love an endpoint like this for generating open graph images for the search result pages! Something that showed the Openverse logo, name of the image, and the license name and icons. Not dissimilar from this tool I built at creative commons, minus the UI: https://cc-og-image.vercel.app/

[dhruvkb]

@AetherUnbound at CC this feature had a frontend but then it was removed. The code stayed but I'm not too sure if we should keep it as it is. @zackkrida's idea to repurpose it for OG images seems like a good way to salvage it and make it somewhat useful.

[sarayourfriend]

I'm going to remove the good first issue label for now. We don't have a clear path forward, I don't think this makes sense as someone's first issue to tackle at the moment... maybe once we have an idea of what we actually want to do we can add the label back or create a new issue with clearer definitions of done.

[sarayourfriend]

@WordPress/openverse-maintainers can we re-prioritize this issue to at least 404 the watermark endpoint?

If we want to build a new feature out of the watermark features (which seems good) let's do that in a separate issue.

[sarayourfriend]

While we wait for someone to update this issue based on the discussion during the weekly dev chat from this week, I will also note that we can easily resolve some issues with this endpoint by adding a try/except around the exif.dump line in the endpoint to prevent errors like this one: https://sentry.io/share/issue/a80d52de7f89436586ed0250cd0a32d2/

This is documented here: #849

[sarayourfriend]

I'm writing the update, given no one else has done so yet.

When thinking about this issue: please keep in mind that if an endpoint exists on a versioned prefix then we have effectively cemented the existence of that endpoint. If we wish to break this contract, then we may do so, but I would ask that we do so with careful consideration and not just to get out of having to fix some issues that appear to be relatively simple bug fixes.

Unless we are prepared to right now commit someone to spending a significant amount of time thinking about and developing an RFC for how we will proceed with API versioning, we should not remove this endpoint. We already have API endpoints that have broken version contracts (deprecated query params without version changes), I do not think we should continue this pattern. In my opinion we do not have the time or expertise to quickly develop an API versioning RFC right now.

In light of that, we should close this issue and solve the handful of bugs in the watermark and oembed endpoints.

[zackkrida]

@sarayourfriend your reasoning in your August 9th update is sound. Should we close this issue now? Please do if so.

[sarayourfriend]

@zackkrida I'm not sure what the bugs are with this endpoint and was never closely keeping track of them. I'll close this issue but I don't know if the bugs are resolved. @dhruvkb could you confirm that all the bugs for this endpoint are documented in different issues, I seem to recall you being involved in a lot of the discussions about these.

[dhruvkb]

The issues for the endpoint (#827 and #849) were closed by various PRs (#903 and #932) so afaik, the problems with the endpoint have actually been resolved.