Si vous lisez ce blog régu­liè­re­ment (et vous le faites, n’est-ce pas ?), vous avez sûre­ment remarqué que nous y post­ons des vidéos régulièrement.

Parmi ces vidéos, vous avez du ren­con­trer cer­taines qui s’affichaient dans toute la lar­geur du site (Par exemple le teaser des Watchmen).

Et parmi celles-ci, vous avez enfin sur­ement remarqué cer­taines qui pro­ve­naient de You­Tube (Where the Hell is Matt en est un exemple.) et s’affichaient dans toute leur gloire en Haute Défi­ni­tion, c’est-à-dire en 1280×720.

En effet, depuis quelques jours il est pos­sible, si vous avez envoyé sur you­Tube une vidéo en Haute Défi­ni­tion, de l’afficher dans toute sa splendeur

Pour faire ceci, voici les modi­fi­ca­tions à apporter :

Dans une page You­tube, si vous dési­rez que la vidéo soit dif­fu­sée en HD, ajou­tez &fmt=22 à la suite de l’url.

Par exmple pour Where the Hell is Matt,
http://www.youtube.com/watch?v=zlfKdbWwruY
devient
http://www.youtube.com/watch?v=zlfKdbWwruY&fmt=22

Evi­dem­ment, si vous faites cela, la taille du pavé dans la page You­Tube ne chan­gera pas, mais si vous cliquez sur le bou­ton plein écran, vous ver­rez que la vidéo est bien en Haute Définition.

Mais le plus inté­res­sant reste de pou­voir affi­cher le player You­Tube ou bon vous semble, et dans la taille qui vous plaira.

Pour faire ceci, il vous sera néces­saire de rajou­ter le code “&ap=%2526fmt%3D22” à votre vidéo.

<object width="1280" height="750" >
	<param name="movie" value="http://www.youtube.com/v/zlfKdbWwruY&amp;rel=0&amp;fs=1; />
	<param name="allowFullScreen" value="true"/>
	<param name="wmode" value="window" />
	<embed src="http://www.youtube.com/v/zlfKdbWwruY&amp;rel=0&amp;fs=1; type="application/x-shockwave-flash" allowfullscreen="true" width="1280" height="750" ></embed>
</object>

Le code sui­vant devient donc :

<object width="1280" height="750" >
	<param name="movie" value="http://www.youtube.com/v/zlfKdbWwruY&amp;rel=0&amp;fs=1&amp;ap=%2526fmt%3D22" />
	<param name="allowFullScreen" value="true" />
	<param name="wmode" value="window" />
	<embed src="http://www.youtube.com/v/zlfKdbWwruY&amp;rel=0&amp;fs=1&amp;ap=%2526fmt%3D22" type="application/x-shockwave-flash" allowfullscreen="true" width="640" height="389" ></embed>
</object>

View English version

Un post Déve­lop­pe­ment, pour changer :

Si vous avez essayé d’utiliser sIFR (Shaun Inman’s Flash Repla­ce­ment, du nom de son géni­teur), vous avez sûre­ment constaté quelques sou­cis dans l’utilisation de textes de nos contrées, à savoir des textes dis­po­sant de carac­tères accentués :

Par exemple, sur ce blog, vous pour­rez consta­ter que les titres sont en capi­tales.
La ges­tion des accents fut un tant soit peu pro­blé­ma­tique jusqu’à ce que nous met­tions en place un “workaround”.

Voici le pro­blème en ques­tion :

Pour régler ce pro­blème, qui ne peut pas être sup­primé par les deux variables tune­Height et off­set­Top, il faut d’abord le comprendre.

Le bug ne vient pas de sIFR, mais bien de Flash.
pour vous en convaincre, voici deux screenshots :

Dans l’IDE flash.

Et voici le rendu après expor­ta­tion :

La rai­son pour laquelle sIFR ne peut pas régler cela avec les variables pré­vues (off­se­tHeight, et off­set­Top) est la suivante :

off­set­Top effec­tue une trans­la­tion simple : vous spé­ci­fiez “offsetTop:5″ dans votre fichier .js, et chaque bloc de texte sera décalé par rap­port à l’objet flash ver­ti­ca­le­ment de ce nombre de pixels pré­ci­sé­ment, sans plus de véri­fi­ca­tions.
Si vous spé­ci­fiez par exemple “offsetTop:30″, cela va pla­cer le champ texte à y=30, donc 30px vers le bas.

Il y a donc de grandes qu’il dépasse verticalement.

tune­Height change la hau­teur du fichier flash du nombre de pixels spé­ci­fiés, sans se sou­cier du fait que le texte soit coupé, et sans s’occuper de la taille du champ texte qu’il contient.
tuneHeight:-5 va donc tout sim­ple­ment cou­per 5px en bas de l’objet flash.

Ces deux variables ont une grande uti­lité pour ajus­ter fine­ment la hau­teur de votre texte, et la place qu’il occupe verticalement.

Cer­taines polices en effet ont de longues ascen­dantes et des­cen­dantes, et il est néces­saire d’utiliser off­set­Top et tuneHeight.

Mal­heu­reu­se­ment, concer­nant notre pro­blème, cela n’est pas suf­fi­sant, car Flash pré­sente un bug qui coupe pure­ment et sim­ple­ment les polices

Ce n’est donc pas le bloc de texte qui dépasse de l’objet Flash,
mais bien le texte qui dépasse de l’objet texte.

On remarque d’ailleurs que Flash dis­pose d’une cer­taine tolé­rance, et ne coupe pas “a ras” le contenu, mais quelques pixels au dessus.

Pour cela, on ne peut rien faire, car flash ne mesure pas ce dépassement.

Heu­reu­se­ment, ce pro­blème n’est pré­sent que sur la PREMIERE ligne de texte flash, les sui­vantes s’afficheront correctement.

Notre solu­tion est donc de créer une pre­mière ligne invi­sible, et de déca­ler ver­ti­ca­le­ment le texte.
Il faut en fai­sant cela bien faire atten­tion à gar­der la pos­si­blité de faire varier la hau­teur de cette ligne, voire de la sup­pri­mer com­plè­te­ment depuis le fichier javas­cript, pour gar­der la flexi­bi­lité de sIFR.

Nous allons donc rajou­ter un para­graphe “invi­sible”, et confi­gu­rable à tous les textes conçernés :

Ouvrez le fichier sIFR.as, et, dans la fonc­tion “write(content)”, (aux alen­tours de la ligne 375), remplacez :

375
376
377

this.textField.htmlText = ['<p class="', CSS_ROOT_CLASS, '">',
						content, '</p>'
					].join('');

par :

375
376
377

this.textField.htmlText = ['<p class="accentfix"> </p>','<p class="', CSS_ROOT_CLASS, '">',
						content, '</p>'
					].join('');

ensuite, à la ligne 114, remplaçez :

114
115
116
117
118

  public static function setDefaultStyles() {
	...
      'a:hover { color: #0000FF; text-decoration: none; }'
    ].join(''));
  }

par :

114
115
116
117
118
119
120

  public static function setDefaultStyles() {
    sIFR.styles.parseCSS([
	...
      'a:hover { color: #0000FF; text-decoration: none; }',
	  'p.accentfix {font-size:1;}'
    ].join(''));
  }

Nous avons donc ici un para­graphe de classe “accent­fix”, invisble, et de police de hau­teur 1 par défaut.

Il reste main­te­nant à l’utiliser au sein du fichier javas­cript :
Si vous vou­lez déca­ler votre texte ver­ti­ca­le­ment pour régler les pro­blèmes d’accentuation, vous pou­vez main­te­nant ajou­ter la règle css suivante :

1
2
3
4
5
6
7

sIFR.replace(flash_font, {
	selector: '#someSelector',
	css: [
		'.sIFR-root { /* Your regular sIFR setup goes here*/ }'
	],
	offsetTop:0 /* You can also use this variable, if you feel like it */
});

devient :

1
2
3
4
5
6
7
8

sIFR.replace(flash_font, {
	selector: '#someSelector',
	css: [
		'.sIFR-root { /* Your regular sIFR setup goes here*/ }',
		'.accentfix{display:block; font-size:1; leading:5; }'
	],
	offsetTop:0 /* You can also use this variable, if you feel like it */
});

Pour conclure, ce wor­ka­round ne convien­dra pas à tout le monde, mais il per­met déjà de régler sim­ple­ment et élé­gam­ment une bonne par­tie des pro­blèmes inhé­rents à ce bug de flash.

Si vous vous en ser­vez pour votre site, lais­sez nous un commentaire !

Romain

Lire la version Française

Here is a Deve­lop­ment post, about a pro­blem we had and fixed as we could :

If you have tried using sIFR (Shaun Inman’s Flash Repla­ce­ment, named after it’s crea­tor, a great great man ;) ), and are using it to dis­play non-english cha­rac­ters, you will sur­ely have encoun­te­red some sort of ver­sion of the pro­blem we are dis­cus­sing here :
Upper­case accen­ted and spe­cial cha­rac­ters don’t do well with sIFR.

On this very blog, you can see that we use upper­case titles, and some­times accen­ted cha­rac­ters slip in… what an idea…

We have had trouble get­ting them to dis­play cor­rectly, until we setup this workaround.

The pro­blem can best be des­cri­bed by this pic­ture :

In order to fix this, we could not use the para­me­ters pro­vi­ded by sIFR, tune­Height & off­set­Top, and here is why :

The bug does not come from sIFR but from Flash itself.
To prove this to you, here are two screen­shots and one flash applet:

In the Flash IDE.

After export :

An image ver­sion for those using iPhones ;) :

The rea­son sIFR can’t fix that with tune­Height & off­set­Top is the following :

off­set­Top does a simple ver­ti­cal trans­la­tion. you tell it “offsetTop:5″, and the text­Field will be moved by 5 pixels dow­nards, without any other sort of veri­fi­ca­tion or adjustment

tune­Height changes the ove­rall height of the flash object, without wor­rying about the text being cut or otherwise.

“tuneHeight:-5″ will thus sim­ply cut 5 pixels from the bot­tom of the flash object.

Those two para­me­ters are great to adjust pre­ci­sely the ver­ti­cal grid of your text, and, for some fonts that have long ascen­ders or des­cen­ders, it can prevent them from being cutoff.

Unfor­tu­na­tely, it’s not enough for our pre­cise case, because the Flash bug sim­ply cuts the text that over­flows too much.

So it’s not the text­Field over­flo­wing from Flash, its the text over­flo­wing from the text­Field that causes trouble.

We can see that Flash has a cer­tain tole­rance, and does not cut shar­ply the text, but leaves a few pixels to over­flow.
but this is not enough for cer­tain fonts.

For that there’s nothing we can do because Flash has no way of mea­su­ring the overflow’s height.

For­tu­na­tely, this pro­blem is only present for the VERY FIRST line of a text­Field, and the fol­lo­wing ones will dis­play correctly.

Our solu­tion is then to create an invi­sible first line, and adjust it’s height to be pre­ci­sely what we need, and even to sup­press it com­ple­tely from the javas­cript if we see fit.

So we will modify the sIFR.as file to auto­ma­ti­cally add some mar­kup to every text :

Open sIFR.as, and, in the “write(content)” func­tion, around line 375 (in v3r435) replace :

375
376
377

this.textField.htmlText = ['<p class="', CSS_ROOT_CLASS, '">',
						content, '</p>'
					].join('');

by :

375
376
377

this.textField.htmlText = ['<p class="accentfix"> </p>','<p class="', CSS_ROOT_CLASS, '">',
						content, '</p>'
					].join('');

We have just pre­pen­ded a para­graph to every flash text block.

Then, at line 114, replace :

114
115
116
117
118

  public static function setDefaultStyles() {
	...
      'a:hover { color: #0000FF; text-decoration: none; }'
    ].join(''));
  }

by :

114
115
116
117
118
119
120

  public static function setDefaultStyles() {
    sIFR.styles.parseCSS([
	...
      'a:hover { color: #0000FF; text-decoration: none; }',
	  'p.accentfix {font-size:1;}'
    ].join(''));
  }

We now have a para­graph with class “accent­fix”, that’s invi­sible and has a font-size of 1 by default.

Now you can use it in your javas­cript file :

If you want to off­set ver­ti­cally your text to fix the pro­blem, you can sim­ply add the fol­lo­wing css rule to the replace statement :

1
2
3
4
5
6
7

sIFR.replace(flash_font, {
	selector: '#someSelector',
	css: [
		'.sIFR-root { /* Your regular sIFR setup goes here*/ }'
	],
	offsetTop:0 /* You can also use this variable, if you feel like it */
});

becomes :

1
2
3
4
5
6
7
8

sIFR.replace(flash_font, {
	selector: '#someSelector',
	css: [
		'.sIFR-root { /* Your regular sIFR setup goes here*/ }',
		'.accentfix{display:block; font-size:1; leading:5; }'
	],
	offsetTop:0 /* You can also use this variable, if you feel like it */
});

And Voila ! no more cutoff upper­case characters !

This wor­ka­round will not fit eve­ryone, but it allows to fix sim­ply and qui­ckly a good part of the pro­blems rela­ted to this flash bug.

If you use it, be sure to let us know !

Romain

It seems some undo­cu­men­ted fea­ture allows to have fulls­creen web apps with the cur­rent firmware.

That could be inter­es­ting, as I don’t want to leard Objective-C just to be able to send ano­ther really useful app to the Appstore

Read on AppleInsider