Comment 14 for bug 741804

Vish: "Icons need to be done for their sizes", indeed. This is the point I had attempted to highlight above; my apologies for not having managed to convey that clearly.

  * To be able to hint/draw against a grid, one must first have a grid.
  * To be able to draw a grid, one must know the characteristics of that particular target (dimensions, texel count, texel aspect ratio)
  * To be able to document the characteristics one must know the specific use-case(s).

Not all grids are affine, and not all grids are 1:1 ratio in their cells, and not all grids have the same number of texels in each axis.

Example 1: As an extreme example, the magic on-pitch advertising at televised sports events is drawn (by a human painter with a bucket of paint) against a non-affine, non-linear grid; and that grid is chosen beforehand based on a use-case of one particular camera location, angle and viewpoint. One could, of course, take a random image and scale/transform/interpolate it to fit, but it's not going to be as pretty when seen by the television camera as something optimised for one use-case and painted with carefully-aligned high-contrast edges. (To get it absolutely perfect, ideally one would know the focal-length of the camera lens and the internal CCD pitch too ;-).

Example 2: As another example, to grid fit for something like the OLPC display you would need two grids, one to hint/draw/align the luminance against and another grid to hint/draw/align the coloured-fills. The human designer creating the hinted form would need to have knowledge of both grids in order to be able to draw a completely grid-fitted variant.

Example 3: As a third example, it's only recently that nominally 1:1 ratio displays have been the norm. For most of the 1980s and 1990s people were using VGA cards attached to CRTs and quite often using resolutions with a 1:1.2-ratio pixel ratio. The icons used for games like Doom were all (very) carefully drawn to be grid-fitted against an affine 1:1.2-ratio grid. To draw a circle against such a grid, there are going to be more texels in one axis than the other, but the result when rendered and shown to the game-player appears circular and naturally round. But, rotate that grid-fitted icon 90-degrees and rather than a circle, or slight ellipse, the viewer will now see a quite extreme ellipse. Another example in the same-setting would be the grid-fitted cross-hairs used for targeting. If you use various virtual-machine emulators, you may still see a double-jump in the window size during boot as the device comes up in 640×400.

Text and Icons:
"Fonts and icons are completely different." Perhaps. In the case of the indicators in the panel, they are used as optimised legible replacements for text. Their purposed is to convey information to the user in the best wording possible, which, unless you're visually impaired is often (but not always) an icon—as long as the icon-for-text-replacement used is familiar and predictable to the user. Things like the time and the name of the current user are not replaced by pure-icon forms at the moment because it's less useful to the user and for an analogue wall-clock with very low footprint to information ratio there probably aren't the available pixels for a particularly legible rendering with the pixels available.

Free Software Icon Hinting Infrastructure:
"We still don't have any clever system for icons/svg in GNOME." Quite agreed, the free-software world is lacking an decent rounded-out solution for hinting; both in the interactive tools for interactively-optimising grid-fitted forms, or in the rendering stack to actually execute the rule-set that the design has manually created from their GUI. Both the design tools (eg. modifications to Inkscape) and the rendering stack (Pango, Ft2, rsvg) are likely to end up looking suspiciously-like the manual hinting methods used for existing high-legibility line-art, errr… font glyphs.

(For distribution and simplicity in maintainability, it would probably be convenient if all the outputted forms/metadata would wind up in a single file too. The current Icon Specifications spread it out, with some metadata being in the filesystem structure. Both of the primary competitor desktop operating systems have such an arrangement and have done for a very long time, which helps to keep the association between "an icon" and its available optimised sub-forms more concise and transparent to the user).

Like everything, the problem space must be known and understood to some degree before it can be solved in an ideal fashion; in this case that probably means collating the academic work that has been done on the topic. Perhaps it's something to raise on the Ayatana-list as a future project focus once some of the shorter-term goals are solved for the Free Software stack. I could raise it myself, but I think it has more weight if somebody like yourself takes the time to raise it; if you know of any academic researchers, departments or papers on the subject then that would be something that could be brought up at the same time. Doing this at a high-level on Ayatana would help to keep the conversation in one place (and still in the open), rather than us both subverting this bug report to do that or resorting to off-line methods.

Workspace Icon:
The new symbolic icon for the window-switcher was a feature request. Specifically regarding the workspace-switcher-icon looking blurry in the screenshot: Yes. There is a bug here. The bug is that an optimised/hinted ("grid fitted") version was not available for the target grid required. It was not available because it had not been drawn. The solution (for the instance in the provided screenshot) is to have a human draw a variant for the target grid in question, which I believe is a grid of 48x48 1:1 ratio texels and then also ensuring that the matching "height/width" set correctly in the opening <svg> tag (see the note at the end). "Daniel Fore, who has been contracted … to "fix" so many icons … with such alignment problems". I'm sure Daniel and yourself will be excellent at ensuring that additional bug-fixing gets done! (Bug fixing broken stuff != brand new pre-UI Freeze Feature request for new shiny).

SVG width/height:
As a side-issue the SVG currently contains: height="65.312" width="65.312" owing, which is I presume a result of my quick use of Inkscape's "crop to selection" also taking account of the width of the hairline stroke of the outline slightly going over the 64x64 pixel grid that I suspect Rosie had had in-mind (purely from those numbers) when drawing. Fixing this is also a bug, rather than a feature-request and something that is perfectly reasonable to do in a controlled manner post UI-freeze.

Perhaps at the distro/upstream level, I think it might be useful to incorporate a unit-test in the build-process that checks that SVG hinted versions provided in certain directories at least claim to be same size to be a sub-multiple of that fixed size that their filename/directory location portrays. I'm happy to do this if you also think it would be useful, to help try and sanity-check what goes in a bit better; if for no other reason than to catch my own fat-fingers! :-)