Opened 2 years ago

Closed 2 years ago

#23965 closed defect (fixed)

500 internal server error when trying to print svg from metrics graph

Reported by: arma Owned by: karsten
Priority: Medium Milestone:
Component: Metrics/Website Version:
Severity: Normal Keywords:
Cc: irl Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

https://metrics.torproject.org/userstats-relay-country.svg?start=2016-12-01&end=2017-10-24&country=ae&events=points
tells me "Oops! Something went wrong here! We encountered a 500 Internal Server Error when processing your request!"

I assume some backend thing is down. So (a) we should get it back up, and (b) we should figure out some way to automatically recognize if it fails again.

Child Tickets

Change History (16)

comment:1 Changed 2 years ago by arma

The "download as pdf" option works. It's just the "download as svg" that gives the error.

comment:2 Changed 2 years ago by karsten

Owner: changed from metrics-team to karsten
Status: newaccepted

Aha. This error message from R looks related:

Error in loadNamespace(name) : there is no package called 'svglite'

Will investigate later this morning.

comment:3 Changed 2 years ago by karsten

Cc: irl added

irl, can you maybe help debug this issue?

It looks like the CRAN package ggplot2 lists svglite under suggests, but I'm unclear whether the Debian package r-cran-ggplot2 lists svglite as dependency/suggest.

Ideally, we'd install everything we need for R from Debian packages and avoid R's install.packages() for installing into the user's home directory.

comment:4 Changed 2 years ago by irl

svglite is not packaged in Debian as far as I can tell, nor is there any package that contains a file named like svglite so it's probably not included in another package.

There is also no request for package or intent to package bug filed.

comment:5 Changed 2 years ago by karsten

Was it maybe packaged in earlier Debian versions?

Or did we really only use it from R's install.packages() before switching over to using Debian packages only and then simply forgot to test the SVG export?

comment:6 Changed 2 years ago by irl

The Ultimate Debian Database has no knowledge of a package ever having the name "r-cran-svglite" or "svglite", which makes me think it was never there.

It may well have always been installed in the home directory.

If it's useful, I can file an ITP bug and produce a package. It depends on how much effort we think svglite being in Debian is worth (are we going to keep using it for at least 3 years?).

comment:7 Changed 2 years ago by karsten

arma, how critical is it for you to have the SVG format rather than PDF or PNG?

Part of me thinks that it's the first time that somebody notices since we switched to Debian stretch 3 months ago, so it's probably okay to remove the SVG format entirely. But I'd like to hear whether that would hurt anybody more than I currently think.

comment:8 Changed 2 years ago by irl

Is the PDF a vector graphic or is it a bitmap encapsulated in PDF?

comment:9 Changed 2 years ago by karsten

The PDF is a vector graphic. I guess the question is whether the PDF is harder to embed somewhere (slides? reports?) than the SVG. But in theory, there should be ways to convert from PDF to SVG.

comment:10 Changed 2 years ago by irl

Ok cool. I was just thinking to embed it in things it's good to have at least one vector version. This being the case, I personally don't see a reason to not drop the (currently broken) SVG. Maybe arma had a specific use case in mind though.

comment:11 Changed 2 years ago by karsten

Status: acceptedneeds_information

arma, can you describe your use case and why it requires an SVG and not a PDF?

The current plan is to remove the SVG option in order to avoid dependency trouble on the host and under the assumption that most SVG people would just be fine with the PDF option.

comment:12 Changed 2 years ago by arma

My use case is that I want a graph in my slides, so I go to the metrics site, pick out the scenario I want a graph for, click svg, and then in libreoffice, I do an import -> picture and get the svg and then resize it to fill the slide.

This time, I fetched the pdf instead, and did "convert foo.pdf foo.svg" and used that svg.

I think the pdf is different from the (previously generated) svg though -- the font spacing is different, the x axis labels get cut off a bit early, etc.

I had thought that it was the 'convert' program that is messing it up, but now I'm thinking maybe it's the pdf itself that is messed up.

So maybe a way forward is to have somebody with a sense of visual taste look at each of them and tell us which one is more appealing to look at.

comment:13 in reply to:  12 Changed 2 years ago by karsten

Regarding the issue you describe about x axis labels getting cut off a bit early: the reason is that we're changing axis labels without changing margins. I just fixed that by increasing the right margin a bit. This is unrelated to the output format. If you run into similar issues, just file a ticket, and we can tweak such parameters.

Regarding the suspected differences between PDF and SVG output: I just created a PDF and an SVG file locally, and they look almost exactly the same, except that the SVG had a font problem with the 0 on the y axis. But other than that I couldn't spot any differences. To me this means that ImageMagick's convert is to blame for either not parsing the PDF input correctly or not creating an adequate SVG output.

Can you maybe try out LibreOffice's PDF import to import the PDF file directly?

Otherwise we might consider replacing SVG with another format rather than just removing it. The `ggsave` documentation says we can produce: "eps", "ps", "tex" (pictex), "pdf", "jpeg", "tiff", "png", "bmp", "svg" or "wmf" (windows only). Untested, subject to similar dependency issues that we're seeing with SVG right now! If you have any preference for or against one of the formats, please say so!

Another option would be to add a new parameter for the resolution and put a "PNG (high-resolution) link on the website for 2 times or 4 times the current resolution.

comment:14 Changed 2 years ago by karsten

I'd like to remove the SVG format tomorrow. We can still add another format or high-resolution PNG later on. But we shouldn't keep something around that's known to be broken.

Of course, if I have feedback on what other format might be useful by tomorrow, I could replace formats even more easily than remove one format now and add another one shortly after. Let me know!

comment:15 Changed 2 years ago by arma

I like the png idea.

comment:16 Changed 2 years ago by karsten

Resolution: fixed
Status: needs_informationclosed

Great! Replaced SVGs with higher-resolution PNGs. I think this fixes the issue. Closing. Thanks for the report!

Note: See TracTickets for help on using tickets.