[Bug 741804] Re: user-trash.svg and user-trash-full.svg not lens grayscale versions

[Paul Sladen]

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!  :-)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/741804

Title:
  user-trash.svg and user-trash-full.svg not lens grayscale versions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs