CDG contre K² et sa pro-linuxerie - Page 7

Kevin Kofler (./180) :
Mais on n'a besoin que d'une seule implémentation si cette implémentation est libre. Les licences libres permettent de la réutiliser plutôt que de réinventer la roue.

D'ailleurs, KHTML ne sert vraiment à rien, il y avait déjà Gecko et Lynx qui implémentaient le HTML...

Flan > il n'y a pas du tout qu'une seule implémentation de tex ; la plus utilisée actuellement c'est pdfetex, enfin je crois, mais tu as aussi par exemple xetex (qui a l'air très prometteuse et que j'ai l'intention de tester quand j'aurai le temps maintenant que ça a été porté sur PC — ça ne fonctionnait à l'origine que sous mac)

Sally (./182) :
Flan > il n'y a pas du tout qu'une seule implémentation de tex ; la plus utilisée actuellement c'est pdfetex, enfin je crois, mais tu as aussi par exemple xetex (qui a l'air très prometteuse et que j'ai l'intention de tester quand j'aurai le temps maintenant que ça a été porté sur PC — ça ne fonctionnait à l'origine que sous mac)

Est-ce qu'ils ont tous un rendu identique (déjà, si latex ne prend pas en compte les images png contrairement à pdflatex et que ce sont deux implémentations différentes, c'est mal parti) ?
Et est-ce que le format est vraiment aussi complexe que le docx ou le xlsx ?

Joli pavé le ./1 en tout cas pour ce topic, l'auteur a provoqué un joli débat sans jamais venir en re-discuter (il semblerait).

Tétrofor Yoshi !

Flanker (./183) :
Est-ce qu'ils ont tous un rendu identique (déjà, si latex ne prend pas en compte les images png contrairement à pdflatex et que ce sont deux implémentations différentes, c'est mal parti) ?

Bah déjà, à la base, je ne connais pas deux implémentations différentes ayant le *même* rendu. Généralement, justement, si une nouvelle implémentation voit le jour, c'est pour répondre à de nouvelles contraintes (portabilité, rapidité, sécurité ou, bien souvent, fonctionnalités - donc le rendu va différer). Et c'est vrai pour tout, même - par exemple - pour l'audio ou le graphisme en lossy, où on va chercher à améliorer les artefacts.

C'est pourtant le principe de la vague de librasition à laquelle on a eu droit à un moment où chaque logiciel fonctionnel était recodé en mode "libre" juste pour dire que ça excistait...

Nil (./185) :

Flanker (./183) :
Est-ce qu'ils ont tous un rendu identique (déjà, si latex ne prend pas en compte les images png contrairement à pdflatex et que ce sont deux implémentations différentes, c'est mal parti) ?

Bah déjà, à la base, je ne connais pas deux implémentations différentes ayant le *même* rendu. Généralement, justement, si une nouvelle implémentation voit le jour, c'est pour répondre à de nouvelles contraintes (portabilité, rapidité, sécurité ou, bien souvent, fonctionnalités - donc le rendu va différer). Et c'est vrai pour tout, même - par exemple - pour l'audio ou le graphisme en lossy, où on va chercher à améliorer les artefacts.

Bin pour le HTML, on cherche à justement obtenir un rendu identique, non ? Idem pour le CSS, d'ailleurs...

Flanker (./187) :

Nil (./185) :

Flanker (./183) :
Est-ce qu'ils ont tous un rendu identique (déjà, si latex ne prend pas en compte les images png contrairement à pdflatex et que ce sont deux implémentations différentes, c'est mal parti) ?

Bah déjà, à la base, je ne connais pas deux implémentations différentes ayant le *même* rendu. Généralement, justement, si une nouvelle implémentation voit le jour, c'est pour répondre à de nouvelles contraintes (portabilité, rapidité, sécurité ou, bien souvent, fonctionnalités - donc le rendu va différer). Et c'est vrai pour tout, même - par exemple - pour l'audio ou le graphisme en lossy, où on va chercher à améliorer les artefacts.

Bin pour le HTML, on cherche à justement obtenir un rendu identique, non ? Idem pour le CSS, d'ailleurs...

Ben non, la preuve : on n'a pas cherché à copier le rendu d'IE, mais à faire mieux (donc en cassant quelque chose par rapport au navigateur principal). Et on cherche à ajouter des fonctionnalités (donc là aussi, le rendu va forcément changer, puisque de nouvelles balises et de nouveaux styles vont être pris en compte).

Quel format ? ce n'est pas un format de document mais un langage de programmation hein ^^

Je crois qu'ils sont faits pour avoir tous un rendu identique sur les fichiers qui sont acceptés par tous. Enfin identique une fois imprimé, les fichiers sortis ne seront certainement pas identiques (déjà c'est même pas forcément le même format ^^). Mais bon il n'y a certainement pas autant de variation qu'entre genre deux versions de word hein ^^

(Ou même qu'entre une seule version de Word mais deux imprimantes avec des marges différentes )

Nil (./188) :
Ben non, la preuve : on n'a pas cherché à copier le rendu d'IE, mais à faire mieux (donc en cassant quelque chose par rapport au navigateur principal). Et on cherche à ajouter des fonctionnalités (donc là aussi, le rendu va forcément changer, puisque de nouvelles balises et de nouveaux styles vont être pris en compte).

Ah non, actuellement, on cherche à avoir exactement le même rendu, défini par les recommandations w3c (bon, IE pas tellement au début, mais ils s'y mettent). Sinon, pourquoi cherche-t-on à passer les tests acid ?

Et les nouvelles fonctionnalités sont normalement pour répondre aux nouvelles versions de la norme.

Pour ce qui est du CSS, il n'y a pas de navigateur qui soit actuellement conforme à CSS1 (si si, vous avez bien lu "1"), même si Amaya est assez proche de la conformité.
Alors pour les autres standards, vous pensez...

Les tests ACID ne sont pas officiels W3C. Les tests ACID ne sont pas des tests de conformité aux standards: ils utilisent quelques comportements non définis par le standard et qu'implémentent certains browsers.

Lionel Debroux (./192) :
Pour ce qui est du CSS, il n'y a pas de navigateur qui soit actuellement conforme à CSS1 (si si, vous avez bien lu "1"), même si Amaya est assez proche de la conformité.
Alors pour les autres standards, vous pensez...

On cherche tout de même à avoir un rendu identique... même si la complexité de la norme ne facilite pas les choses Sinon, à quoi servent ces normes, justement ?

Flanker (./193) :
Sinon, à quoi servent ces normes, justement ?

A occuper des gratte-papiers...


...et ça a l'air de marcher pas trop mal

Flanker (./183) :
déjà, si latex ne prend pas en compte les images png contrairement à pdflatex et que ce sont deux implémentations différentes

pdftex, et aussi pdfetex (qui est censé être une fusion de pdftex et etex en termes de fonctionnalités, pour l'implémentation je sais pas ^^), ne fonctionnent pas forcément en mode sortie pdf, ils peuvent aussi tourner en compatibilité et sortir un fichier dvi classique. Auquel cas toutes les fonctions pdf sont bien sûr inaccessibles, et notamment l'inclusion d'images png. En fait typiquement pdflatex, comme latex, est un lien symbolique vers ton unique implémentation de tex (pdfetex par défaut sur une version récente), qui décide comment se comporter en fonction du nom avec lequel elle est appelée (enfin aussi en fonction du document, s'il y a %&latex sur la première ligne c'est du latex, et si tu mets un truc genre \pdfoutput=true ça va sortir du pdf).

vince (./186) :
C'est pourtant le principe de la vague de librasition à laquelle on a eu droit à un moment où chaque logiciel fonctionnel était recodé en mode "libre" juste pour dire que ça excistait...

C'est grâce à ça qu'on a des OS entièrement fonctionnels entièrement libres maintenant. Et ce n'est d'ailleurs pas fini, cf. Gnash, swfdec (remplacements libres de Flash), Nouveau (pilote libre pour les cartes graphiques NVidia) etc.

topics/110018-planning-collaboratif#4

tu pourrais pas arrêter de dénigrer à tout va windows ? car franchement c'est soulant, on dirait un gosse de 4 ans !

Demande pas trop à Kevin de changer radicalement, ça marche pas, ça fait des années qu'on essaye. Au mieux il peut se civiliser un peu..

n'empeche qu'il est pas mal fort, parce que même sur un topic qui le critique, il arrive à changer le débat et argumenter pour tel ou tel format audio/vidéo... bref, il fait du KK là où il est critiqué !

justement, #kk#

Tiens, j'avais pas posté une réponse ?!

oui, ici : topics/110018-planning-collaboratif#6

Flanker (./187) :

Nil (./185) :

Flanker (./183) :
Est-ce qu'ils ont tous un rendu identique (déjà, si latex ne prend pas en compte les images png contrairement à pdflatex et que ce sont deux implémentations différentes, c'est mal parti) ?

Bah déjà, à la base, je ne connais pas deux implémentations différentes ayant le *même* rendu. Généralement, justement, si une nouvelle implémentation voit le jour, c'est pour répondre à de nouvelles contraintes (portabilité, rapidité, sécurité ou, bien souvent, fonctionnalités - donc le rendu va différer). Et c'est vrai pour tout, même - par exemple - pour l'audio ou le graphisme en lossy, où on va chercher à améliorer les artefacts.

Bin pour le HTML, on cherche à justement obtenir un rendu identique, non ? Idem pour le CSS, d'ailleurs...

Certainement pas. Tu n'as pas bien saisi l'intérêt du HTML je crois.

dualmoo (./203) :

Flanker (./187) :

Nil (./185) :

Flanker (./183) :
Est-ce qu'ils ont tous un rendu identique (déjà, si latex ne prend pas en compte les images png contrairement à pdflatex et que ce sont deux implémentations différentes, c'est mal parti) ?

Bah déjà, à la base, je ne connais pas deux implémentations différentes ayant le *même* rendu. Généralement, justement, si une nouvelle implémentation voit le jour, c'est pour répondre à de nouvelles contraintes (portabilité, rapidité, sécurité ou, bien souvent, fonctionnalités - donc le rendu va différer). Et c'est vrai pour tout, même - par exemple - pour l'audio ou le graphisme en lossy, où on va chercher à améliorer les artefacts.

Bin pour le HTML, on cherche à justement obtenir un rendu identique, non ? Idem pour le CSS, d'ailleurs...

Certainement pas. Tu n'as pas bien saisi l'intérêt du HTML je crois.

Je crois que c'est toi la pour le coup. Le but de HTML+CSS c'est bien d'avoir un rendu identique quelque soit la plateforme et le navigateur. Apres HTML "brut" avec différent CSSs peut avoir un rendu différent, mais c'est une autre histoire.

Mais non c'est pas d'avoir un rendu identique (c'est débile de vouloir un rendu identique entre un écran 24'' de pc et celui de 12'' d'un altra-portable et celui d'un pda), c'est d'avoir un rendu conforme au specs, ça veut pas du tout dire identique...

Bah oui, dans les mêmes conditions, deux moteurs doivent avoir le même rendu, sinon ils ne respectent pas les specs...

genre tu dis width: 100%, là forcément tu n'auras pas la même largeur sur un 24" ou sur un 10". mais que ce soit gecko, trident, presto ou webkit, tu auras la même largeur

Pas forcément, certains ont des barres d'outils latérales, les polices peuvent avoir des chasses différentes... ce n'est pas indispensable d'avoir strictement le même rendu.

C'est même non-demandé

Et les navigateurs qui permettent par exemple d'avoir une taille d'écran virtuelle et ensuite de zoomer proportionnellement sur la page ( opera mini, opera mobile, pocket ie, ff3, ...), c'est clairement pour rendre un rendu très différent du truc de base, pourtant on peut pas dire que ça respecte pas les specs a proprement parletr là-dessus..

very (./208) :
C'est même non-demandé

Et les navigateurs qui permettent par exemple d'avoir une taille d'écran virtuelle et ensuite de zoomer proportionnellement sur la page ( opera mini, opera mobile, pocket ie, ff3, ...), c'est clairement pour rendre un rendu très différent du truc de base, pourtant on peut pas dire que ça respecte pas les specs a proprement parletr là-dessus..

Oui, enfin si les specs ne demandent d'avoir le même rendu, on s'en fout effectivement s'il est différent (je pensais qu'il fallait avoir le même rendu dans les mêmes conditions mais ça m'étonne quand même )


à la base, on parlait de besoin d'avoir une spec détaillée, pour que les logiciels puissent comprendre la même chose (après, libre à eux de l'interpréter comme ils veulent).
Par exemple, ODF ne dit pas comment doit être stocké le mot de passe (en clair ? en md5 ? en sha1 ? y a une borne inf sur la sécurité ? on a le droit à des algos exotiques ? )
si tu veux être sûr que ton document protégé passe sur OpenOffice, il faut que tu regardes le code source d'OO en plus de la doc pour voir quels sont les hashages qu'il connaît...

Flanker (./209) :

si tu veux être sûr que ton document protégé passe sur OpenOffice, il faut que tu regardes le code source d'OO en plus de la doc pour voir quels sont les hashages qu'il connaît...

Oui mais justement, c'est la force du truc (un peu comme les implémentations d'LDAP, tiens ) : chaque implémentation est libre d'utiliser des mécanismes de cryptages différents (il y en a 4 ou 5 qui sont dans la RFC, mais c'est "open", on peut mettre ce qu'on veut, pourvu que ça précède le mot de passe et que ça soit entre { }. Ainsi, on a une (toute relative) course aux méthodes d'encryptage, on est libre d'utiliser celle qu'on veut en fonction de la puissance des machines oui de migrer si la méthode de cryptage est cassée.