<?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: Welcome, Early Adopters!</title>
	<atom:link href="http://fontstruct.fontshop.com/news/2008/03/30/fontstruct-welcomes-alpha-testers/feed/" rel="self" type="application/rss+xml" />
	<link>http://fontstruct.fontshop.com/news/2008/03/30/fontstruct-welcomes-alpha-testers/</link>
	<description>the FontStruct blog</description>
	<pubDate>Mon, 13 Oct 2008 11:52:46 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: intaglio</title>
		<link>http://fontstruct.fontshop.com/news/2008/03/30/fontstruct-welcomes-alpha-testers/#comment-30</link>
		<dc:creator>intaglio</dc:creator>
		<pubDate>Mon, 26 May 2008 19:05:44 +0000</pubDate>
		<guid isPermaLink="false">http://fontstruct.fontshop.com/news/2008/01/31/fontstruct-welcomes-alpha-testers/#comment-30</guid>
		<description>Thank you for an utterly, utterly brilliant program. During my ride to work I was thinking about the problem of "too many bricks". By adding the quarter-brick shapes to the toolbox, there's a sub-grid level of complexity going on, which I'd love to be able to truly exploit. In a future iteration of the program, how would it be if you could customise bricks to zoom in or out of the grid in quarter-grid steps? Perhaps you would right click an existing brick to access the feature. You'd be able to name it, assign a hot key/s to it even, like InDesign's hotkey function. A preview would appear showing the brick superimposed on the main grid but also showing its quarter-grid subdivisions. Your zoom-up or down customisation would "snap-to" the subdivisions. So there'd be no danger of attempting mathematically illogical shapes. 
Once created, the customised brick would go into the user's "my bricks" palette. This palette would increase in size as it was added to; the main palette would correspondingly shrink.

An added bonus to this scenario would be the ability to do away with redundant bricks friom the toolbox: there'd still be circles, squares, triangles, half-rounds, etc, but their size-relationship to the grid would be in the hands of the user. Therefore, if users wish to create complex geometrical headaches for themselves, they'd only have themselves to blame!

I understand there may be technical reasons why this can't be pursued. You've probably thought of all this. But I write in case you haven't already explored the possibility.</description>
		<content:encoded><![CDATA[<p>Thank you for an utterly, utterly brilliant program. During my ride to work I was thinking about the problem of &#8220;too many bricks&#8221;. By adding the quarter-brick shapes to the toolbox, there&#8217;s a sub-grid level of complexity going on, which I&#8217;d love to be able to truly exploit. In a future iteration of the program, how would it be if you could customise bricks to zoom in or out of the grid in quarter-grid steps? Perhaps you would right click an existing brick to access the feature. You&#8217;d be able to name it, assign a hot key/s to it even, like InDesign&#8217;s hotkey function. A preview would appear showing the brick superimposed on the main grid but also showing its quarter-grid subdivisions. Your zoom-up or down customisation would &#8220;snap-to&#8221; the subdivisions. So there&#8217;d be no danger of attempting mathematically illogical shapes.<br />
Once created, the customised brick would go into the user&#8217;s &#8220;my bricks&#8221; palette. This palette would increase in size as it was added to; the main palette would correspondingly shrink.</p>
<p>An added bonus to this scenario would be the ability to do away with redundant bricks friom the toolbox: there&#8217;d still be circles, squares, triangles, half-rounds, etc, but their size-relationship to the grid would be in the hands of the user. Therefore, if users wish to create complex geometrical headaches for themselves, they&#8217;d only have themselves to blame!</p>
<p>I understand there may be technical reasons why this can&#8217;t be pursued. You&#8217;ve probably thought of all this. But I write in case you haven&#8217;t already explored the possibility.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
