Le moteur de Gecko en version serveur ?

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes :
0
16
juil.
2005
Internet
Mozillazine-Fr nous annonce qu'une société (Dynalivery) développerait une version du moteur de rendu Gecko en mode serveur.

L'objectif de la société est "d'étendre le champ d'application du XHTML" et c'est ainsi qu'il nous présente un première version de leur produit.

Cette version du moteur est vouée à être intégrée dans un serveur d'impression capable de transformer n'importe quelle ressource Web (au format XHTML) vers une sortie papier classique et/ou dans un autre format tels le PDF, le SVG pour n'en citer que deux.

Le produit est déjà parfaitement utilisable et preuve en est faite sur le site de démonstration de la société Dynalivery.

À tester d'urgence !

Aller plus loin

  • # Hein ?

    Posté par  . Évalué à 4.

    Je ne vois pas trop en quoi c'est une grande avancée. Je pensais bêtement que le moteur gecko fonctionnait comme ceci :

    xhtml --> [ module de rendu ] --> [ primitives graphiques ] --> « dessin »

    Faire un « serveur » à partir de cette architecture, c'est simplement permettre de changer facilement le module des primitives graphiques (pour faire du pdf, du X11, du gtk, du svg...) et emballer tout ça avec un peu de multithread.

    Si ce n'était pas le cas, alors, évidemment, ça fait du boulot pour y arriver...

    PS : dans la série ouille, mes yeux : « Cette version du moteur est vouée à être intégrée... », merci.

    • [^] # Re: Hein ?

      Posté par  . Évalué à 6.

      Faire un « serveur » à partir de cette architecture, c'est simplement permettre de changer facilement le module des primitives graphiques (pour faire du pdf, du X11, du gtk, du svg...) et emballer tout ça avec un peu de multithread.

      Faut-il encore en avoir l'idée et le faire :)

      • [^] # Re: Hein ?

        Posté par  . Évalué à 5.

        Ben oui ;o)

        Bon, du côté de Dynalivery, il s'agit quand même de vendre leur produit : il faut bien laisser croire que c'est génial.

    • [^] # Re: Hein ?

      Posté par  . Évalué à -1.

      C'est clair que l'interêt est minime. A part "tester" son site avec un rendu Gecko, je ne vois pas l'interet. Et encore, je ne vois pas non plus l'interet de tester avec Gecko puisque :

      - ca sera de toutes façon un rendu (presque) exact ou en tout cas qui ne pose pas de problème particulier
      - on utilise de toutes façon déja un navigateur avec Gecko ...

      • [^] # Re: Hein ?

        Posté par  . Évalué à 2.

        Tout le monde n'utilise pas firefox et autre pour naviguer (je suis l'un de ceux qui répugne à l'utiliser par exemple).

        Bon c'est sûr je n'ai pas la prétention d'être un grand guru de cette technologie mais si vous connaissez déjà un appareil qui embarque gecko, bah n'hésitez pas hein.

        • [^] # Re: Hein ?

          Posté par  . Évalué à 9.

          Oh on a pas le droit de ne pas aimer firefox par ici. Dommage.

          Ceci dit je vais préciser un peu mon point de vue parce que je ne veux pas qu'on puisse croire que je pense que c'est une daube. Simplement en bon fan du mode console, j'ai pris l'habitude de tout faire au clavier, d'avoir un environnement de travail minimal (emacs+w3m => parfait pour moi). Quand je me retrouve dans une session X, j'ai du mal et firefox fait partie de ces applis que j'essaie d'éviter d'utiliser au maximum (trop lourd, prend une fenêtre à lui tout seul, tout-à-cliquouille sauf lorsqu'on utilise l'extension conkeror dont j'avais fait une courte présentation).

          Bref, firefox ne correspond tout simplement pas à mes besoins/attentes et je lui préfère 1000 fois emacs-w3m.

          Tous les goûts sont dans la nature. Au bureau par contre, point de salut : c'est soit IE soit Firefox et pour le coup, je préfère largement firefox ;)

          Ceci dit, je ne rafolle pas de firefox. Si je peux m'en passer, je n'hésite pas une seconde.

          Si je devais faire un classement au niveau navigateur, il serait sans équivoque:

          1. emacs-w3m (magnifique, tout simplement génial)
          2. firefox (bien mais c'est pas dans ma "mentalité", désolé pour ceux que cela choque)
          3. galeon (j'ai jamais réussi à en faire ce que je voulais)
          4. mozilla (cf. 2)

          L'avantage que je vois à utiliser emacs-w3m ? Ben comme pour tous les usages que je fais de Emacs: il est scriptable et me permet de faire à peu près tout ce que je peux imaginer. Donc je peux étendre mon navigateur en quelques lignes de codes Lisp sans "surcharger" la bestiole. Je comprends très bien que firefox ne vise pas forcément le même style de public, et comme j'utilise du logiciel libre, je suis libre de ne pas l'utiliser (firefox).

          Voilà,

          • [^] # Re: Hein ?

            Posté par  (site web personnel) . Évalué à 4.

            Oh on a pas le droit de ne pas aimer firefox par ici. Dommage.

            Je pense que si, en expliquant pourquoi comme tu viens de le faire.
            J'ai trouvé, personnellement, ton explication pertinente.

            Personnellement, ce que je reproche à Firefox tient du fait qu'on s'éloigne beaucoup trop de la philosophie que je me fais d'Unix : un petit outil qui fait ce qu'on lui demande, pas plus, mais bien.
            D'un autre côté, je ne suis pas sûr du tout que ce soit la philosophie qui ai guidé le développement.

            Première "mauvaise" expérience : je voulais, à une époque, pour faire une base de données de marque-pages incluant une photo d'écran de la page en question, prendre une photo d'écran d'une page dont le rendu était effectué par Firefox : pas de solution évidente trouvée, autre qu'un bon script qui lancait Firefox puis prenait lui même une photo d'écran après avoir positionné Firefox via geometry à un endroit bien particulier. On va me rétorquer que j'aurais dû utiliser Gecko pour cela, et non Firefox complet : j'ai du coup jeté un coup d'oeil aux sources de la bête de manière à essayer d'isoler ce qui m'intéressait, mais le manque de documentation a fait que je me suis vite fait rabattu sur la solution évoqué ci-précédemment.

            Dans le style aberrant, l'installation de la localisation. Heureusement que l'équipe de Gentoo s'est amusé à faire une doc', parce que ce n'est pas forcément évident pour celui qui désire installer Firefox dans une autre langue que US sur une plateforme autre que Linux/Windows/MacOSX (dans mon cas : NetBSD). Passer Firefox 1.0.4 d'anglais à francais, ce qui, avec Gnumeric ou Abiword par exemple se règle très simplement via un LANG=(fr-)FR, prend l'allure d'un petit parcours du combattant (dans le sens où cela ne correspond à aucune règle habituellement en vigueur en ce qui concerne la localisation d'une application) avec une ligne de commande sans page de manuel explicative (il fallait le trouver le firefox -contentLocale FR -UILocale fr-FR).

            Mon rêve : un firefox modulaire avec les modules faciles à paramétrer, via un système de fichiers de config' XML ou un truc du genre.
            Je sais, on va me rétorquer : si tu le veux, contribue. Mais là on retombe sur un autre problème : il faut investir un temps considérable (du moins c'est ce que j'ai constaté le jour où j'ai voulu commencer à tripatouiller le code de Firefox pour isoler les fonctions qui m'intéressait) avant de pouvoir apporter quelque chose d'intéressant au coeur de ce dernier.

            En gros, un Firefox "scriptable", un peu comme ton Emacs-w3m (du moins ce que tu en relates, vu que je n'ai pas encore essayé ce dernier).

            Par contre, je ne cesse d'utiliser ce dernier car je n'ai pas encore d'autre alternative (Firefox est le seul navigateur que je peux (m')installer à quasi coup sûr pour ne pas être embetté même sur les pages exotiques à la MS-IE-only).

            Dans mon classement perso' :
            - firefox (pas trouvé mieux pour l'instant)
            - lynx/links/dillo (le reste du temps, en fonction des besoins)

          • [^] # Re: Hein ?

            Posté par  . Évalué à 1.

            > Au bureau par contre, point de salut : c'est soit IE soit Firefox et pour le coup, je préfère largement firefox ;)

            Pourquoi n'essaies tu pas emacs+w3m sous cygwin (http://www.cygwin.com(...) ) si tu es forcé d'utiliser un windows ?

            • [^] # Re: Hein ?

              Posté par  . Évalué à 1.

              vu les commentaires élogieux de emacs+w3m, j'aimerais bien tester ce mode. Mais je ne trouve pas de tutoriel clair, est ce que quelqu'un aurait un lien ?

              merci

              • [^] # Re: Hein ?

                Posté par  . Évalué à 3.

                Commence par visiter et écumer le site http://www.emacsfr.org.(...) Tu devrais y trouver quelques pistes.

                Sinon le truc achement qu'il est bien dans Emacs, c'est qu'il est auto-documenté.

                En gros, C-h m peut t'aider à avancer

                Pour le reste, il y a la documentation. Pour débuter, il n'y a pas grand chose à faire:

                1. installer Emacs (en utilisant le packaging de ta distribution)
                2. installer emacs-w3m (comme au dessus)
                3. lancer emacs
                4. charger le module w3m (M-x load-library RET w3m RET)
                5. utiliser: M-x w3m RET

                Pour le scripting & co, va falloir plancer un peu plus (apprendre le Emacs Lisp ou au moins les bases).

                Pour plus d'aide, n'hésite pas à me solliciter.

                • [^] # Re: Hein ?

                  Posté par  . Évalué à 1.

                  ok merci bien pour ta reponse, j'arrive a bien a lancer w3m sous emacs.

                  Par contre, par rapport a w3m, les gif et jpeg ne s'affichent pas, c'est normal ?

                  • [^] # Re: Hein ?

                    Posté par  . Évalué à 2.

                    ca dépend des options de compilations que tu as mis pour emacs :)

                    • [^] # Re: Hein ?

                      Posté par  . Évalué à 0.

                      je suis sur mdk 10.2, j'ai installé emacs et w3m avec urpmi.

                • [^] # Re: Hein ?

                  Posté par  . Évalué à 0.

                  ok merci bien, j'ai enfin reussi a lancer emacs-w3m.

                  Par contre, contrairement a w3m, les gif et les jpeg ne s'affichent pas, c'est normal ?

      • [^] # Re: Hein ?

        Posté par  . Évalué à 2.

        Au contraire, je pense qu'il est utile d'avoir un moteur de rendu de documents XML avec des CSS, notamment pour des applications non-XHTML, par exemple lorsqu'il s'agit de rendre du DocBook en PDF, ou autres choses concernant la documentation (technique).

        Au jour d'aujourd'hui en ce qui concerne le libre je ne vois aucune autre solution qui permette de faire cela.

    • [^] # Re: Hein ?

      Posté par  . Évalué à 5.

      "Faire un « serveur » à partir de cette architecture, c'est simplement permettre de changer facilement le module des primitives graphiques (pour faire du pdf, du X11, du gtk, du svg...) et emballer tout ça avec un peu de multithread."

      Bah vi c'est trivial, quoi qu'en fait... perso, je trouve déjà que compiler les sources de mozilla c'est déjà un exploit :p

      Sérieusement je ne suis pas d'accord avec toi, je ne vois pas le rapport entre "facilité d'implémentation" et "grande avancée", ça doit être compliqué pour être une grande avancée?

      Allez, je sors, c'est dimanche!

      • [^] # Re: Hein ?

        Posté par  . Évalué à 2.

        Ce n'est pas tellement qu'il faille que ce soit difficile ou compliqué pour être une grande avancée, ce que je voulais plutôt insinuer* c'est :
        - je croyais gecko conçu pour ça ;
        - je ne vois pas trop l'intérêt pour une 1re page.

        Le premier point étant le plus important pour moi : si j'avais eu à concevoir gecko, c'est comme cela que j'aurais essayé de le faire, à savoir modulaire et réutilisable.

        * : il faudrait que j'arrête d'insinuer sur dlfp mais c'est la seule façon dont je dispose pour que mes propos ne soient pas trop directs et mal perçus

        • [^] # Re: Hein ?

          Posté par  . Évalué à 2.

          Il faut savoir qu'il y a une grosse architecture d'objets et de composants sous Mozilla en général et donc sous Gecko. Ils ont fait un effort de réutilisabilité du code, etc. Simplement, la pratique semble ne pas suivre ...

          • [^] # Re: Hein ?

            Posté par  . Évalué à 2.

            C'est pour ça que je croyais que c'était déjà conçu comme ça et pour ça (en objectif de second plan).
            Mais bon, il est facile de se perdre sous l'ensemble ou de prendre deux trois raccourcis. Faut aussi dire qu'ajouter des couches d'abstraction, ça n'accélère pas le développement (au début) et ça n'accélère pas le rendu.

          • [^] # Re: Hein ?

            Posté par  . Évalué à 2.

            [Ca c'est le post ou je me fais moinssé :p]

            Peut-être la pratique ne suit pas, parce que c'est terriblement complexe de faire un truc pareil...

            Mozilla n'a pas une approche composant, il est difficile d'extraire une partie de l'appli et de l'utiliser ailleurs.

            Comme je l'ai dit plus haut sur un ton léger: compiler mozilla est déjà une prouesse... Non pas que ce soit impossible, mais c'est relativement complexe... (ça prend dans les 1Go d'espace, etc...).

            Ce n'est pas surprenant pour un projet de cette taille... mais c'est pénalisant.

            Personnellement je rêve d'un composant me permettant:
            - d'afficher des pages web ou je veux
            - de les imprimer
            - de gérer ce qui peut/ne peut pas être accéder (download externe, afficher les images, etc...)
            - d'intéragir avec ces pages web (intercepter le click sur un lien et agir en fonction).
            - Le tout en me permettant de m'intégrer plus au moins à l'environnement de l'utilisateur (retenir les liens visités depuis le navigateur etc...).

            Malheureusement aujourd'hui, et sous windows, ce qui s'en rapproche le plus c'est IE :(

            Si vous avez la moindre piste de possibiltié de solution alternative, n'hésitez pas! J'en cherche une déspérément!

            Enfin pour rester dans le sujet, perso, je sépare totalement la complexité technique du fait que ce soit une avancée... certaine grande avancée sont techniquement triviale! (penser à tous les protocoles du web, ils sont simpels, direct, et souvent perfectibles... pourtant on ne peut nier qu'ils ont changés la façon de travailler). Mais bref, c'est un peu le conflit entre l'approche technique et "business".

            • [^] # Re: Hein ?

              Posté par  . Évalué à 4.

              Comme je viens de le dire, Mozilla a fondamentalement une approche par composants (d'ou XPCOM, son framework de composants) ; et il est possible de faire tout cela grâce à des composants de Mozilla : regardez notamment tout ce qu'il est possible de faire grâce à une application en JavaScript depuis Mozilla.

              Cependant, ce qu'il est relativemet difficile de faire, c'est d'utiliser des composants de Mozilla depuis une application "autre", c'est-à-dire qui n'est pas construite sur la base de Mozilla comme le sont Firefox, Thunderbird et autres. D'ou les manques soulignés.

  • # Et aussi...

    Posté par  . Évalué à 3.

    De mémoire, j'avais vu passer sur ces pages un lien vers un site qui proposait un service de capture d'écran de rendus de browsers libres (konqui et *moz) sous GNU/Linux. Sans avoir les memes possibilité de format de sortie que ce nouvel outil, il était déjà tout à fait utile et similaire (bien qu'il ne faisait que des captures d'écran).

    Quelqu'un aurait-il par chance gardé l'adresse sous la main ?

  • # licence ?

    Posté par  (site web personnel) . Évalué à 4.

    Et la licence du bidule ?

  • # et en plus la démo tourne sous Windows !

    Posté par  . Évalué à 1.

    Franchement, ya des fois je comprend pas. Cette boîte a sûrement du fric à perdre...

    • [^] # Re: et en plus la démo tourne sous Windows !

      Posté par  . Évalué à 5.

      Ca tourne sous Windows et ça nous gratifie de ses erreurs types : j'ai voulu tester et je suis arrivé sur une page d'erreur type avec un lien vers le site de Microsoft...
      Désespérant...

    • [^] # Re: et en plus la démo tourne sous Windows !

      Posté par  . Évalué à 4.

      CSS est un moyen de rendre un document XML, y compris sur papier (il existe un media "paper" pour les CSS), il est donc logique de disposer d'un logiciel qui, à partir d'un document XML et d'une feuille XSL produise un document PDF ou autre format adapté à l'impression, par exemple.

      Je ne comprends pas toutes ces réactions critiques étant donné qu'il n'existe pas d'autre solution libre pour cette technologie, à part ouvrir dans Mozilla et cliquer sur "Imprimer".

      • [^] # Re: et en plus la démo tourne sous Windows !

        Posté par  . Évalué à 3.

        Dans ce cas, je ne comprends plus !
        Si ce n'est pas Gecko qui fait le rendu CSS justement, où est l'intérêt de la news ?

        Pour moi, le rendu était justement fait par Gecko et la librairie était pour moi un équivalent du bouton "Imprimer" de Mozilla.

        • [^] # Re: et en plus la démo tourne sous Windows !

          Posté par  . Évalué à 3.

          Je n'ai pas dit que ce n'était pas Gecko qui faisait le rendu ... c'est bien le cas, mais je souligne la nécessité d'avoir une autre solution que d'ouvrir le document dans Mozilla et de cliquer sur "Imprimer", ce qui est malpratique dans de nombreux cas, lorsque l'on traite plusieurs documents, lorsque l'on veut faire ça en sortie d'une autre application, etc.

          • [^] # Re: et en plus la démo tourne sous Windows !

            Posté par  . Évalué à 3.

            Exactement, je prends ce projet un peu comme les imprimantes virtuelles. La différence c'est que ici on a gecko qui triture les données pour en faire quelque chose d'autre ou une sortie papier.

            C'est à mon sens là qu'est la "prouesse".

  • # Quel intérêt par rapport à Cocoon ?

    Posté par  . Évalué à 1.

    Je fais ce genre de chose depuis des années avec Cocoon http://cocoon.apache.org/(...)

    Quel est l'avancée de cet outil que je ne vois pas ?

    • [^] # Re: Quel intérêt par rapport à Cocoon ?

      Posté par  . Évalué à 1.

      Décidement je vais finir par croire que je vis sous l'eau !

      • [^] # Re: Quel intérêt par rapport à Cocoon ?

        Posté par  . Évalué à -8.

        Tu as d'autres commentaires en réserve aussi intelligents ?
        Désolé de ne pas être un "geek" comme toi !

        • [^] # Re: Quel intérêt par rapport à Cocoon ?

          Posté par  . Évalué à 8.

          Je crois qu'il veut dire qu'une lecture rapide des descriptifs des deux projets montre bien leur différence...

          On pourrait aussi se demander l'intérêt d'un fléau d'armes par rapport à une imprimante, pendant qu'on y est. Avec un fléau dont les pointes sont correctement couvertes d'encre, et en frappant une feuille A4 avec une force convenablement dosée et une précision micrométrique, on peut aussi faire de l'impression, non ?

        • [^] # Re: Quel intérêt par rapport à Cocoon ?

          Posté par  . Évalué à 5.

          Oulà faut pas t'emporter. Mon commentaire n'était pas là pour t'offenser mais pour montrer mon étonnement. Comme je l'ai déjà dit, je ne suis pas l'actualité de ce genre de chose mais l'information m'a semblé suffisamment interessante pour qu'en fasse part ici.

          Franchement j'ai déjà essayé cocoon et je suis bleuffé par ce qu'on peut en faire et je suis sûr que le genre de chose dont je parle dans l'article est largement faisable avec cocoon. Seulement voilà, pour arriver à ce résultat par le biais de cocoon, cela demande un certain effort et une compréhension de cocoon que je ne possède pas. Après ça, tu as l'outrecuidance (orthographe ?) de me taxer de geek ?? ^^

          Allez le prend pas mal, je ne voulais ni t'énerver ni te vexer (vraiment pas) et bravo si tu arrives à faire ça avec cocoon. J'aimerais bien en connaître le dixième sur cocoon juste pour pouvoir me lancer ;)

    • [^] # Re: Quel intérêt par rapport à Cocoon ?

      Posté par  . Évalué à 2.

      D'un côté tu utilises le moteur de rendu de Gecko qui s'occupe de tout. De l'autre tu dois écrire le le XML de transformation et faire avec le rendu primitif et peu flatteur de fop.

      • [^] # Re: Quel intérêt par rapport à Cocoon ?

        Posté par  . Évalué à 1.

        FO est un langage de description de page relativement complet, en tout cas plus complet que CSS dans le domaine de la mise en page destinée au papier.

        Après, reste à savoir si fop est une implémentation défectueuse ... mais bon, pour m'en être déjà servi, je ne pense pas que ce rendu soit spécialement "primitif" à condition de disposer d'une feuille XSL bien écrite.

        • [^] # Re: Quel intérêt par rapport à Cocoon ?

          Posté par  . Évalué à 3.

          Oui mais CSS est bien plus simple -- entendu à apprendre, et suffisant dans la plupart des cas. D'un côté, il faut un fichier XML, puis écrire un fichier XSLT et avoir parcouru des centaines de pages pour comprendre le format XML source, le format XSLT, le format FO... plus les moteurs.

          De l'autre, un moteur Gecko en mode client/serveur, qui prend un XHTML (même HTML ?) plus CSS et retourne le rendu du tout au format demandé. Rien qu'en terme de connaissances nécessaires, la solution Gecko amène la composition automatique de documents à un plus grand nombre.

          Je disais que le moteur de fop est bien en deçà de celui de TeX : qualité des glyphes, moteur de composition, césures, équilibre des blancs... Malheureusement, passiveTeX semble ne plus évoluer. D'un autre côté, fop, semble bloqué en version 0.2...

          Oui, je sais bien que le moteur de Gecko est sûrement pire que celui de fop en termes de composition ; je digressais sur la facilité d'apprentissage. De toute façon, si je voulais un rendu de qualité professionnelle, je composerais dans Scribus !

  • # Hum ...

    Posté par  (site web personnel) . Évalué à 3.

    J'veux pas dire, mais http://linuxfr.org/redirect/42728.html(...) ça tourne sous Microsoft-IIS/5.0 et ça marche pas franchement bien :D (tout mes tests font un 404, youpi ..)

  • # Peut être le futur du web ?

    Posté par  (site web personnel) . Évalué à 3.

    J'ai téste le resultat actuel, c'est n'est pas encore trés fonctionel.

    Mais on peut imaginer que dans le futur les pages HTML soient interpretés par le serveur pour être envoyés aux navigateurs sous forme standard, style PDF.

    Un peu comme la difference entre un javascript et un php.

    Cela pourait permettre avoir un rendu indentique, quelque soit le navigateur.

    Bien sur, il faut encore attendre en raison de la puissance ( du serveur et de la connexion ) que ca pourrait demander

    • [^] # Re: Peut être le futur du web ?

      Posté par  (site web personnel) . Évalué à 6.

      Perso je vois pas l'interêt d'un tel system coté serveur... à part cas très spécifique genre portail.

      Tout ce qui est documentation ou génération d'un fichier ps ou autre sont déjà aux points depuis longtemps. Pour limiter la charge CPU tous les gros sites utilisent des systemes de cache ou voir même des technologies anexe tel que le RSS (génération statique d'un fichier XML contenant juste l'information nécessaire)

      L'export en format SVG pdf png dans Gecko .. avait déjà été discuté lors d'une précédente news :: http://linuxfr.org/2005/04/22/18803.html(...) via cette annonce http://weblogs.mozillazine.org/roc/archives/2005/04/glimpse_of_the.(...) qui envisage l'utilisation de Cairo http://cairographics.org/introduction.(...)

      A noté que Cairo marche pas mal puis que http://gsl.openoffice.org/servlets/ReadMsg?listName=dev&msgNo=1(...) font également des testes pour l'intégration de Cairo dans OpenOffice [ http://primates.ximian.com/~michael/ooo-cairo.png(...) - décembre 2003 ]

      Bon je vois bien un plugin sur ettercap qui génère les pages visité en PNG... :p ca serait déja plus marrant.

      Ou peut être des jolies vignettes dans l'exploration de l'historique ou des Bookmarks ?

      Enfin c'est un bel effet d'annonce ou comment faire de la pub gratuitement :)

      http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk

      • [^] # Re: Peut être le futur du web ?

        Posté par  (site web personnel) . Évalué à 3.

        je vois bien un plugin sur ettercap qui génère les pages visité en PNG
        Je connais quelqu'un qui avait comme projet de réaliser un sniffer qui projetterait ce qu'il capte dans un monde virtuel en 3D. Comme screensaver ça peut être intéressant.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: Peut être le futur du web ?

          Posté par  (site web personnel) . Évalué à 1.

          tu veux parler de driftnet : http://www.ex-parrot.com/~chris/driftnet/(...) et de webcollage : http://www.jwz.org/webcollage/(...) ? par contre le monde 3D j'ai pas trouvé .. webcollage peut déjà s'utiliser en tant que fond d'écran ou screensaver

          http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk

          • [^] # Re: Peut être le futur du web ?

            Posté par  (site web personnel) . Évalué à 2.

            Je connais driftnet et webcollage mais là l'idée c'était d'avoir aussi le texte, les pages web,... qui seraient visibles. Le projet n'est jamais arrivé à terme mais j'aime bien l'idée.

            pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

            • [^] # Re: Peut être le futur du web ?

              Posté par  (site web personnel) . Évalué à 1.

              j'ai vu un truc pour les news rss; la personne générai des préview toute les 30min de la page de garde

              peut être la possibilité de "créer" un tag pour les flux rss et faire des rss encore plus mieux. (vu que le rss est en constante modification pas de normes juste une base standardisé si je me souviens bien)

              http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk

    • [^] # Re: Peut être le futur du web ?

      Posté par  . Évalué à 2.

      Il faut penser aux gens qui ont des problèmes de vue: si tu leur envoies un PDF ça va leur faire une belle jambe!

      • [^] # Re: Peut être le futur du web ?

        Posté par  (site web personnel) . Évalué à 3.

        Il n'existe pas de module de lecture de PDF à l'instar de ce qu'on peut trouver pour le monde HTML?

        • [^] # Re: Peut être le futur du web ?

          Posté par  (site web personnel) . Évalué à 7.

          Ca doit probablement exister (pdf2text | je_sais_pas_quoi ...), mais le problème, c'est que le pdf est intrinsèquement un language de mise en page, avec peu de sémantique. Le PDF te dit ou et comment est le texte, mais pas pourquoi. En HTML, l'aveugle, il oublie le CSS, et il lit des < h1 >, < h2 >, ... dans le texte. Il a les attributs "alt" de certaines balises. Bref, il a toute la structure du document, alors que le pdf est forcément assez "plat" pour lui.

          • [^] # Re: Peut être le futur du web ?

            Posté par  (site web personnel) . Évalué à 2.

            Merci pour cet éclairage : je connaissais mal le principe de lecture de ces formats.

            D'un autre côté, je suppose que dans le PDF un texte avec un police de corps 12 est différencié d'un autre en corps 16?
            Si oui, dans ce cas même si on perd la notion de balise "titre", "paragraphe", "énumération", on doit pouvoir trouver des notions équivalentes en PDF non?

            Du genre : 80% du texte écrit en corps 12, cela signifie que le texte est "normalement" en corps 12, et que tout ce qui se trouve au-dessus/au-dessous doit subit un traitement particulier :
            - au-dessus : titre, sous-titre, en fonction de la différence de corps
            - au-dessous : note

            Je pense notamment aux aveugles que je voyais couramment lire des livres en braille dans le train : si je ne m'abuse, il n'y avait pas de balise "titre" pour annoncer un nouveau chapître ou autre, mais simplement un changement de taille de caractère.

            C'est une simple remarque de quelqu'un d'extérieur non confronté au problème.

          • [^] # Re: Peut être le futur du web ?

            Posté par  (site web personnel) . Évalué à 3.

            Notes qu'en dehors des titres et des listes la sémantique HTML est très peu utilisée (certains diront même "utilisable").
            Et .. les listes et les titres sont bien définissables par PDF. Je ne sais pas comment, je ne connais pas PDF, mais je sais que sur les PDF bien fait je peux demander une liste des titres pour naviguer. C'est donc bien que ces titres sont marqués (comme tes h1 et h2) ou du moins peuvent l'être si l'auteur y fait attention (comme en html).

            • [^] # Re: Peut être le futur du web ?

              Posté par  (site web personnel) . Évalué à 4.

              > sur les PDF bien fait je peux demander une liste des titres

              Oui, mais c'est une table des matières à part, ie une série de liens de la table des matières vers le document, pas l'inverse. On doit pouvoir s'arranger, mais c'est vraiment pas fait pour.

  • # Et l'AFP

    Posté par  . Évalué à 1.

    Bonjour,
    j'ai vu que le produit (non libre) permattait de générer de l'AFP. or mes nombreuses recherches sur le web ne m'ont pas permi de mettre la main sur un truc du genre latex2AFP ....
    Quelqu'un sait si il y aurait qqchose dans le genre.

    Merci par avance

    Youpsla

  • # j'ai testé et franchement c'est pas top

    Posté par  . Évalué à 0.

    j'ai testé leur truc sur http://www.csszengarden.com/(...) et heu ben le résultat c'est pas vraiment aussi joli que ce que je peux avoir avec mon renard préféré :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.