<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 11, 2010, at 9:26 AM, Ashley Sheridan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
On Tue, 2010-05-11 at 16:14 +0200, Anne van Kesteren wrote:
<pre>On Tue, 11 May 2010 16:08:01 +0200, Boris Zbarsky <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:
> On 5/11/10 9:39 AM, Ashley Sheridan wrote:
>> Is there really much of a need for this though?
> Good question. What _is_ the use case here, exactly?
E.g. allowing the user to select a font in a text editing or drawing
application. However, for portability it would probably be better if these
were limited to fonts already on the Web.
I agree, portability dictates that they should stick to the few common fonts, or we end up with the same situation I've had countless times where someone sent an MSWord file with all the bullets as some character from the Wingdings font then wonder why people complain that all their bullets are letters.<br>
Embedding the font isn't feasible in this case because you really can't trust the end-user to observe the legal aspects of the fonts they have on their system. The designer of a font may not have given user rights to distribute the font in a document that is publically available like this.<br></div></blockquote></div><br><div>Well, my take is just the opposite. Portability should dictate only if the user wants portability. I don't believe we confine what colors can be picked based upon what is portable.</div><div><br></div><div>People, users, authors, etc learn over time.</div><div><br></div><div>We are seeing with HTML5 and all of its capabilities a real working platform for almost anything. I'm sure there will be ten times as many beasts created from it as beauties but I don't see that as a reason to constrain the possibilities.</div><div><br></div><div>pedz</div><div><br></div></body></html>