Certain browsers are seemingly not grid-fitting SVG images, resulting in blurry edges which are particularly noticeable for 1px lines; there is no analogous problem with PNG images. Firefox seems to be grid-fitting, while Chrome, Chromium, Edge, and Safari, are presently not. A simple CSS work-around on the figure level is to use display: flex; align-items: center; justify-content: center; flex-direction: column;
See for instance Fig. 23 (Web Access toolbar) and Fig. 24 (Web Access toolbar extra-keys): https://www.cendio.com/resources/docs/tag-devel/html/tlwebaccess_usage.html
Phenomenon reported to Chromium and Webkit: https://bugs.chromium.org/p/chromium/issues/detail?id=1392140 https://bugs.webkit.org/show_bug.cgi?id=248222
For some yet unknown reason, displayed document dimensions in Inkscape do not necessarily transfer to the XML file, but may be off by a tiny margin. For instance, a document width displayed as precisely 100px in Inkscape may save as 99.999997px in the XML file. Some browsers, e.g. Chrome, evidently do not treat this artifact properly and consistently. Making sure these XML parameters are integer numbers facilitates grid fitting in the browser and increases the likelihood that images are rendered sharply.
Chrome quickly fixed their bug, and the issue is indeed gone in a fully updated Chrome (tested version 114). I can still see the issue in an older Chromium 113. Unfortunately, a fully updated Safari still shows the issue. So it looks like we'll still need to do a workaround.
Setting an integer pixel size for both width and height seems to resolve the issue for the browsers. But there is some weird scaling side effect for some images in the PDF. Will need to investigate what's going on there.
Hmmm.... The weird scaling effect is already in the current builds. It seems to be more correct once I fix up the images. One gotcha is the SVG "viewBox" attribute though. It affects how coordinates are interpreted in the document, so it needs to be correct. Ideally it has the same values as the width and height, but that assumes all the coordinates in the document are chosen with that in mind. So it doesn't look like we can enforce that right now. What we can do is make sure the proportions are the same to get a predictable scaling. And avoid any offset.
Works well now. Things look good now in the problematic browsers, without any regressions in the other browsers. The gesture images also have a more consistent size in the PDF now. > MUST: > > * All browsers should render the images as intended (compare with Inkscape at 100% zoom) Yes, as far as I can tell. I've tried Firefox, Chrome, Chromium, Safari, Edge, and Epiphany. > SHOULD: > > * There should be an automatic test enforcing the technical requirements to get correct rendering Mostly. We generate some SVGs from Dia files, and those still have weird dimensions since Dia insists on using cm not pixels. So we exclude those files from testing. Should not be a problem in practice, though, as those images are always scaled and I don't think Dia does any pixel grid fitting anyway.
(In reply to Pierre Ossman from comment #11) > Works well now. Things look good now in the problematic browsers, without > any regressions in the other browsers. The gesture images also have a more > consistent size in the PDF now. Actually, my testing shows the gesture image sizes are less consistent now, at least when compared to 4.14.0. I think the gesture “hands” from 4.14.0 all look quite similar in size. See this comparison image: attachment 1134 [details] Perhaps the statement in comment #11 referred to; “more consistent than before the recent commits”. That also makes sense, since before r40329 it seems we had 3 different sizes of hands in the gesture images. For example: * Large size: single tap * Medium size: two finger tap * Small size: three finger tap At least now, after r40329 we only have two different sizes.. However, due to the current state of things, and the fact that we want to finalize release 4.15.0, we will postpone the fix of this regression. The remaining problem has been broken out to bug 8194.
Aside from the problem broken out to bug 8194, I think things look nice now. I verified both the HTML and PDF versions from build 3325 in Google Chrome, Firefox, and Epiphany on Fedora 38. I checked the SVGs modified in commit r40329. The commits look logical, and the acceptance criteria are fulfilled.
