Since an initial artwork's icon is now available, it is possible to add the missing sizes to the png icon set, as well as provide an icon in svg format.

Additionally, since the existing source for the desktop icons already uses svg format (suite/branding/seamonkey/icons/svg/), the correspond gtk and/or other icon set can be provided in svg as well.

Current icons of sizes 16, 32, 48 and 64 seem were produced from another source, or some manual intervention was made.
If you make them just out of the svg present, they look a little worse (because of the "dumb" scaling). (This is similar to how small fonts often require manual override).
All looks fine for sizes 128+ however. :) .

The icon set provided in bug #1362210 looks as produced exactly from the same svg (ie. differs from the present ones as well).

Currently the missed sizes are 22, 24 and 256 (comparing to Firefox).
There is no problem to add size 256 (and above), but it is advisable to find a better source for sizes 22 and 24.

The "default" icon set.

Currently Firefox provides sizes of 16, 22, 24, 32, 48, 64, 128 and 256.
SeaMonkey provides 16, 32, 48, 64 and 128, and the size of 32 is a bit misaligned.

Thus the plan is:

First, rename default.png to default32.png for consistency (as in Fx) at least in the source code.
Then shift 32x32 by one pixel to left for better centering.

Then:

16x16     default16.png
22x22     convert default32.png -scale 22x22 default22.png   (ImageMagic)
24x24     convert default32.png -scale 24x24 default24.png   (ImageMagic)
32x32     default32.png
48x48     default48.png
64x64     default64.png
128x128   export by Inkscape to 1024x1024, then scale by ImageMagic to 128x128
256x256   export by Inkscape to 1024x1024, then scale by ImageMagic to 256x256
512x512   export by Inkscape to 4096x4096, then scale by ImageMagic to 512x512
1024x1024 export by Inkscape to 4096x4096, then scale by ImageMagic to 1024x1024

The sizes of 512 and 1024 can be avoided in a standalone form, since they are requires for .icns format only.

Windows icons:

Firefox provides a file in the .ico format, "firefox.ico", which has icons of 16, 32, 48 and 256 .

Additionally, there ia a file "firefox64.ico" (appeared as a result of bug #1328445 part1), which has the same icons of 16, 32 and 48, and an icon of 64 (instead of 256). But probably it does not make sence for SeaMonkey anyway.

SeaMonkey does not provides any .ico logo file for now.
Thus the icons defailt16.png, default32.png (just shifted), default48.png and default256.png (just prepared form svg) can go to seamonkey.ico

Mac icons:

Firefox-56 provides firefox.icns with sizes of 16, 32, 128, 256, 512 and 1024. Latest Firefox seems to drop the size of 128.

Propably defaults 16, 32, 128, 256,512 and 1024 go to seamonkey.icns.

Proposed SVG icon file to be placed in the source for the official SeaMonkey logo.

Being text xml file, has proper copyright comments (MPL-2.0) and links.

I believe the standalone default512.png and default1024.png can be omitted, since the svg icon is already present. These pngs are required as .icns sources only.

For complecity, it seems better to provide icons/gtk/main-window the same way as other icons in that dir, ie:
icons/gtk/main-window.png copied from default32.png ,
icons/gtk/main-window16.png from default16.png ,
icons/gtk/main-window48.png from default48.png
icons/gtk/main-windowScalable.svg from seamonkey.svg
and drop other main-window's pngs (due to svg present anyway).

System menu under Mate Desktop does not show the svg icon, when It has more than 192 characters in comments outside the main "<svg...> </svg> section. Old Gnome2 affected as well, probably other Linux desktops too.

The same svg icon is shown correctly in all other cases (except the main menu).

It seems like we've caught a problem that no one else has encountered before. (Just no one tried to provide the full copyright statement in the svg file).

Fortunately, there is no such a restriction when the comments are placed a bit below -- fe. just after the initial <svg .....> statement.

Thus the solution is to split the text into two parts, one placed as before, other goes below. And a bit shrinked as well.

The v2 is attached.

Well, it is a general, but simple issue.

To autodetect the image type (not by name suffix), a small amount of bytes are read from the beginning of the file.

For svg format, the key element is "<svg". If, due to a large initial comment, this element moves too far, no one will understand what kind of file it is.

For the gdk-pixbuf2 library (used by gtk2/gtk3 under Linux), such an amount of bytes seems to be 256.
Most Linux svg icons have headers like:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg

which fits into 128 bytes.

There is a kludge possible -- just put "<svg>" somewhere in the comment (but in [0, 256]).

I'm thinking whether it could be more reliable to provide the header as in example above, and put all the big copyright comment immediately after the "<svg....>". This way it still will be seen as a header.

Any thoughts?

Looking at other svg files in m-c, they either have no headers or are of the form:

<!-- This Source Code Form is subject to the terms of the Mozilla Public
   - License, v. 2.0. If a copy of the MPL was not distributed with this
   - file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
<svg

The mention of Official SeaMonkey logo can be moved to within the svg tag.

217 bytes, plus the initial "<?xml ......>" takes some. It's too close to 256 limit.

Probably most cases just not affected, since never used under autodetection.

But all the icons we prepare here are mainly for desktop integration. In general, they will be in the system in a common set with icons of other applications, of arbitrary format. As a rule, in such cases, format autorecognition is used. It will be a little risky to keep everything close to the empirical limit, which can change unpredictably in the future.

Maybe just move all the comments under the svg tag?

For the additional svgs (for gtk/*.svg) I just shortened the statement as:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!--
    This Source Code Form is subject to the terms of the Mozilla Public
    License, v. 2.0 License, v. 2.0 (see http://mozilla.org/MPL/2.0/).
-->
<svg

esp. since the phrase "If a copy of the MPL was not distributed with this file" sounds stupid.

The one I quoted is the standard boilerplate for files in the mozilla repos.
An example file is:
https://searchfox.org/comm-central/source/mail/branding/thunderbird/TB-symbolic.svg
As far as I am aware the file doesn't need the <?xml version="1.0" encoding="UTF-8" standalone="no"?> part.
Potentially

<!-- This Source Code Form is subject to the terms of the Mozilla Public
   - License, v. 2.0 (see http://mozilla.org/MPL/2.0/). -->
<svg

is okay but needs checking with Mozilla (I'm waiting to find out who now covers such things).

Another option is to put a LICENSE file in the directory - see https://www.mozilla.org/en-US/MPL/headers/ - and then no license header is needed in the file itself.

TB-symbolic.svg seems to be suitable for icons/hicolor/symbolic (not familiar with it yet), rather than icons/hicolor/scalable .

Anyway, all (about 2000) the Linux svgs I've found under /usr/share/icons have the "<?xml" header.

OTOH xml specs say that "XML documents SHOULD begin with an XML declaration", rather than must ...

If we intend these svg icons to be used under Linux/UNIX desktops, they should follow the accepted de-facto behavior there. So let's preserve the xml header.

BTW, I've found one example with the full copyright statement provided -- it is emacs.svg icon of Emacs editor. Probably we should do something similar.

New variant with all the comments moved after the <svg ...> statement (follows the emacs example above).

Preserve the text in exact form required by https://www.mozilla.org/en-US/MPL/headers/, just a bit reformatted to be shown clean.

Looks good to me. Thanks.

buc with Bug 1362210 fixed are we good here for now or are there still issues? I lost track somewhat.

Well, pngs are updated and completed, svgs are placed in the source (and can be used by distros for the desktop icons etc.). So you are good here.

Thanks. I think I just dupe it to Bug 1362210.
If something else comes up we file a new bug.