<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Resolution Independent Fever</title>
	<atom:link href="http://www.red-sweater.com/blog/223/resolution-independent-fever/feed" rel="self" type="application/rss+xml" />
	<link>http://www.red-sweater.com/blog/223/resolution-independent-fever</link>
	<description>Mac &#38; Technology Writings by Daniel Jalkut</description>
	<pubDate>Sun, 12 Oct 2008 02:26:37 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: Fred</title>
		<link>http://www.red-sweater.com/blog/223/resolution-independent-fever#comment-45657</link>
		<dc:creator>Fred</dc:creator>
		<pubDate>Fri, 19 Jan 2007 12:48:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.red-sweater.com/blog/223/resolution-independent-fever#comment-45657</guid>
		<description>I have noticed a lot of discussion about why having an entirely vector interface would be a bad idea. For example at small icon sizes, where handplaced pixels are more eloquent than interpolated ones.

It is very rash to take this black and white approach and imagine taking place a transition from bitmaps' pros and cons to vectors' pros and cons. The reality will likely turn out to be the best of both. Small icon sizes do not need to be appear at multi-megapixel sizes, and it would be redundant to allow them to.

Also, this discussion does not have a large impact on Mac OS X Icons either. They have been resolution independent since OS X was introduced. And they bring a relevant hint as to the future of things to come. Namely, for large sizes the icon is interpolated on the fly; when the icon is shown smaller the system uses a set versions of the icon tailored for use at that size.</description>
		<content:encoded><![CDATA[<p>I have noticed a lot of discussion about why having an entirely vector interface would be a bad idea. For example at small icon sizes, where handplaced pixels are more eloquent than interpolated ones.</p>
<p>It is very rash to take this black and white approach and imagine taking place a transition from bitmaps&#8217; pros and cons to vectors&#8217; pros and cons. The reality will likely turn out to be the best of both. Small icon sizes do not need to be appear at multi-megapixel sizes, and it would be redundant to allow them to.</p>
<p>Also, this discussion does not have a large impact on Mac OS X Icons either. They have been resolution independent since OS X was introduced. And they bring a relevant hint as to the future of things to come. Namely, for large sizes the icon is interpolated on the fly; when the icon is shown smaller the system uses a set versions of the icon tailored for use at that size.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jimi</title>
		<link>http://www.red-sweater.com/blog/223/resolution-independent-fever#comment-38330</link>
		<dc:creator>Jimi</dc:creator>
		<pubDate>Thu, 28 Dec 2006 01:31:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.red-sweater.com/blog/223/resolution-independent-fever#comment-38330</guid>
		<description>what about java apps. Are the going to be left behind. Is this just cocoa thing or will the Java boys be able to play zoom zoom too?</description>
		<content:encoded><![CDATA[<p>what about java apps. Are the going to be left behind. Is this just cocoa thing or will the Java boys be able to play zoom zoom too?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter Hosey</title>
		<link>http://www.red-sweater.com/blog/223/resolution-independent-fever#comment-32257</link>
		<dc:creator>Peter Hosey</dc:creator>
		<pubDate>Sat, 09 Dec 2006 23:44:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.red-sweater.com/blog/223/resolution-independent-fever#comment-32257</guid>
		<description>No, zoom enlarges a section of the screen to fill the screen. The UI scale makes all the objects on the screen (menu bar, menus, windows, controls, text) bigger.</description>
		<content:encoded><![CDATA[<p>No, zoom enlarges a section of the screen to fill the screen. The UI scale makes all the objects on the screen (menu bar, menus, windows, controls, text) bigger.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jj</title>
		<link>http://www.red-sweater.com/blog/223/resolution-independent-fever#comment-29172</link>
		<dc:creator>jj</dc:creator>
		<pubDate>Tue, 28 Nov 2006 14:48:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.red-sweater.com/blog/223/resolution-independent-fever#comment-29172</guid>
		<description>".. but you will be able to change the entire UI scale, which will increase the size of everything, including fonts."

Wouldn't this be the same as the current zoom feature, resulting in the edges of the zoomed screen to be hidden? If yes, it is not a good solution for the font size problem.</description>
		<content:encoded><![CDATA[<p>&#8220;.. but you will be able to change the entire UI scale, which will increase the size of everything, including fonts.&#8221;</p>
<p>Wouldn&#8217;t this be the same as the current zoom feature, resulting in the edges of the zoomed screen to be hidden? If yes, it is not a good solution for the font size problem.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marc Edwards</title>
		<link>http://www.red-sweater.com/blog/223/resolution-independent-fever#comment-28914</link>
		<dc:creator>Marc Edwards</dc:creator>
		<pubDate>Mon, 27 Nov 2006 05:12:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.red-sweater.com/blog/223/resolution-independent-fever#comment-28914</guid>
		<description>"Will I be able to change the font size system-wide?"

I can't answer that, but you will be able to change the entire UI scale, which will increase the size of everything, including fonts.</description>
		<content:encoded><![CDATA[<p>&#8220;Will I be able to change the font size system-wide?&#8221;</p>
<p>I can&#8217;t answer that, but you will be able to change the entire UI scale, which will increase the size of everything, including fonts.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jj</title>
		<link>http://www.red-sweater.com/blog/223/resolution-independent-fever#comment-28005</link>
		<dc:creator>jj</dc:creator>
		<pubDate>Thu, 23 Nov 2006 04:35:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.red-sweater.com/blog/223/resolution-independent-fever#comment-28005</guid>
		<description>Great article! I am still wondering though if RI will finally solve the tiny font problem used in so many MAC applications? 

Will I be able to change the font size system-wide?</description>
		<content:encoded><![CDATA[<p>Great article! I am still wondering though if RI will finally solve the tiny font problem used in so many MAC applications? </p>
<p>Will I be able to change the font size system-wide?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marc Edwards</title>
		<link>http://www.red-sweater.com/blog/223/resolution-independent-fever#comment-27310</link>
		<dc:creator>Marc Edwards</dc:creator>
		<pubDate>Mon, 20 Nov 2006 12:51:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.red-sweater.com/blog/223/resolution-independent-fever#comment-27310</guid>
		<description>Jon: I hope my post came across as tongue-in-cheek... that was the intention :)

I agree though. A file format like ICNS that can handle vectors would solve everything and be a welcome addition to any developer or designer's toolset.</description>
		<content:encoded><![CDATA[<p>Jon: I hope my post came across as tongue-in-cheek&#8230; that was the intention :)</p>
<p>I agree though. A file format like ICNS that can handle vectors would solve everything and be a welcome addition to any developer or designer&#8217;s toolset.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jon A. Cruz</title>
		<link>http://www.red-sweater.com/blog/223/resolution-independent-fever#comment-27265</link>
		<dc:creator>Jon A. Cruz</dc:creator>
		<pubDate>Mon, 20 Nov 2006 08:54:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.red-sweater.com/blog/223/resolution-independent-fever#comment-27265</guid>
		<description>Adding to Marc's "two categories" comment, I'd like to enter a third.

#3 Pro multi-image = people who program *and* work with graphics.


Avoid the problem of trying to force things into a false dichotomy. SVG 1.2 though still in final wrap up phases, has added a "multiImage" element. This allows for all or parts of a single file to be matched by DPI, much as game textures use level of detail to swap in versions.

This will allow a designer to create vector versions for higher res icons, but still targeted to size ranges. For example, an icon might render as a single letter at smaller sizes, but a complex image with multiple parts at a larget size.

Also, the smaller size versions could drop to pure bitmap and allow for all the hand-tweaking that icon authors usually need.


Even if SVG render support for this is not widely adopted, it is still a useful solution. Inkscape ( http://www.inkscape.org/ ) is one of the more popular SVG editors and has been adding various icon support features. Even if target platforms don't support SVG with multiImage, an artist could use Inkscape to work in a single file for all versions and then batch export needed vector or bitmaps for final format.</description>
		<content:encoded><![CDATA[<p>Adding to Marc&#8217;s &#8220;two categories&#8221; comment, I&#8217;d like to enter a third.</p>
<p>#3 Pro multi-image = people who program *and* work with graphics.</p>
<p>Avoid the problem of trying to force things into a false dichotomy. SVG 1.2 though still in final wrap up phases, has added a &#8220;multiImage&#8221; element. This allows for all or parts of a single file to be matched by DPI, much as game textures use level of detail to swap in versions.</p>
<p>This will allow a designer to create vector versions for higher res icons, but still targeted to size ranges. For example, an icon might render as a single letter at smaller sizes, but a complex image with multiple parts at a larget size.</p>
<p>Also, the smaller size versions could drop to pure bitmap and allow for all the hand-tweaking that icon authors usually need.</p>
<p>Even if SVG render support for this is not widely adopted, it is still a useful solution. Inkscape ( <a href="http://www.inkscape.org/" rel="nofollow">http://www.inkscape.org/</a> ) is one of the more popular SVG editors and has been adding various icon support features. Even if target platforms don&#8217;t support SVG with multiImage, an artist could use Inkscape to work in a single file for all versions and then batch export needed vector or bitmaps for final format.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marc Edwards</title>
		<link>http://www.red-sweater.com/blog/223/resolution-independent-fever#comment-27192</link>
		<dc:creator>Marc Edwards</dc:creator>
		<pubDate>Mon, 20 Nov 2006 01:48:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.red-sweater.com/blog/223/resolution-independent-fever#comment-27192</guid>
		<description>At the risk of splitting those for and against into "us" and "them"... it seems like everyone's opinion falls neatly in to two categories.

#1 - Pro vectors = developers who love the idea of having one file that works for any situation and is completely future proof.

#2 - Pro bitmaps = designers who have actually worked with vectors and realise what a complete abortion the process can be at times!

Obviously Craig Hockenberry doesn't fit into that sweeping generalisation. I like to think of Craig as a "designer sympathiser" :P

Seriously folks, vectors are trouble! YOU HAVE BEEN WARNED!!!!</description>
		<content:encoded><![CDATA[<p>At the risk of splitting those for and against into &#8220;us&#8221; and &#8220;them&#8221;&#8230; it seems like everyone&#8217;s opinion falls neatly in to two categories.</p>
<p>#1 - Pro vectors = developers who love the idea of having one file that works for any situation and is completely future proof.</p>
<p>#2 - Pro bitmaps = designers who have actually worked with vectors and realise what a complete abortion the process can be at times!</p>
<p>Obviously Craig Hockenberry doesn&#8217;t fit into that sweeping generalisation. I like to think of Craig as a &#8220;designer sympathiser&#8221; :P</p>
<p>Seriously folks, vectors are trouble! YOU HAVE BEEN WARNED!!!!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daniel Jalkut</title>
		<link>http://www.red-sweater.com/blog/223/resolution-independent-fever#comment-27081</link>
		<dc:creator>Daniel Jalkut</dc:creator>
		<pubDate>Sun, 19 Nov 2006 15:08:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.red-sweater.com/blog/223/resolution-independent-fever#comment-27081</guid>
		<description>Hi Marc - thanks for writing that. Great points - especially about "vectors are easy to botch" - boy don't I know it :)</description>
		<content:encoded><![CDATA[<p>Hi Marc - thanks for writing that. Great points - especially about &#8220;vectors are easy to botch&#8221; - boy don&#8217;t I know it :)</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.294 seconds -->
