28220 sujets

CSS et mise en forme, CSS3

Référence de caractère numérique, font et charset

Pages :
Bonjour,

j'utilise dans le cadre de mon projet des références de caractère numériques pour afficher des cadres (┌ ─ ...)

Le probléme que je rencontre est que la font-size ne semble pas appliquée à ces caractères sur certains postes clients en dépit d'un environnement d'exécution a priori identique (IE6 / Windows XP).

voici ma css :

body {
	font-family: Courier ;
	font-weight: normal;
	font-size: 16 px;
	line-height: 16px;
}

pre {
	margin: 0;
	padding: 0;
}

Modifié par loobiecore (27 Jul 2005 - 15:21)
un exemple en ligne ?
le code de ta page html ?

tout cela pourrait nous aider à t'apporter une solution
Bonjour loobiecore,

loobiecore a écrit :


	font-size: 16 px;


Il ne doit pas y avoir d'espace entre la valeur et l'unité: font-size: 16px; ira déjà beaucoup mieux et règlera le problème de taille de police Smiley cligne

cela dit, tes cadres avec des entités caractères peuvent être assez, voir très problématiques par ailleurs...

Peux-tu nous en dire plus sur le pourquoi et sur le comment (Code HTML) ?
Modifié par Laurent Denis (27 Jul 2005 - 10:32)
voici un exemple de code : 


style.css
body, select {
	font-family: Courier;
	font-weight: normal;
	font-size: 16px;
	line-height: 16px;
}

pre {
	margin: 0;
	padding: 0;
}

test.html
<html>
<link href="style.css" type="text/css" rel="stylesheet" >
<body>
<pre>                                                                           
   &#9484;&#9472;&#9516;&#9472;&#9488;                                              
   &#9474; &#9474; &#9474;
   &#9500;&#9472;&#9532;&#9472;&#9508;                                                                                                                                 
   &#9474; &#9474; &#9474;
   &#9492;&#9472;&#9524;&#9472;&#9496;                                                                                                                              
</pre>
</body>
</html>
quelques infos supplémentaires :

1) sur les postes où je n'ai pas de problème d'alignement, l'exemple que j'ai fourni a une forme rectangulaire. sur les postes à problème, les lignes horizontales sont affichées avec une taille plus grande...

2) le pourquoi : je travaille sur le reverse d'une application mainframe et j'utilise ces caractères spéciaux pour les substituer aux # | - utilisés par les fameux écrans verts...
Il s'agit peut-être d'un problème de charset.

Lorsque l'on bascule le codage à "personnalisé" sur les postes qui posent problème, l'affichage est correct.

Du coup, je ne sais pas quel charset je dois spécifier dans le header de ma réponse (actuellement ISO-8859-1)...

Et ca ne m'explique pas pourquoi certains postes n'ont pas ce problème...
Bon, le problème éventuel de la syntaxe CSS étant écarté, il nous reste deux problèmes de fond nettement plus ennuyeux :

- tes références d'entités numériques sont a priori impeccables : elles désignent parfaitement les caractères Unicode en question, que n'importe quel navigateur peut comprendre.
- mais il faut encore que le navigateur établisse dans quelle police de caractères disponible sur le client il peut rendre au mieux le caractère en question. Le site http://www.alanwood.net/ te permettra de vérifier quelles polices courantes le peuvent, et si tu peux raisonnablement compter dessus.
- Internet Explorer ne sait pas gérer ce type de correspondance de manière transparente dans de nombreux cas (j'ignore si c'est le cas ici) : il faut que l'utilisateur l'ait configuré via les options Internet pour que cela passe.

Bref :
- changer de charset n'a aucune influence ici, puisqu'il s'agit d'entités numériques et non de caractères littéraux.
- IE a un support limité et problématique pour ce que tu veux faire
- je ne comprends toujours pas (et je suis un indécrottable curieux) pourquoi tu passes par de pseudos bordures en contenu au lieu d'utiliser des tableaux HTML, ou des bordures CSS ? Il y a une bonne raison, j'imagine, et j'aimerais bien la connaître Smiley cligne
Modifié par Laurent Denis (27 Jul 2005 - 12:14)
Je travaille sur une solution de webisation d'application mainframe. La génération du html est réalisée dans certain cas par le traduction à la volée des écrans qui me sont retournés par le mainframe. Pour l'instant, mon algo ne contient pas suffisamment d'intelligence pour générer les cadres avec des balise <table> et il se contente de substituer les caractères du genre | - # par ces références d'entité numériques.

En résumé, pour formatter mes pages, je m'appuie sur la balise <pre>, une police non proportionnel (Courier) et les références d'entité numériques pour les bordures.

Personnellement, j'avoue ne pas très bien comprendre comment se fait le lien entre la police et le charset. Je pensais que la css me permettait de l'imposer au browser.

Quelqu'un sait-il ce qui se passe lorsque l'on effectue l'action "Affichage>codage>personnalisées" sous IE6 ??
loobiecore a écrit :
Personnellement, j'avoue ne pas très bien comprendre comment se fait le lien entre la police et le charset. Je pensais que la css me permettait de l'imposer au browser.


Dans la mesure où celui-ci peut la trouver sur la machine en question Smiley cligne

Tu indiques comme seule police "Courier", sans police générique "monospace" permettant au navigateur de chercher une police équivalente dans le stock disponible. Ajouter "Courier, monospace" dans ta CSS sera déjà un premier pas.

Reste à savoir comment le client va établir cette correspondance en déterminant au mieux quelle police de substitution (Courrier New, par exemple) permet de restituer le caractère... Cela dépend du navigateur, et de son paramétrage (un '"Ignorer les Polices Spécifiées Dans les Pages web" dans les options d'IE peut tout mettre par terre, par exemple)

a écrit :

Quelqu'un sait-il ce qui se passe lorsque l'on effectue l'action "Affichage>codage>personnalisées" sous IE6 ??


le navigateur réinterprète la page avec le charset choisi. Mais les caractères désignés par une entité numérique ne sont pas concernés, les entités numériques étant totalement indépendantes du jeu de caractères du document (c'est son rôle et sa raison d'être, en fait). Le problème, encore une fois, n'est pas au niveau du charset, mais au niveau de la disponibilité du caractère dans les polices disponibles sur le client.
Modifié par Laurent Denis (27 Jul 2005 - 12:51)
Concernant la disponibilité de la police, si on part du principe que son apparition dans Word est garante de sa disponibilité pour IE, les postes à problème possèdent tous Courier et Courier New. De plus, je comptais bien sur le fait que Courier ou Courier New relèvent des standards sous Windows...

Par contre, tu sembles être catégorique sur le fait que le fait de basculer manuellemenent "affichage>codage>personnalisées" sous IE n'a aucun impact sur les entités numériques mais le fait que cette manipulation modifie le rendu et résoud le problème d'affichage, semble prouver le contraire...
j'avoue froidement, à ce stade, ignorer si un paramétrage particulier d'IE peut l'amener à ignorer les références Unicode (!) de telle sorte que seul le choix d'un encodage explicite par l'utilisateur puisse "réactiver" celles-ci, bien que cela n'ait aucun sens Smiley cligne
Modifié par Laurent Denis (27 Jul 2005 - 14:24)
Je te confirme que ces caractères ne sont pas mappés dans la police Courier mais bien dans la police Courier New (pour info, j'utilise l'utilitaire windows charmap.exe pour récupérer ce genre d'info).

J'ai donc substitué Courier new à Courier dans ma css.
1) j'ai toujours le problème sur les poste qui ne fonctionnait pas.
2) les postes qui fonctionnait ont maintenant un problème d'alignement vertical...
pour info, je viens de m'apercevoir que la balise <pre> n'hérite pas de la font définie au niveau du body dans ma css.

La font définie par défaut pour la balise <pre> selon le W3C est "monospace" et celle qui est définie par défaut sur mes différents IE6 est "Courier New".

Le problème est donc toujours là...
loobiecore a écrit :
pour info, je viens de m'apercevoir que la balise <pre> n'hérite pas de la font définie au niveau du body dans ma css.


Ah, nous aurons appris une nouvelle particularité d'IE aujourd'hui Smiley cligne

Mais ceci semble régler le problème, pour autant que je puisse tester :
pre {
font-family: "Courier New";
}
Le positionnement de la font "Courier New" au niveau de la balise <pre> ne résoud pas le problème vu que IE6 utilise manifestement déjà cette police par défaut.

J'ai vraiment l'impression que c'est un bug d'affichage IE6 car seul le caractère &#9472; (le tiret horizontal) pose problème en étant affiché avec une longueur trop grande. Sinon, je ne vois pas pourquoi le fait de lui faire réafficher la page avec le "codage personnalisé" déclenche un rendu correct...
Suite de mon investigation :

Si je remplace &#9472; par &#9473; (le même tiret mais en gras), j'obtiens les résultats suivants :

- sur les postes qui fonctionnent : le caractère ne semble pas reconnu et j'ai un joli petit carré à la place.
-sur les postes qui ne fonctionnent pas : le caractère est correctement affiché ; si je bascule en "codage personnalisé", j'ai un petit carré.
quelques nouvelles du front :

j'ai testé cette page sur les différents postes : l'affichage est correct lorsque seuls les caractères du sous-ensemble WGL4 sont supportés. Lorque tous les caractères sont supportés, je constate visuellement que le tiret horizontal paraît plus grand, ce qui expliquerait les décalages horizontaux.

sinon, je pense avoir compris ce que faisait l'action "Affichage>Codage>Personnalisées". Dans "Outils>Options Internet> Onglet Général>Bouton Police", il existe une combo "jeux de caractère" avec l'option "personnalisé". J'imagine que c'est la font spécifiée qui est utilisée pour afficher les caractères avec une référence numérique Unicode.
Le souci est que tous les browsers que j'ai inspectés font tous référence à "Courier New" que ce soit pour "Basé sur le latin" ou "Personnalisé". Il existe bien des différence au niveau des polices proposées mais c'est toujours "Courier New" qui est sélectionné Smiley decu .

J'explore donc la piste d'un événtuel problème de version sur "Courier new" .
http://www.unicode.org/help/display_problems.html
a écrit :

IE is fairly smart about picking tuned fonts for different characters. To set your font as the default for a given block of characters, choose Tools > Internet Options > Fonts, then select the fonts.

Monospace Fonts:
IE uses Web page font to mean variable-width, and Plain text font to mean fixed width. Unfortunately, IE will not let you pick a variable-width font in the Plain text font box. That means in practice that you simply can't view most Unicode characters in fixed-width.
Voici mes conclusion suite à mes différentes recherches :

1) le point le plus problématique semble concerner le fait qu'on ait aucun contrôle précis sur la façon dont IE va récupérer une font pour afficher une entité numérique (voir ce site).
Ceci explique à mon avis pourquoi l'affichage devient correct sur les postes à problème lorsque je bascule le charset à "personnalisé" : lorsqu'il s'appuie sur le charset détecté, IE recherche la font qui lui paraît la plus pertinente pour afficher le caractère unicode et dans mon cas, il doit récupérer une font proportionnelle alors que tout le reste est en non proportionnel (le "Courier New" de ma css), d'où les décalages horizontaux. En basculant en charset "personnalisé", ce mécanisme de recherche doit être annulé et il s'appuie alors bien sur "Courier New".

2) si on ajoute à cela que l'on a encore moins de contrôle sur les fonts installées et leur version (ce qui a un impact sur leur niveau de support d'unicode)... remarque : mon point de départ était quand même que "Courier New" était un standard sous Windows.

J'en conclue que mon problème est insoluble en conservant cette stratégie de codage des bordures.
Je vais donc faire marche arrière et utiliser une font embarquée à base de symbole.

A tout hasard, je vais faire un post dans la rubrique Unicode qui est moins fournie que celle sur les css.
Merci à Laurent Denis pour son aide.
Pages :
Sujet clos
Aller à