<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Multiple font weights via CSS 3 and more font fun</title>
	<atom:link href="http://ajaxian.com/archives/multiple-font-weights-via-css-3-and-more-font-fun/feed" rel="self" type="application/rss+xml" />
	<link>http://ajaxian.com/archives/multiple-font-weights-via-css-3-and-more-font-fun</link>
	<description>Cleaning up the web with Ajax</description>
	<lastBuildDate>Thu, 17 May 2012 07:43:39 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: CaptainN</title>
		<link>http://ajaxian.com/archives/multiple-font-weights-via-css-3-and-more-font-fun/comment-page-1#comment-274670</link>
		<dc:creator>CaptainN</dc:creator>
		<pubDate>Fri, 24 Jul 2009 23:26:46 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=7134#comment-274670</guid>
		<description>I wrote about a similar way to protect fonts a while back, talking about how you can really only protect against the casual pirate with these kinds of techniques. Someone could easily pirate a file from a server (like a font or an image), even if they don&#039;t posses the necessary knowledge to get an embedded font to install in the system, if it is encumbered in some way, like being in EOT or SVG format, encoded in a dataURL. That kind of protection is a lot more reasonable for font sellers to ask for, than something like heavy handed DRM. Other forms of content on the internet (video, graphics, music, etc.) posses the same kind of protection since they are generally heavily edited and compressed before they are used.

http://www.unfocus.com/projects/2009/04/22/the-third-option-for-html-font-embedding/</description>
		<content:encoded><![CDATA[<p>I wrote about a similar way to protect fonts a while back, talking about how you can really only protect against the casual pirate with these kinds of techniques. Someone could easily pirate a file from a server (like a font or an image), even if they don&#8217;t posses the necessary knowledge to get an embedded font to install in the system, if it is encumbered in some way, like being in EOT or SVG format, encoded in a dataURL. That kind of protection is a lot more reasonable for font sellers to ask for, than something like heavy handed DRM. Other forms of content on the internet (video, graphics, music, etc.) posses the same kind of protection since they are generally heavily edited and compressed before they are used.</p>
<p><a href="http://www.unfocus.com/projects/2009/04/22/the-third-option-for-html-font-embedding/" rel="nofollow">http://www.unfocus.com/projects/2009/04/22/the-third-option-for-html-font-embedding/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Schill</title>
		<link>http://ajaxian.com/archives/multiple-font-weights-via-css-3-and-more-font-fun/comment-page-1#comment-274660</link>
		<dc:creator>Schill</dc:creator>
		<pubDate>Thu, 23 Jul 2009 16:19:10 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=7134#comment-274660</guid>
		<description>I didn&#039;t realize it when poking around yesterday, but the Typekit guys had just written a nice post the day before on &lt;a href=&quot;http://blog.typekit.com/2009/07/21/serving-and-protecting-fonts-on-the-web/&quot; rel=&quot;nofollow&quot;&gt;how their service works&lt;/a&gt;, and their protection scheme (referrer checking, base64-encoded data URIs, and &quot;segmenting&quot;). Also, see &lt;a href=&quot;http://forabeautifulweb.com/blog/about/first_impressions_of_typekit/&quot; rel=&quot;nofollow&quot;&gt;First impressions of Typekit&lt;/a&gt;.
&#160;
Given the &quot;open&quot; web nature, I think it&#039;s interesting to see companies trying to protect assets like fonts online on top of the @font-face standard. There is also a proposal for a &lt;a href=&quot;http://ilovetypography.com/2009/07/20/web-fonts-%E2%80%94-where-are-we/&quot; rel=&quot;nofollow&quot;&gt;.webfont standard&lt;/a&gt;, which would include another form of permission-based protection. Will be interesting to see where it all goes.</description>
		<content:encoded><![CDATA[<p>I didn&#8217;t realize it when poking around yesterday, but the Typekit guys had just written a nice post the day before on <a href="http://blog.typekit.com/2009/07/21/serving-and-protecting-fonts-on-the-web/" rel="nofollow">how their service works</a>, and their protection scheme (referrer checking, base64-encoded data URIs, and &#8220;segmenting&#8221;). Also, see <a href="http://forabeautifulweb.com/blog/about/first_impressions_of_typekit/" rel="nofollow">First impressions of Typekit</a>.<br />
&nbsp;<br />
Given the &#8220;open&#8221; web nature, I think it&#8217;s interesting to see companies trying to protect assets like fonts online on top of the @font-face standard. There is also a proposal for a <a href="http://ilovetypography.com/2009/07/20/web-fonts-%E2%80%94-where-are-we/" rel="nofollow">.webfont standard</a>, which would include another form of permission-based protection. Will be interesting to see where it all goes.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

