[wish] new "boxmodel" for grid alignment (1pixel border issue)

There exist two bounding box modes (visual bbox, geometric bbox), and snapping allows to snap either bounding boxes (which include stroke-width if bounding box mode is set to 'visual') or nodes/handles (default snap mode, snaps nodes to grid). What would be the use case for a third bounding box model ("Inside coordinates")?

CONTEXT:
SVG says the stroke will be 50% in the shape and 50 % outside. This is nor good nor bad, this is a choice and we have to go with it.
This choice has (dis)advantages like IE box model vs W3c box model and if does the border width count in element width.

PROBLEM :
Strokes look blurry when their sizes are (2n+1) pixels (see pixelsnap addin) because they don't fill "complete" pixels but rather 50%.
There would be no (less) problem if the stroke was drawn OUTSIDE of the shape.

(not a practical) SOLUTION? :
all shapes should be offseted by 0.5 px so that the stroke fills a complete pixel.

Offseting could be done more efficiently by using a grid but no combination of grid snaping looks effective to me :

eg:

new 32*32px document
new grid 1*1 starting @ 0,0 maingrid @ 5,5

Bounding Box
============
snap to bounding box = true
snap to nodes = false

draw a rect with a 1 px border
=> Bad : the first point isn't grabbed by grid.

resize(if visual)
=> Good : the border fits in a full pixel
resize(if geometric)
=> Bad : the border spread over 2 pixels

draw a complex shape with a 1 px border and try to move a node
=> Bad : node isn't aligned [because snap to nodes is off]

Snap to node
============
snap to bounding box = flase
snap to nodes = true

draw a rect with a 1 px border
=> Bad[*] : the first point is grabbed by grid at integer coordinates x,y so the border spread over two pixels (50% inside the shape, 50% outside the shape)

resize
=> Bad : the border spread over 2 pixels

draw a complex shape with a 1 px border and try to move a node
=> Bad : node is grabbed by grid at integer coordinates x,y so the border spread over two pixels

One could go with 0.5,0.5 grid and snap to node, but if you draw shapes with no (or 2n+0px) border the shapes may fall in between pixels.

THE MOST EFFECTIVE :
Visual bounding box works rather well for rectangle, but I don't want to snap only corner of a rectangle but all nodes of a complex shape.

So I propose to extend the visual concept from bounding box to shape. In this mode, all nodes would be offseted using a erosion of 0.5*stroke width
and so
the stroke would look like it is outside of the shape and
nodes will look like being at the fronteer with the stroke instead of being in the middle.

If there are straight horizontal/vertical lines in your complex shape and you grid-align your nodes, then the stroke will be 100% perfect

The underlying coordinates of nodes will still be in svg mode but their display on screen will be faked (like coordinates for the visual bounding box)

ANOTHER SOLUTION
that solves less problems but is simpler : add an option so that when the stroke width is a straight (2n+1) multiple of grid size then the nodes are not aligned on integer coordinates but at x+0.5*gridwidth

You know that you can add a second grid and offset its origin e.g. by (0.5px,0.5px) already?

see also:
http://www.inkscapeforum.com/viewtopic.php?f=5&t=1973&p=18799#p18798
http://mso-chronicles.blogspot.com/2008/06/echo-icon-common-mistakes-blurry-icons.html

Setting status to 'Confirmed' because this is a recurring question for many users and currently available tools or workflows lack support of e.g. scaled or uneven stroke widths.

I think it's a more complex that just setting the origin to 0.5.
This will do the trick for (2n+)1px stroke but will fail (=will be of no practical use) for (2n+)0px border.

> I think it's a more complex that just setting the origin to 0.5.
See comment #5.

> (…) but will fail (=will be of no practical use) for (2n+)0px border.
Those can be snapped to the original grid (you can use _multiple_ grids in the same document).

> you can use _multiple_ grids in the same document

Setting a grid of XYWH 0.5 0.5 1 1 plus a grid of XYWH 0 0 1 1 will be rather useless, no ?
Unless you can easily (un)activate one or the other without going to the prefs menu. And probably the keyboard shortcut (if any) won't work with non-us keyboard [zoom shortcuts don't work with FR or DE keyboards]

<off-topic>
> [zoom shortcuts don't work with FR or DE keyboards]

Most likely this is bug #167796 "zoom keys (shortcuts) 3,4,6 on numeric pad not working"
See comment #9 for details how to add the numpad keys to the list of keymappings as workaround
</off-topic>

>off-topic continued>
I might be mistaken and actually it is bug #181393 “View shortcuts don't work on french keyboard” which IMHO is not a duplicate of bug #167796 but more related to bug #165755 (and bug #266913).

Using a MacBook with a de_CH keyboard layout I have similar issues with (different) default shortcuts (|, #, [, ], <, >, etc.). For those shortcuts that are important in my workflow and that don't bypass the configurable keyboard mapping I have created custom keybindings file in my user profile for Inkscape (~/.config/inkscape/keys/default.xml).

See <http://wiki.inkscape.org/wiki/index.php/Release_notes/0.44#Configurable_keyboard> on details how to create a custom keybindings file in the user Inkscape profile to override the default shortcuts that assume a US keyboard layout. The default file 'share/keys/default.xml' has additional helpful comments.
</off-topic>