Freedom Environment (F.E. = effie)
Contemplating alternative logos
and logo enhancements.
FE Home page > This FE 'Logo' Images page
! Preliminary ! More image files MAY be added.
Images ('logos') that represent the Freedom Environment utilities and subsystems are below.
If anyone cares to donate image files (in JPEG or PNG or animated GIF format), I will post them here --- with their permission.
SVG (Scalable Vector Graphics) format may be OK --- if I find that I can display '.svg' files reliably from a web page like this, working around the brain-damaged (for some file formats) 'dance' that web-servers and web-browsers go through in handling media formats out of the ordinary --- that is, media formats other than a few common formats like JPEG, PNG, GIF, animated-GIF, and a few video/audio formats.
Speaking of audio, that reminds me --- an FE theme song or motto might be a good thing to have.
John had a good idea for a theme or motto. (audio)
If the link above does not play, you can try this link to
Time out --- for a rant on web browser 'plug-ins' and 'helper-apps' :
Most browsers do not handle the 'embed' HTML tag well, so I avoid it. ('embed' crashed my web browser, almost randomly --- about 50% of the time, on leaving[!] the web page, AFTER playing an audio file --- NOT when I played the mp3 file with audio player controls embedded in the web page.) And the 'object' tag is just as problematic.
The handling of audio (and other media) by web browsers is really messed up. The browser developers obviously do very little testing of the four pre-HTML5 kinds of audio links referenced above (anchor-tag-to-m3u, anchor-tag-to-mp3, embed-tag, object-tag) --- nor sufficient testing of the two types of playback systems ('plug-in' and 'helper-app'), discussed just below.
is really hosed --- insufficiently tested. It's chiefly the fault of the browser developers --- NOT the media player developers, NOR the varying logic of web servers in downloading files.
There are plenty of good 'stand-alone' audio players on the several main operating systems --- Linux, Mac OS X, MS Windows --- that can serve as stand-alone 'helper applications', on the several popular operating systems.
The browser developers need to get the 'helper application' logic tested out thoroughly --- because the 'stand-alone' players can serve as a fallback if the 'plug-in' type of player is not working well on a particular operating system.
The stand-alone players are always going to be there and be well developed and tested, because they serve as players for the media files located on the local file system of the computer.
The integrated-into-the-browser-window 'plug-in' players are a 'nice-to-have', but the 'stand-alone' players are the 'old reliables'. The priority should always be on getting the 'stand-alone helper app' logic working properly.
Ancient history: I think SGI made a big mistake by making only a 'plug-in' viewer (Cosmoplayer) for VRML2 3D model files --- and no 'stand-alone' VRML2 viewer. If SGI had released the code for a stand-alone VRML2 viewer (like their 'ivview' viewer for Inventor and VRML1 files), it probably would have resulted in a plethora of 'stand-alone' VRML2 viewers runnable on PC's (MS Windows and Linux) as well as on SGI workstations. Then I think we would have seen 3D models in web pages all over the Internet --- from about 2001 onward.
SGI wasted time (resources) in coming up with different plugin interfaces (see the two below) instead of making a stand-alone viewer.
Back to the 'helper-apps' and 'plug-ins' buggy operation issue :
The problem, when you can't play a media file in your web browser, is, ultimately, NOT with your local computer. If you can download the media file and play it on your local computer with a stand-alone app, the problem, ultimately, is the web browser software and, in some cases, the web server configuration --- but your web browser could warn you of the latter.
In fact, here are a couple of web pages that show how 'helper applications' for viewing 3D files behave differently (for various 3D file formats) depending on whether a given web browser is accessing a web page locally or whether the browser is accessing a web page after uploading it to a server.
Quite obviously, browser developers ( Mozilla-Firefox, Mozilla-Seamonkey, Gnome-Epiphany, Midori, MS-IE, etc.) do not do adequate testing of their 'helper application' and 'plug-in' logic in BOTH 'local' and 'remote' web-page install mode.
It's no wonder that Google has created their own web browser. They can't count on Mozilla, Safari, MS Internet Explorer, Opera, et. al. to get 'it' (including helper-apps and plug-ins) right.
Don't let the browser developers distract you with their fingers pointing elsewhere. Give them hell. They've had over 15 years to get helper-apps and plug-ins right.
NOTE: I expect the browser developers won't get the HTML5 'audio' tag working properly either. Instead of the browser developers getting one of the five methods mentioned above (anchor-tag-to-m3u, anchor-tag-to-mp3, embed-tag, object-tag, audio-tag) to work right, I think that we can expect to see a sixth method of implementing an audio file in HTML language specifications by the year 2015. The 'web development people' seem to come up with new tags, rather than fixing the program-logic problems that the web browser programmers have cobbled together for the currently available HTML media tags.
Disgusting! Hey, Mozilla et. al! For starters, just pick one tag --- and the stand-alone 'helper applicaton' method --- and put your best developers on it to get its implementation right. And test it thoroughly (as in 'let the user community test it') in both 'local' and 'remote' mode!
Are you web browser development 'organizations' (I use the term loosely) assigning 'helper application' and 'plug-in' implementation to inexperienced summer interns?? Who the heck is mis-managing helper-app and plug-in development? Put them in charge of making coffee for some good, clear-thinking developers who understand the matrix of elements involved --- namely:
And for humanity's sake, let some good, clear-thinking, knowledgable users test what the developers develop --- and then act on the feedback of those users.
Furthermore, we need a 'Steve Jobs' to 'de-confuse' the helper-apps and plug-ins interface in web browsers --- for example, the 'Edit > Preferences > Browser > Helper Applications' interface in the Mozilla Seamonkey web browser.
Back to the logos :
If any developer/'owner' of the images (or audio snippets) used on this site objects to their use here, I will be glad to remove them.
I made these two animated gifs by using the two
You can move the mouse cursor (pointer) over these images
I may make color or animated-embossed versions of the black-white images above.
The ImageMagick web page on Compound Font Effects offers many ideas and code examples with which to experiment.
The black-white images above are screen captures of the 'Preview text:' option of the 'gnome-specimen' font-viewer utility. 'gnome-screenshot' was used to do the screen captures. 'mtpaint' was used to make embossed versions.
People who are expert in using GIMP, Inkscape, or other art tools could devise variations on these images that include spot-lighted, color-shaded, 3D-looking effects --- or texture-mapped effects.
Since I am no artist and not proficient in the use of such utilities, I will probably not devise any such variations soon. If anyone with those talents wishes to contribute, please do so.
Tile Creation - another 'FE Nautilus Scripts' application example :
As another example of using 'IMAGEtools' of 'FE Nautilus Scripts' --- besides the example of creating a couple of animated GIFs, above, from still-image files --- consider the seamless tile background of this web page.
I made the seamless tile for this page starting with a non-seamless image file of craters :
In the tiled area below, you can see that the image does not 'tile' seamlessly --- some of the craters are 'chopped-off' :
So I applied an 'IMAGEtools' feNautilusScript with a name like
tile02_1-jpgORpngORgif-file_ MAKEpreSmudgeTILE_ via4quads_convert-5times.sh
to the 'craters' file. (The script uses a rather tricky set of parameters on the ImageMagick 'convert' command.)
The script broke the image up into 4 quadrants and pasted them back together into the following file --- with two seam lines across and down the middle of the image. The outer boundaries will now tile seamlessly, but we need to take care of the two seams, horizontal and vertical, across the middle of the image.
I used the 'mtpaint' (MarkTylerPaint) program, available on Linux, to sample the gray color from a pixel in the image file and brush over the seam lines with a 'brush' --- wiping out some of the partial craters that were cut by the seams. That resulted in the following 'seamless' file.
Another approach would have been to use the 'smudge' option of 'mtpaint' to use colors in the area under the brush to 'dynamically' get an 'average' set of colors to use under the brush --- but this would have led to gray 'streaks' on the image. 'Smudging' might work better on some other types of images, such as granite stone --- if you 'dab-smudge' with a small 'brush'.
This is the file that provides the seamless background of this web page --- except that I used the 'Effects > Transform Color ... > Gamma' option of 'mtpaint' to lighten-up the gray color of the image.
So this 'FE Logos' page gives me a chance to show how some of the 'FE Nautilus Scripts' --- in particular, 'IMAGEtools' scripts --- can be used.
I would like to thank the authors of Linux utilities such as 'gnome-specimen', 'gnome-screenshot', 'mtpaint', ImageMagick, and Nautilus --- utilities that make this page possible --- and even easy-to-do.
Bottom of the FE System - 'Logo' Image Files page.
To return to a previously visited web page location, click on the
Back button of your web browser a sufficient number of times.
OR, use the History-list option of your web browser.
Page was created 2011 Jan 31.