On Wed, Dec 26, 2007 at 04:49:21PM +0100, Maximilian Albert wrote:

I gather that multiple degrees of precision are used throughout Inkscape. Grids allow 4 digits, guidelines 3, but document size (for example) only provides 2. I haven't checked all the other places but I'm wondering if it would make sense to unify all these.

It probably would make a lot of sense to come up with a more systematic method of dealing with precision.

Isn't having different precisions simply inconsistent and annoying for users who need high precision for their work? Would this be a difficult/time consuming change or do people think it is something that can be achieved (or is desirable at all) for 0.46?

I think it would be a good thing to aim for post-0.46. This feels more like a feature change than like a bug fix, and in any case I suspect it could get thorny.

A couple years ago I briefly poked into the precision stuff when I worked on units, but at that time the code didn't seem to be well abstracted; unit-handling assumptions were peppered through the code and would need significant refactoring in order to enforce consistency effectively.

In this case, what would be a good level of precision? Is there any reason not to provide 4 digits everywhere (apart from space considerations, maybe)?

There's several different spots where precision can come into play:

* Internal calculations (rounding/snapping) * UI widgets * SVG/PDF/etc. output

For internal calculations, it would seem logical to simply allow the maximum precision possible. The only area where some exceptions to this might make sense are when doing always-snap; however I assume the snapping code would take care of proper rounding here.

For UI widgets, the text-edit widgets should probably permit any level of precision necessary I guess. It may look more consistent if they always provided space for three decimal points or something. I suspect where precision is going to show up the most is with spinners - should they increment by 0.01, 0.001, etc.? I'm not sure that's something that can be easily standardized; it depends a lot on the usage situation.

For SVG output, the situation becomes much trickier. I think there are multiple use cases that conflict in what they'd like to have:

* Artistic SVG: In these cases, precision is more or less irrelevant, and they'd prefer that points lay where they lay, even if it takes 8 decimals to pin them down. No precision trimming should be going on.

* Technical SVG: Diagrams, maps, charts, and so on generally need some particular level of precision (or significant figures). Setting precisions can be tricky to get right in this case, but can add a lot of value to the application if done correctly. In general, 4 or 5 digits of precision should be sufficient. However this can be very dependent on the scale and unit system in use.

* Web SVG: For web-oriented SVG output, file size is the principle concern, and generally precision is unimportant. Having more than a couple digits of precision is usually excessive and will just be bloat. Again, though, this can be application-dependent - an SVG web page intended to be scaled in and out deeply could require different precision than a static un-zoomed drawing.

Unfortunately, if we were to simply handle precision snipping at the output phase, we get into an ugly situation where what you save may looks subtly different from what you'd been drawing.

So... Unfortunately it doesn't seem like we could take a simple solution (like clip all numbers to 4 digits of precision). I think we'd need to really look at the underlying things that are demanding higher (or lower) precision levels, and identify if there's better approaches to achieving those goals.

For instance, the Web SVG use case is really at heart a "make SVG less verbose" desire. A user-controllable tool to "condense" the SVG may be handy here. But for the technical use case, a smarter grid/snapping approach may give a better all-around solution.

Anyway, I've probably gone into a lot more depth than necessary, but hopefully this gives good background if nothing else.

Bryce

I hope this hasn't been discussed before or I'm touching on a sensitive issue. Just wondering.

Max