Lion bloque les gestionnaires de police avec Webkit
Certains d'entre vous ont peut-être remarqué que sous Mac OS X 10.7, le texte de certains sites était remplacé par des "A" dans un bloc, que ce soit avec Safari ou Chrome.
MacFixIt a pu en découvrir la raison et comment y remédier : il s'agit d'une incompatibilité entre les nouveaux systèmes de bac à sable de Webkit (le moteur de rendu HTML commun à Safari et Chrome), et les gestionnaires de polices. Le principe du bac à sable est un isolement du code afin de l'empêcher d'accéder à certaines ressources du système pour protéger l'utilisateur. Le système comprend un certain nombre de polices par défaut dans le dossier Système/Bibliothèque/Fonts/, dont une, intitulée Last Resort, qui est utilisée lorsque l'application n'a d'autre recours (d'où son nom). C'est celle-ci qui affiche les fameux caractères incriminés.
Deux autres dossiers contiennent des polices, /Bibliothèque/Fonts/ et /nomdutilisateur/Bibliothèque/Fonts/, qui sont les dossiers dans lesquels Webkit ira chercher les polices nécessaires à l'affichage des sites. Mais les gestionnaires de police disposent de leurs propres dossiers où ils entreposent les polices qu'ils gèrent, et Webkit n'y a par défaut pas accès, et les remplace le cas échéant par Last Resort.
MacFixIt propose trois solutions à ce problème :
- cesser d'utiliser les gestionnaires de police
- configurer le gestionnaire de police pour qu'il utilise l'un des dossiers par défaut
- modifier le fichier de configuration de Webkit
Dans ce dernier cas, il s'agit d'ajouter le dossier utilisé par votre gestionnaire de police dans la liste des chemins que Webkit a le droit d'exploiter. Pour ce faire :
- dans le Finder, sélectionnez le menu "Aller", puis "Aller au dossier…" et collez l'adresse suivante dans la boîte de dialogue :
- dans la fenêtre qui s'ouvre, vous trouverez le fichier com.apple.WebProcess.sb, dupliquez le sur le bureau et renommez l'original par sécurité
- faites un clic droit sur la copie et sélectionnez "Ouvrir avec…" puis TextEdit.
- repérez la section du fichier intitulée "Read-only preferences and data", sous laquelle vous trouverez une ligne commençant par "
- ajoutez les lignes suivantes en respectant l'indentation :
Ces chemins ne valent que pour FontExplorer X et FontAgent Pro, assurez-vous d'y ajouter le chemin utilisé par votre gestionnaire de polices s'il diffère.
- enregistrez et fermez le fichier, puis déplacez-le à l'endroit d'où vous l'avez copié (/System/Library/PrivateFrameworks/WebKit2.framework/WebProcess.app/Contents/Resources), le Finder vous demandera votre mot de passe
- lancez l'application Terminal, copiez-collez la ligne de commande suivante, suivie d'une espace, sans taper la touche entrée :
- glissez l'icône du fichier que vous venez de copier sur la fenêtre du Terminal pour y ajouter son chemin, et tapez la touche entrée, puis votre mot de passe.
En cas de problèmes, revenez à la version initiale du fichier de configuration que vous avez conservée et renommée.
MacFixIt a pu en découvrir la raison et comment y remédier : il s'agit d'une incompatibilité entre les nouveaux systèmes de bac à sable de Webkit (le moteur de rendu HTML commun à Safari et Chrome), et les gestionnaires de polices. Le principe du bac à sable est un isolement du code afin de l'empêcher d'accéder à certaines ressources du système pour protéger l'utilisateur. Le système comprend un certain nombre de polices par défaut dans le dossier Système/Bibliothèque/Fonts/, dont une, intitulée Last Resort, qui est utilisée lorsque l'application n'a d'autre recours (d'où son nom). C'est celle-ci qui affiche les fameux caractères incriminés.
Deux autres dossiers contiennent des polices, /Bibliothèque/Fonts/ et /nomdutilisateur/Bibliothèque/Fonts/, qui sont les dossiers dans lesquels Webkit ira chercher les polices nécessaires à l'affichage des sites. Mais les gestionnaires de police disposent de leurs propres dossiers où ils entreposent les polices qu'ils gèrent, et Webkit n'y a par défaut pas accès, et les remplace le cas échéant par Last Resort.
MacFixIt propose trois solutions à ce problème :
- cesser d'utiliser les gestionnaires de police
- configurer le gestionnaire de police pour qu'il utilise l'un des dossiers par défaut
- modifier le fichier de configuration de Webkit
Dans ce dernier cas, il s'agit d'ajouter le dossier utilisé par votre gestionnaire de police dans la liste des chemins que Webkit a le droit d'exploiter. Pour ce faire :
- dans le Finder, sélectionnez le menu "Aller", puis "Aller au dossier…" et collez l'adresse suivante dans la boîte de dialogue :
/System/Library/PrivateFrameworks/WebKit2.framework/WebProcess.app/Contents/Resources- dans la fenêtre qui s'ouvre, vous trouverez le fichier com.apple.WebProcess.sb, dupliquez le sur le bureau et renommez l'original par sécurité
- faites un clic droit sur la copie et sélectionnez "Ouvrir avec…" puis TextEdit.
- repérez la section du fichier intitulée "Read-only preferences and data", sous laquelle vous trouverez une ligne commençant par "
(allow file-read*" et suivie d'une liste des chemins et fichiers accessibles par WebKit- ajoutez les lignes suivantes en respectant l'indentation :
(home-subpath "/FontExplorer X")
(home-subpath "/FontExplorer X/Font Library")
(home-subpath "/FontAgent Pro Fonts")
(home-subpath "/Library/FontAgent Pro")
(subpath "/Library/FontAgent Pro")Ces chemins ne valent que pour FontExplorer X et FontAgent Pro, assurez-vous d'y ajouter le chemin utilisé par votre gestionnaire de polices s'il diffère.
- enregistrez et fermez le fichier, puis déplacez-le à l'endroit d'où vous l'avez copié (/System/Library/PrivateFrameworks/WebKit2.framework/WebProcess.app/Contents/Resources), le Finder vous demandera votre mot de passe
- lancez l'application Terminal, copiez-collez la ligne de commande suivante, suivie d'une espace, sans taper la touche entrée :
sudo chown root:wheel- glissez l'icône du fichier que vous venez de copier sur la fenêtre du Terminal pour y ajouter son chemin, et tapez la touche entrée, puis votre mot de passe.
En cas de problèmes, revenez à la version initiale du fichier de configuration que vous avez conservée et renommée.
Bisou
@zefoot13
Bisou
@zefoot13 et @victordu66
Bisou
[quote]Certains d'entre vous ont peut-être remarqué que sous Mac OS X 10.7, le texte de certains sites était remplacé par des "A" dans un bloc[/quote]
Mais non... personne n'a rien remarqué, voyons.
Tout le monde sait que plus personne ne fait de la PAO et n'utilise de gestionnaire de polices sous mac OS, enfin ???
Si ?
Mais non... et puis les FontAgentPro, Suitcase et autre Lynotype FEX ne sont plus que de l'histoire ancienne.
...
Et une raison de plus pour ne surtout pas passer à Lion.
C'est décidément de mieux en mieux, chez Apple.
"ne pas utiliser de gestionnaire de polices"...
Mouahahahaha...
Merci pour tous nos amis maquettistes.
Je suis *certain* qu'ils connaissent suffisamment leur mac et le terminal sur le bout des doigts pour appliquer la troisième façon de s'en sortir (la seule valable).
Ou pas. ^_^
Back to the Snow Leopard!
Après la non prise en charge du plug de Reader, maintenant les polices....
Ca sent l'OS super sérieux.
Allez...
Pourquoi vous sortez des news comme ça à macgé ?
Vous croyez qu'on le sait pas déjà qu'il est inutilisable dans un environnement pro, ce félin ?
Tsss...
Tiens j'ai lu ça tout à l'heure :
http://www.pcinpact.com/actu/news/64926-ios-mac-osx-apple-fusion-arm.htm
Ce n'est que le début...
Finalement je reste sur Snow leopard... pas de transition par Lion, je passerais directement à Windows 8...
Vous réalisez que c'est une conséquence de la securité TRÈS renforcée de Lion
Vous feriez mieux de saluer cela et configurer votre gestionnaire pour utiliser les dossiers standards ou demander que son éditeur tienne compte des nouvelles protections de Lion.
-
Je déconseillerai de manipuler le sandboxing des applications via le terminal
Le soucis vient probablement du fait que les bêta-testeurs étaient majoritairement (uniquement ?) des développeurs, qui n'ont par définition pas les mêmes habitudes et n'utilisent pas les mêmes outils que les graphistes/monteurs/maquettistes/musiciens/etc.
Je me trompe peut être, mais ça pourrait être une explication.
Si c'est le cas, surprenant qu'Apple n'en ai pas conscience et ne tente pas d'y remédier en élargissant son parc de testeurs.
Après sans être un grand fan de Lion (mais je finirai bien par m'y habituer), toute sortie de nouvel OS (quelqu'il soit) est toujours suivi d'une suite de correctifs suite à des bugs non dépistés durant la période de test.
Les early-adopters sont forcément les premiers touchés, quant aux pros, ils devraient être au courant et toujours attendre 3 à 6 mois avant de migrer sur une nouvelle version des OS/logiciels qu'ils utilisent, afin d'être sûr qu'ils soient stabilisés et ne pas perdre de temps bêtement.
@pecos [04/08/2011 17:14]
Cette histoire de fusion iOS os x n'a aucun sens
1: ils sont déjà fusionnés : c'est le même noyau, une tonne de code commun entre Cocoa osx et Cocoa iOS
2: les proc arm ne peuvent pas rivaliser avec les procs Intel pour des machines généralistes. Intel est agressif et aligne nouveau cpu sur nouveau cpu.
3: tous les macs sont maintenant thunderbolt. TB est propriétaire Intel et ne peut pas exister pour arm, pour l'heure.
Vous savez donc déjà que pour un bon nombre d'années c'est impossible que quoi que ce soit change
Il n'y a aucun avantage pour Apple et ses clients à passer le Mac en arm
Ni en prix, ni autonomie ni performance. Actuellement on sait déjà que cela serait une régression.
Voilà qui va beaucoup plaire aux studios, aux publicitaires, aux graphistes et autres imprimeurs…
C'est vraiment une cata, ce Lion.
Perso, c'est Mail qui quitte toutes les 30 secondes.
oomu : c'est drôle tu utilises la même excuse que certains politiques pour justifier l'injustifiable :D ("c'est pour votre sécurité, c'est bien")
mettons nous à genoux pour remercier ce bug qui nous protège mes frères :D hahahaha
@ pecos : « Vous croyez qu'on le sait pas déjà qu'il est inutilisable dans un environnement pro, ce félin ? »
Fichtre ! Et moi qui pensais pourtant utiliser mon Mac avec Lion dans un environnement pro sans problème. J’imagine que je me trompais totalement.
Ou alors, c’est plutôt que certaines personnes devraient arrêter de prendre leur cas pour une généralité et de penser que leur environnement de travail est la seule définition envisageable d’un « environnement pro ».
« Tiens j'ai lu ça tout à l'heure :
http://www.pcinpact.com/actu/news/64926-ios-mac-osx-apple-fusion-arm.htm
Ce n'est que le début... »
Ah ben forcément, si c’est PCINpact qui l’écrit, ou plus précisément qui le rapporte en l’appuyant de belles affirmations de Vincent Hermann comme quoi « une telle fusion n’étonnerait personne »… alors ça ne peut qu’être vrai, n’est-ca pas ?
Imaginer une telle fusion paraît tout simplement stupide (dans l’avenir proche décrit par cet article — l’avenir plus lointain est impossible à prédire).
@ Pecos : En même temps, le professionnel de la PAO qui passe à Lion 15 jours après sa sortie est ou suicidaire ou stupide…
La moindre des choses est d'attendre les retours des éditeurs et la confirmation de la compatibilité de leurs produits avec Lion ou, au moins, les retours utilisateurs.
Perso, je suis passé à SL avec un an de "retard" et je n'en suis pas mort… Faut savoir ce qu'on veut dans la vie : avoir un outil professionnel fiable ou tester les dernières nouveautés…
Je trouve Lion très prometteur pour un professionnel, à bien des égards. Faut juste être un minimum prudent avant de mettre à jour son outil de production. C'est pas non plus comme si Adobe avait mis à jour sa suite pour Lion…
@Silverscreen
"Perso, je suis passé à SL avec un an de "retard" et je n'en suis pas mort… Faut savoir ce qu'on veut dans la vie : avoir un outil professionnel fiable ou tester les dernières nouveautés…"
Exact !!!
Cher Oomu, il faut arrêter d'essayer de tout justifier:
- oui, ce bug est une conséquence du niveau de sécurité de Lion
- Mais sécuriser au point d'empêcher la lecture est une erreur qui n'aurait pas du passer.
Bref Lion n'a pas été plus finalisé que les versions précédentes, et c'est dommage.
@DrFatalis
merci, j'aurais pas mieux dit.
@oomu faut bien lire : "et Webkit n'y a par défaut pas accès, et les remplace le cas échéant par Last Ressort."
donc Non non et non, ce bug ( comme tu n'oses pas le nommer. Bug,bug, buuuuug ) n'est pas une conséquence de la sécurité TRÈS renforcée de Lion, mais un TRÈS mauvaise choix de substitut de la part de WebKit, qui aurait très bien pu aller chercher un tahoma ou un helvetica à la place.
Et la sécurité de Lion n'en aurait pas souffert.
Si ?
Les 30 premiers commentaires sont rédigés par des personnes qui ne savent pas lire. Ils lisent que le bac à sable de webkit ne fonctionne plus avec le gestionnaire de polices et ils comprennent que c'est lion qui ne le fait pas. C'est franchement effrayant...
@treizep
1
Ce qui est hallucinant dans cette histoire, c'est les gars de MacFixIt qui esayent - tant bien que mal et de plus en plus difficilement - de faire en sorte qu'un mac puisse être utilisé normalement, et pas comme on l'a décidé en haut lieu à votre place.
Franchement, chapeau bas, car moi il y a longtemps que j'ai laissé tombé le prosélytisme pro apple : trop occupé à essayer de recoller les morceaux sur mes propres machines.
Maintenant je conseille carrément W7, d'une part parce que c'est bien plus versatile, d'autre part parce qu'au moins je n'aurais pas à m'en occuper.
Mais comme toujours avec ce genre de news (qui s'accumulent, ces derniers temps) il y a toujours quelques farfelus qui nous assènent qu'on a rien compris.
Rassurez vous, les gars : j'ai très bien compris où Apple veut en venir. ^_^
Ah, et sinon, ce n'est pas un bug du tout cette histoire : c'est une choix technologique d'Apple qui verrouille les applis dans un bac à sable pour éviter que le ciel lui tombe sur la tête.
Des fois qu'on oserait utiliser une police non autorisée dans Safari !!!
Manquerait plus que ça...
N'espérez donc pas que ça soit corrigé dans une version future.
J'aime bien oomu aussi : "configurer votre gestionnaire pour utiliser les dossiers standards"...
Hi hi hi...
Mais ça revient justement à ne pas utiliser les gestionnaires de police, si on les mets toutes dans les dossiers "fonts" du système... Personne ne veut lui dire ?
Mais il n'a peut-être jamais essayé de démarrer un mac avec 6000 polices dans le dossiers fonts du système, lui...
Du très grand comique, quoi.
@mantra77
euh... ca fait des siècles qu'on ne redémarre plus pour ça
;)
@ grogeek
Il vient de faire la mise à jour depuis Mac OS 7.0. Laisse lui le temps de découvrir les nouvelles features ! :p
J'ai un système de gestion de polices que j'utilise depuis 7 ans... Pas de mise a jour, 100% système, pas d'incompatibilité ni de bug... Je sais ce que je fais, j'utilise les polices dont j'ai besoin et je ne me la pète pas a charger 5412 polices pour en trouver une bien...
La gestion des polices sous os x est fine, est pointue... Mais tant que les utilisateurs verront ça comme un détail, on n'en sortira pas.
C'est quand même 80% des sources de plantées et de ralentissement, les polices en doublons et triplons...
Vraiment pathétique. Passez sur Lion qu'ils disaient, et vous aurez la joie de bidouiller comme sur un PC pour le double du prix ! Pas d'excuses, Apple n'est pas une petite entreprise sympathique, Inadmissible !
Dans le cas où la solution proposée dans l'article ne fonctionne pas (comme sur mon mac):
[b]une autre solution donnée par le support de FontExplorer X Pro:[/b]
http://www.youtube.com/watch?v=dW9aHlOIJUg
[b]Cette solution semble marcher![/b] (à vérifier sur la durée)
Cette vidéo est pour FontAgent, mais fonctionne aussi pour FontExplorer X Pro:
au dessus de la ligne (home-subpath "/Library/Fonts") on ajoute:
(home-subpath "/Users/[i]VotreCompteUtilisateur[/i]/FontExplorer X/Font Library")
(home-subpath "/Users/[i]VotreCompteUtilisateur[/i]/Library/Application Support/Linotype/FontExplorer X")
(subpath "/Volumes/HDD/Users/[i]VotreCompteUtilisateur[/i]/Library/Application Support/Linotype/FontExplorer X")