But it does show up in Inkscape as well?
Inkscape? It doesnât show in the reference implementation of EMF, which is Microsoft products: I already mentioned, that it is OK in Word. Inkscape may have its own problems of the same kind, maybe even created by the same backend, which might be some system library - Cairo maybe?
I exported that .emf file to .png and you can see the transparent gap between the rectangles.
The way I understand it, the gap should NOT be there at all as the objects are snapped together. Is there a known solution to this in Linux? I am sure I am not the first person noticing thisâŚ
Did you file it as a bug? Only then you may get an authoritative answer, if there was already such report. And maybe about workarounds.
About Inkscape. This is unrelated at all: try creating and snapping objects there, and see that it shows the same artifact. Thus, it would naturally show it for anything, including documents generated by other software, and would make it not possible to judge about the actual gap/overlap presence.
I tried your file on Windows 10. Opening up the .odg file and zooming in or out, you donât see a line. Even exporting it as .png you donât see it. However, if you export it as .svg, there will be a line
My question is, does this even register as a bug? To me, two snapped files should absolutely not show any gap whatsoever. Is this considered normal from the side of developers?
While I could tolerate a visual glitch in screen rendering, it must not happen in raster export. The PNG export (without Skia / on Linux) is a definite bug.
Wrt SVG - it needs investigating. Inaccuracies when exporting to external formats may occur, but in this case, SVG is capable of using any units, so we should be able to export / import your file perfectly. This would be another bug.
The reason .svg export bothers me is because it completely throws measurements off. If I have 2 rectangles with 15 mm length each and they are snapped together (as in being 15mm away from each other) on a page measuring 30 mm, there shouldnât even be a microscopic line, no matter how much it is zoomed in.
I know that there is no rounding of units here since Draw and Impress 0.01 mm and I am using exactly that. I would like to report this and hope that it will be taken into account. However, I would be surprised if no one hasnât filed this as a bug before.
But I donât see that problem with the exported SVG, when importing it back to Draw.
Well, I tried it both on Windows 10 and Linux. There is a very thin line between the squares, depending on the screen resolution, it might disappear on certain levels of zoom, but it is obvious that the squares havenât connected seamlessly.
Whatâs important is that the SVG export produces squares with width / height of 15.010, as shown in Inkscape (which, in this case, is the reference implementation).
Why does SVG export add extra length to it?
My goal here is simple, if I snap two pieces of same color together, they should have one seamless color, there should be nothing separating them. However, whether it is an .odg file or svg/emf/png file, you can easily see the separation between them. Ideally, without any rendering artifacts or bugs, should snapping create seamless colors though?
Unfortunately, right now this makes it impossible for me to trust the measurement system here.
The âwhyâ is the essence of the SVG export bug. The reason is likely a misunderstanding of open- vs. closed range size, and what is expected at SVG export. The size of the vector rectangle is 15.00 mm; it is from coordinate 0.00 to 15.00. If you consider these coordinates in raster matrix, it would include pixels at 0.00 and at 15.00, which means one more pixel (this is closed range). We often see the mistakes where people miscalculate things, e.g. adding 1 to result of subtracting coordinates, where that is not needed.
And that is different from the display issue you see. Even if there is the same mistake, itâs somewhere else in the code; so please stop implying that you see one bug. Itâs at least two (Iâd say, three, because the rendering on Windows without Skia, and rendering on Linux, are two completely different sets of code).
Note that rendering on screen is tricky in the sense that it definitely paints on a raster surface; it needs to render some vector objects to some coordinates that arise from a multitude of factors like screen resolution, pan position, zoom level. In this case, the correct coordinate of the border between the rectangles may be in the middle of a pixel; the rendering may round to the whole numbers, and create the artifacts on screen because of rounding errors (where it creates less / more intensity in the pixels on the border). We donât care much about this on screen, because itâs more important to be performant, than to spend much time avoiding the artifacts.
And about trusting. You shouldnât trust measurement system here, anyway. We are not CAD. There is no stated goal of providing correct measurements. We should fix bugs, but we donât guarantee against all kinds of rounding errors and the like, beyond some reasonable (in the âoffice suiteâ sense) level.
1 Like
I understand it a little bit better now. So, there is definitely an .svg export bug and we should see a seamless shape and no lines between the squares at any zoom level, right? (which happens in windows 10 as well).
Another bug would be rendering on Linux. I originally thought that if the exported file has a gap, maybe LO Draw was showing me the actual gap and not an artifact. My confusion arises from the assumption that many people use LO on Linux and probably do way more complex stuff than me. So, I am surprised that such a fundamental bug is still unadressed.
And if I do report this as a bug, am I justified in saying that two squares snapped together should show absolutely no gap whatsoever at any zoom level and just have a seamless color?
I tried to describe this several times already. We wouldnât care on screen (we actively not consider it as a bug). It would be a (minor) bug in exported PNGs.
Doesnât this go way beyond just a rendering issue? The gaps show up when a file is exported, both in windows and in linux. This happens in pdf, png, emf, svg. If the problem happened only in linux, Iâd understand. But the exported file shows the gap in windows as well.
My question is that if you do snap to squares together, if there are no rendering artifacts or anything like that, would you expect a visible line between them? My idea is that snapping should be seamless?
Please try to read and comprehend.
You write about zoom level: this is about our display (other apps arenât our concern).
I wrote explicitly, several times:
I also mentioned that itâs a bug in SVG.
What specifically is unclear?
This part
Also, if the exported file shows a gap, doesnât that mean that the source file (in this case, .odg) failed to snap them properly?
We are discussing the rendering artifact.
Re-read my notes about Inkscape. Their bugs is their bugs, so what is shown elsewhere should be checked separately.
I understand that we are discussing the rendering artifact, what I was asking is that in the absence of rendering artifacts, would two squares with a length of 15.00 mm where one is located exactly 15.00 mm away from each other display any gap between them, or should it be seamless? I am starting to think that I am misunderstanding what snapping function is supposed to do. On the other hand, snapping seems to do exactly what I would achieve with manually entering their coordinates.
Regarding inkscape, if I did report it to them, wouldnât they just say that if there is a gap, then that is because of the original document having it and I should make sure that there should be no gap? Mathematically speaking, there is no reason to have a gap, but every exported file shows itâŚ
Ideally, snapped rectangles like yours should not have a line.
You donât even try to read what I wrote (and I wrote about Inkscape, that they show that line even for rectangles created and positioned in the Inkscape itself).