Nothing new here. After reading another tidbit on the latest 120 GB Zunes, I remembered an old post I had. Not that big of a deal, but I thought it was interesting to see my prediction come to light.
Retrospectiva en Previsión
No hay nada nuevo aquí. Después de leer otro comentario acerca de la 120 GB Zunes, me acordé un puesto que escribí. El puesto no es muy importante, pero pensé que era interesante que mi predicción se hizo realidad.
If you're interested in what software updates are coming out for Zune 3, check out the collection of videos on Engadget from this morning. There are a few things not mentioned, like the games, but it does cover all the heavy-hitting features the Zune team is pushing.
¿Se Está Interesado en Zune 3?
Si está interesado en lo que cambiará en el software de Zune, mira la videos en Engadget de esta mañana. Hay algunas cosas que falta, como los juegos, pero describe todas las características principales del equipo de Zune.
By Michael Flanakin
@ 3:54 PM
:: 769 Views
:: Digg it!
A while ago, when working on my first Silverlight app -- well, "app" might be pushing it -- I wanted to use very specific fonts to achieve a specific look and feel. I didn't put much thought into what was rendered at first, but soon I realized my fonts weren't being used. I ultimately found out that Silverlight is very limited in the built-in fonts you have to choose from. You can only choose from the following:
- Comic Sans MS
- Courier New
- Lucida Sans Unicode
- Times New Roman
I was very disappointed when I found out about this because I'm in love with the fonts released with Office 2007, namely Calibri, Cambria, and Consolas. I did say "built-in fonts," however, which is perhaps misleading. The reason for the limited fonts, which I'm sure you can guess, is because Silverlight is aiming to ensure the font you'll need is on the client's machine. What sucks about this is that, even if the client has the font, you still can't use it with a simple name reference, like you can with CSS. There is one work-around, tho.
To use a custom or non-standard font, you simply need to specify a path to the font. The problem with this approach is that it requires the client to download the font file, even if they already have the font locally. I still don't like this, but it's better than no option at all. To specify the font path, you have two options: FontUri property or the <uri>#<font name> syntax within the FontFamily peroperty. This may change in Silverlight 2, but I believe it's consistent with WPF, so I doubt it.
My only hope is that a future version of Silverlight might include a quick check to see if the font is available on the client before downloading it. This should give you the flexibility of using common fonts that aren't considered "standard" to Silverlight without increasing download size significantly across the board.
The last thing I should mention is the use of fall-back fonts. As I understand it, Silverlight support fall-back fonts, but I'm not sure how, unless you're using a custom font. Fall-back fonts in CSS are used when the first font is not available. Since Silverlight limits you to what fonts are theoretically ubiquitous, there doesn't seem to be a need for fall-backs. I can only guess that a fall-back would be used in a case where a font fails to download or the URI is bad.