Posté par chaperon () le 29/06/2007 à 07:57. (lien). Évalué à 5.

belle et éthérée ou autrement dit floue

Les polices vectorielles sont floues, oui. Mais les polices TrueType/OpenType/... ne le sont pas forcément.

Un exemple d'intelligence pure : ProggyFonts (http://www.proggyfonts.com). En utilisant le hinting et en donnant une forme particulière aux polices, on obtient un effet "bitmap".
Et en faisant un hinting aux petits oignons, on devrait même pouvoir obtenir le même résultat en scalable.

Créer une vraie police professionnelle est un art complexe, long, éprouvant et faisant appel à des connaissances très poussées, donc le placement "amoureux" de quelques pixels est devenu dérisoire face à l'impressionnante qualité que l'on peut atteindre avec des polices bien faites.

[ Répondre ]

Posté par chaperon () le 08/06/2007 à 14:06. (lien). Évalué à 5.

Comme par exemple l'excellentissime portaudio http://www.portaudio.com/ que je recommande chaudement

Ou, pour un autre usage, JACK (http://jackaudio.org), pour qui tous les programmes devraient supporter la sauvegarde de session et le transport synchronisé (avis aux développeurs contributeurs).

Maintenant, sans vouloir dénigrer ALSA ni les efforts d'OSS, un système audio centralisé sur un démon me semble plus pratique qu'une couche de pilotes qui sait tout faire. Ils devraient se concentrer sur la stabilité et la latence (qui sont déjà remarquables) plutôt que sur les fonctionnalités.

Donc OSS de retour, c'est une bonne nouvelle, puisque cela fera un meilleur support pour certaines cartes et de toute façon, on va abstraire tout ça derrière une belle lib bien complexe qui fait le travail !

[ Répondre ]

Posté par chaperon () le 16/05/2007 à 18:12. (lien). Évalué à 1.

Je ne réponds pas sur la première partie des réponses, vu que SDL n'est qu'un sujet de trolls sans fin et une lib qui rend bien des services. Admettons que j'aie eu tort, même si je ne le pense toujours pas ...

Par contre, pour le C#, c'est assez inquiétant, vu que beaucoup de jeux XBLA sont en C#. Alors ce ne sont peut-être pas des superproductions, mais attention : Ce type de jeu sera peut-être le jeu vidéo du 21ème siècle.

Qui n'a pas remarqué le type de jeu que fait actuellement Nintendo. N'allez pas me dire qu'un jeu Wii type Wii sports ne peut pas tourner en C# sur une 360. Et comme le marché est encore en train de changer, avec des horreurs techniques genre Nintendo DS (je parle du rendu des jeux, pas de l'input system génial), le C# va prendre de plus en plus d'importance.

Et la différence avec Java, c'est qu'il y a Microsoft derrière, et Vista+360 imposent une pression énorme dans les choix des développeurs en ce moment. Bref, rien à voir avec l'insignifiant (et méconnu) marché des plateformes libres.
Quand je dis insignifiant, tout le monde aura vu la légère exagération, mais le principe est le même.

<mode meme-que-c'est-pas-forcément-vrai-on-s'en-fout-vu-que-les-dev-pensent-tous-ca>De toute manière, linux n'est pas prêt pour le marché de masse. Alors même si tout le monde possède virtuellement une machine sous linux (y'a qu'à l'installer, voire le fournir sur le DVD du jeu), rien ne sert de faire une version avec des technos libres puisque ça ferme la porte de la xbox.

[ Répondre ]

Posté par chaperon () le 15/05/2007 à 10:42. (lien). Évalué à 4.

Enterré ? Et alors !
Un jeu DirectX se porte très facilement sous OpenGL si le code est bien fait. Il ne faut pas voir un jeu comme un gros pâté posé comme ça sur une techno. Tous les jeux récents se basent sur un moteur intermédiaire (type Unreal Engine).

Alors c'est sûr, la demande du marché fait que les jeux passent en DirectX en ce moment, mais les moteurs peuvent en général être passés en OpenGL facilement. Du coup, le fait de modifier un moteur te fais passer facilement 10 jeux du même coup.

... Reste qu'il n'y a encore aucun équivalent libre à DirectX qui soit suffisemment sérieux pour ses fonctionnalités supplémentaires : le support joystick, la gestion directe de la souris (pas en mouse grab, une vraie interface qui prend les souris haute résolution). Le son, OpenAL est définitivement la bonne voie (car supporté par Creative). La création de fenêtre de rendu n'est pas non plus très facile en multiplateforme.
Et le premier qui me répond SDL, je suis au regret de l'informer que c'est hélas insuffisant et un peu mort comme projet (pas de multihead, pas de souris en prise directe, pas de micro, pas de joysticks-de-la-mort avec 45 boutons et 12 axes, ...).

La meilleure voie est encore de pousser les technos libres en amont (Ogre par exemple) et c'est précisément mon job en ce moment. Mais l'entrave la plus grande reste Microsoft et sa X-Box 360. Sous prétexte de "portabilité" (un jeu PC/360 est dit "multiplateforme", arrgh) tout le monde tente de rentrer dans le moule Microsoft. Attendez-vous à voir de plus en plus de jeux écrits en C# ces prochaines années.

[ Répondre ]

Posté par chaperon () le 04/10/2006 à 11:46. (lien). Évalué à 2.

Tout à fait d'accord : Slackware m'a appris le mécanisme de boot de linux (init, le rc et les scripts) car c'est la seule qui soit suffisement simple pour que les scripts soient lisibles par une personne normalement constituée !

Ceci dit, le passage à l'init façon systemV (rc?.d avec des priorites) m'a un peu rebuté.

[ Répondre ]

Posté par chaperon () le 16/09/2006 à 12:06. (lien). Évalué à 1.

Ravi de voir PostgreSQL en évidence, cela m'aidera peut-être à en faire la publicité. Très bonne base de données, mais disposant d'une faible image de marque.

Pour en revenir à la distribution, est-ce que les outils proposés sont vraiment efficaces (genre OpenOffice) ou plutôt des outils encore jeunes (genre GNUCash) ? Peut-on réellement envisager un déploiement en PME ? Les outils sont-ils adaptés au système de comptabilité français ?

Enfin, un gros troll caché sous une montagne de subjectivité : je n'aime pas XUL et je me demande si une alternative libre et réellement standard existe.

[ Répondre ]

Posté par chaperon () le 09/09/2006 à 07:39. (lien). Évalué à 1.

Le "système solaire avec toutes ses planètes" est GNU ?

Il ne peut pas être GNU parce qu'il n'est malheureusement pas livré avec les sources. Ou alors si elles existent, elles ne semblent malheureusement pas modifiables (de l'open source non libre !)

A moins qu'elles existent, mais on n'a pas le compilateur pour refaire le monde (un ptit make world ne devrait pas suffire).

[ Répondre ]

Posté par chaperon () le 06/07/2006 à 13:01. (lien). Évalué à 4.

Mon exemple restait un exemple.

Pour les autres problèmes que tu avance, les formats modernes (OpenType notamment) sont capables de tout gérer ou presque (le presque est infime). Toutes les joyeusetés nécessaires au rendu des polices sont inclues.

Pour ta question sur les algos spécifiques, cela dépend de l'implémentation. Toutes les informations nécessaires au fonctionnement des algos sont fournies dans la police. En revanche, l'interprétation de ces infos sont gérées par les différentes implémentations. On peut imaginer une implémentation spécifique par modèle d'imprimante, par écran, mais en général, les bibliothèques généralistes font de l'assez bon travail pour un usage courant.

Je pense que cette campagne de test souligne bien la complexité énorme de ce travail, et ils devraient bien expliquer qu'il faut soumettre les polices à toutes sortes de médias de sortie (imprimantes de tous types, écran, je ne sais quoi encore ...).

Mais comme apparament leur priorité est le support d'un maximum de langues, aucun cas n'est fait de ce genre de problèmes.

[ Répondre ]

Posté par chaperon () le 06/07/2006 à 12:50. (lien). Évalué à 0.

Mais il y a déjà tellement à faire en poste par poste sur une install d'office par défaut. Paramétrer les données personnelles, enlever cette sal... de compagnon office, régler 2/3 barres d'outils, installer un export PDF, vérifier les configs des filtres de macros, installer un antivirus, je ne parle pas du réglage de Outlook (qui, je vous le rappelle, fait partie d'Office), ...

Bref, les administrations sont rodées à ce genre de manips en install poste par poste. En plus, comme rien n'est automatisable dans office (ou si peu ...), tout cela est fait a la main, avec une procédure généralement sur papier.

Donc l'installation d'un filtre supplémentaire ne devrait pas trop poser de problèmes, à moins qu'il ne fasse 70 Mo et aie 5 écrans de paramétrage pour fonctionner correctement. Il faut simplement qu'il soit connu des administrateurs qui pondent les procédures d'install et OpenDocument sera au moins lisible directement. Quant-à le paramétrer comme format par défaut, la marche est encore haute.

[ Répondre ]

Posté par chaperon () le 06/07/2006 à 07:57. (lien). Évalué à 10.

En fait, les formats utilisés actuellement doivent en théorie s'affranchir de ce problème, ainsi que de la faible résolution des écrans.

Une police vectorielle (composée de lignes et de courbes plutôt que de pixels) est peu lisible si tracée telle quelle sur un écran. Ceci est dû à la résolution très limitée des écrans actuels (120dpi dans le meilleur des cas). Par exemple, un "E" peut avoir ses deux branches horizontales supérieures accolées s'il est tracé trop petit : il devient illisible sur un écran mais reste parfait sur une imprimante.

Pour corriger ces effets indésirables, on utilise le hinting (S.V.P. trouvez-moi la traduction en français) : cela consiste à décaler d'un pixel ou deux les fameuses branches horizontales du E (toujours dans mon exemple). De cette façon, le E est toujours lisible sur un écran à basse résolution (quoique déformé par l'opération).

Et le hinting est une opération complexe, mettant en oeuvre une sorte de langage de programmation (dont le bytecode pose des problèmes de license dans TrueType).

C'est cet aspect universel qui est dur à obtenir dans les polices actuelles, et comme le soulignent les posts plus haut, concevoir une police est un travail de titan ... surtout quand la police est unicode (plusieurs dizaines de milliers de symboles).

[ Répondre ]

Posté par chaperon () le 08/06/2006 à 06:02. (lien). Évalué à 2.

... Surtout que Gentoo (stage 1 notamment) est à mon avis plus chiante à installer qu'une slack.

[ Répondre ]

Posté par chaperon () le 08/06/2006 à 05:57. (lien). Évalué à 0.

Mais qui fait encore des /boot ?

Sérieusement, le /boot était là au départ pour que l'image noyau soit avant le 1024ème secteur du disque car au delà, lilo ne pouvait pas y accéder.

Sinon, aucun intérêt particulier, et surtout pas celui de booter quand même malgré une partition / plantée car pour booter, on a besoin de /etc/inittab.

Et pour ce que sert cette partition, de l'ext3 est amplement suffisant.

Je tolère à peine les /tmp dans une partition séparée, alors les /boot ...

P.S. tout ceci n'est valable que pour un desktop.

[ Répondre ]

Posté par chaperon () le 29/05/2006 à 14:41. (lien). Évalué à 1.

Destroyed Daffy

Excellent nom pour une distrib ! Y'a des royalties ?

[ Répondre ]

Posté par chaperon () le 29/05/2006 à 14:39. (lien). Évalué à 2.

Ouais, enfin relativisons.
Je suis passé à Ubuntu (pour le desktop) dans l'unique but d'avoir des softs plus à jour, mais je n'ai pas tenu 5 minutes avant de passer en dapper (alors qu'elle était à peine dispo en instable).
Quand on en veut toujours plus, on est en instable et on fait des bugreports au lieu de râler.

Et avec mes problèmes de LVM avec le noyau 2.6.16.18 sous debian sarge (compilé correctement avec kernel-package), je songe à passer à ubuntu aussi pour le serveur (petit serveur mais professionnel quand même).

[ Répondre ]

Posté par chaperon () le 01/04/2006 à 14:07. (lien). Évalué à 3.

Ce buisness-model m'a l'air bien, du moins de la façon dont je le comprends.

D'après ce que je comprends, il ne vendra le code (ou le droit de l'utiliser) à personne. Il veut récolter une certaine somme, à partir de laquelle il libèrera le code.

Donc, d'après ce que je comprends (et je peux comprendre de travers), si VMWare sponsorise kqemu, kqemu deviendra libre, et non pas propriété de VMWare.

Si c'est bien ce que j'ai compris, alors je trouve le modèle très réglo, surtout que le module proprio est gratuit (ce qui n'est pas rien).

[ Répondre ]

Posté par chaperon () le 30/03/2006 à 07:57. (lien). Évalué à 3.

4/ les flux DRMisés, serotn à terme lisible que sur une chaine sûre

Oui, sauf que les haut-parleurs seront toujours fabriqués avec des bobines dans lesquelles passe un courant proportionnel au signal. Il suffit de donner un grand coup de savate dans l'enceinte (une enceinte à 2 balles suffit), de récupérer le fil de la bobine, de le couper en son milieu et de reconnecter tout ça sur une entrée ligne de PC.

A moins qu'ils fassent des haut-parleurs surblindés, je vois pas !

Et après, quel sera le rôle de l'ampli ? Si le signal transite en numérique de la source aux enceintes, vu que le convertisseur sera dans l'enceinte, je vois plus l'utilité de l'ampli, qui sera dans l'enceinte.

Et quelles seront les conséquences sur qualité audio de ce type de chaine ? (je parle en très haut de gamme)

[ Répondre ]

Posté par chaperon () le 15/03/2006 à 17:47. (lien). Évalué à 4.

Plutôt intéressant, mais ne résoud pas le problème des moteurs de thèmes, radicalement différents. Dommage que gtk-qt fasse l'inverse de ce que je souhaite (j'utilise GTK majoritairement, et je souhaiterais que les applis QT utilisent le thème GTK).

En plus, les moteurs ont quand même des capacités similaires, et sont donc unifiables facilement.

En bref, les problèmes de widgets sont loin d'être résolus. Et je ne parle pas de OpenOffice/Firefox/Motif/Tk/<you name it>

[ Répondre ]

Posté par chaperon () le 15/03/2006 à 16:17. (lien). Évalué à 2.

D'ailleurs, je verrais bien une norme pour les thèmes graphiques. Avec tous ces moteurs de thèmes, et l'existance de gtk-qt montre un peu le chemin à quivre.

D'après ce que j'ai compris, le dessin des boutons dans QT et GTK sont réalisés par des modules enfichables. Pourquoi pas un format commun ?

Quitte à réaliser un moteur complexe ayant les capacités des deux, mais c'est juste histoire d'en finir une bonne fois pour toute avec les gueguerres de look et histoire de simplifier la vie des créateurs de thèmes.

[ Répondre ]

Posté par chaperon () le 15/03/2006 à 15:55. (lien). Évalué à 2.

Remarque : il n'y a pas beaucoup plus de risques de faux que lors d'une pétition manuscrite. Le seul facteur aggravant est la masse énorme du public sollicité (potentiellement tout internet via google).

[ Répondre ]