Nominal size vs. actual image size

[jinliu]

XCursor has the distinction between nominal size and image size. (See XcursorImage in https://www.x.org/releases/X11R7.5/doc/man/man3/Xcursor.3.html)

IIUC, in hyprcursor metadata, e.g. "define_size = 64, image64.png", the "64" is the nominal size. The actual size of "image64.png" is not necessarily 64x64.

For example, KDE's Breeze cursor theme has a nominal size of 24, but pixmaps are all 32x32 (so is the canvas size of source SVGs). I don't know why it was done this way, but it's the status quo.

Then there are two problems:

1. For PNGs, libhyprcursor renders the top-left nominal_size x nominal_size part of the image. So if I use hyprcursor-util to convert the current Breeze cursor XCursor file to hyprcursor format, many cursors would be truncated.

2. For SVGs, libhyprcursor renders the SVG at the nominal size. That would render current Breeze SVG files smaller (at 24x24) than they are designed (32x32) in the 100% scale.

There are two ways to fix this:

1. Require all PNGs and SVGs to be exactly at the nominal size, with no margins as XCursor allows. I can manually remove margins from Breeze SVG files and make them 24x24. But this would mean that converting from XCursor might not work for some cursor themes.

2. Adopt the nominal size vs. actual size idea from XCursor:
   a) Render PNG at its embedded size instead of the nominal size.
   b) Define hotspot as "hotspot_coord / actual_image_size", since it can be greater than the nominal size.
   c) Also define a nominal size of SVGs. E.g. with "define_size = 24, image.svg", and if "image.svg" has a canvas size of 32x32, then libhyprcursor would render a cursor at nominal size 48, by rendering the SVG at size 32x(48/24)=64.

2.c also has the extra benefit that we can have different SVGs for different sizes, like how SVG icons are handled.

[jinliu]

https://invent.kde.org/plasma/breeze/-/blob/master/cursors/Breeze/Breeze/cursors/bottom_right_corner is an example with hotspot at the bottom right corner in the 32x32 pixmap, with a nominal size of 24.

[vaxerski]

SVGs have no size - all SVG cursors are required a size of 0 (in >0.1.5 they are forced to be 0 anyways)

PNGs should be exactly the size they advertise - true. I can add that to docs and enforce in lib.

I don't see a point in having two sizes (nominal and actual)

[jinliu]

That would be fine. Some conversion from XCursor might fail, but I don't think many people will do the conversion just to save space, anyway. SVG is the point.

The other direction - generate a XCursor theme from a hyprcursor theme, seems more useful, as I can deploy a small hyprcursor package to the end user, and in its postinstall script, generate a XCursor theme for compatibility.

[vaxerski]

it's in the todo but I put off doing it as all themes so far have come from x anyways.

[jinliu]

I think I know why Breeze cursors are set in that way:

Left: Adwaita, Right: Breeze, in the same nominal size.

You can see that the main "arrow" part of the Breeze cursor is roughly the same size as the Adwaita one, only the "badge" is outside the nominal size bounds.

So if we set the nominal size of Breeze to the actual 32px instead of the current 24px, the end user would feel that it's "smaller" than Adwaita at the same 32px nominal size.

Anyway, I'll try to set the Breeze nominal size to the actual size. Seems more straightforward this way.