Afficher une image en RAM parmi du texte

Nicolas George

28/04/2006 à 16:14

Asterbing wrote in message
:

print "Content-type: text/htmlnn";
print "Ceci est une image :";
print $img;
print "C'est tout !";
exit 0;

Si je retire la ligne "... Ceci est une image ...", l'image en question
s'affiche bien dans le navigateur, mais la ligne "... C'est tout !" est
ignorée.

Si je laisse la ligne "... Ceci est une image ...", j'obtiens la phrase,
puis le contenu de l'image interprété en tant que texte et la dernière
ligne de texte.

C'est une question de HTML, pas de Perl : comment avoir une image
directement dans un document HTML, sans passer par un document séparé tel
qu'on le fait avec <img src="..." />. Ensuite, passer à du perl revient
uniquement à ajouter les print qui vont bien.

La réponse à la question est le schéma d'URL data:. Voici comment il
s'utilise :

Voici mon
<img src="data:image/gif;base64,
R0lGODdhCAAIAJEAAP///6bK8Cpf/wAAACwAAAAACAAIAAACEIx/ojux7J5ocsZHZRu8jwIAOw=="
/>
image.

Je rappelle qu'au passage qu'en HTML, une image ne peut pas apparaître à
même dans un document, elle doit être incorporée à un paragraphe ou un autre
élément de type bloc.

L'idéal serait bien sûr de passer par un truc comme "print <img
src="display_image_value.cgi"></img>"; avec l'image POStée
(puisqu'impossible de passer les data de l'image en GET sur l'url elle-
même), mais comment simule-t-on le POST sans formulaire et son action ?

On ne peut pas faire un POST sans formulaire. En revanche, un GET, c'est
trivial.

Je ne veux pas paraître méchant, mais il me semble qu'il manque un certain
niveau de compréhension des mécanismes mis en jeu. Je conseille donc, avant
de poursuivre la réalisation de CGI en Perl, d'apprendre le minimum sur,
dans l'ordre :

- le HTML ;

- le HTTP (au moins savoir envoyer une requête GET et une requête POST à la
main avec telnet ou assimilé) ;

- le CGI et son lien avec HTTP.

On peut souvent arriver à se débrouiller pour les trucs élémentaires sans
ça, mais dès qu'on complique, en particulier des CGI en plusieurs fichiers,
cette compréhension devient indispensable.

Asterbing wrote in message
<MPG.1ebc34c629cbf9df989823@news.tiscali.fr>:

print "Content-type: text/htmlnn";
print "Ceci est une image :";
print $img;
print "C'est tout !";
exit 0;

Si je retire la ligne "... Ceci est une image ...", l'image en question
s'affiche bien dans le navigateur, mais la ligne "... C'est tout !" est
ignorée.

Si je laisse la ligne "... Ceci est une image ...", j'obtiens la phrase,
puis le contenu de l'image interprété en tant que texte et la dernière
ligne de texte.

C'est une question de HTML, pas de Perl : comment avoir une image
directement dans un document HTML, sans passer par un document séparé tel
qu'on le fait avec <img src="..." />. Ensuite, passer à du perl revient
uniquement à ajouter les print qui vont bien.

La réponse à la question est le schéma d'URL data:. Voici comment il
s'utilise :

Voici mon
<img src="data:image/gif;base64,
R0lGODdhCAAIAJEAAP///6bK8Cpf/wAAACwAAAAACAAIAAACEIx/ojux7J5ocsZHZRu8jwIAOw=="
/>
image.

Je rappelle qu'au passage qu'en HTML, une image ne peut pas apparaître à
même dans un document, elle doit être incorporée à un paragraphe ou un autre
élément de type bloc.

L'idéal serait bien sûr de passer par un truc comme "print <img
src="display_image_value.cgi"></img>"; avec l'image POStée
(puisqu'impossible de passer les data de l'image en GET sur l'url elle-
même), mais comment simule-t-on le POST sans formulaire et son action ?

On ne peut pas faire un POST sans formulaire. En revanche, un GET, c'est
trivial.

Je ne veux pas paraître méchant, mais il me semble qu'il manque un certain
niveau de compréhension des mécanismes mis en jeu. Je conseille donc, avant
de poursuivre la réalisation de CGI en Perl, d'apprendre le minimum sur,
dans l'ordre :

- le HTML ;

- le HTTP (au moins savoir envoyer une requête GET et une requête POST à la
main avec telnet ou assimilé) ;

- le CGI et son lien avec HTTP.

On peut souvent arriver à se débrouiller pour les trucs élémentaires sans
ça, mais dès qu'on complique, en particulier des CGI en plusieurs fichiers,
cette compréhension devient indispensable.

Vous avez filtré cet utilisateur ! Consultez son message

Asterbing wrote in message
:

print "Content-type: text/htmlnn";
print "Ceci est une image :";
print $img;
print "C'est tout !";
exit 0;

Si je retire la ligne "... Ceci est une image ...", l'image en question
s'affiche bien dans le navigateur, mais la ligne "... C'est tout !" est
ignorée.

Si je laisse la ligne "... Ceci est une image ...", j'obtiens la phrase,
puis le contenu de l'image interprété en tant que texte et la dernière
ligne de texte.

C'est une question de HTML, pas de Perl : comment avoir une image
directement dans un document HTML, sans passer par un document séparé tel
qu'on le fait avec <img src="..." />. Ensuite, passer à du perl revient
uniquement à ajouter les print qui vont bien.

La réponse à la question est le schéma d'URL data:. Voici comment il
s'utilise :

Voici mon
<img src="data:image/gif;base64,
R0lGODdhCAAIAJEAAP///6bK8Cpf/wAAACwAAAAACAAIAAACEIx/ojux7J5ocsZHZRu8jwIAOw=="
/>
image.

Je rappelle qu'au passage qu'en HTML, une image ne peut pas apparaître à
même dans un document, elle doit être incorporée à un paragraphe ou un autre
élément de type bloc.

L'idéal serait bien sûr de passer par un truc comme "print <img
src="display_image_value.cgi"></img>"; avec l'image POStée
(puisqu'impossible de passer les data de l'image en GET sur l'url elle-
même), mais comment simule-t-on le POST sans formulaire et son action ?

On ne peut pas faire un POST sans formulaire. En revanche, un GET, c'est
trivial.

Je ne veux pas paraître méchant, mais il me semble qu'il manque un certain
niveau de compréhension des mécanismes mis en jeu. Je conseille donc, avant
de poursuivre la réalisation de CGI en Perl, d'apprendre le minimum sur,
dans l'ordre :

- le HTML ;

- le HTTP (au moins savoir envoyer une requête GET et une requête POST à la
main avec telnet ou assimilé) ;

- le CGI et son lien avec HTTP.

On peut souvent arriver à se débrouiller pour les trucs élémentaires sans
ça, mais dès qu'on complique, en particulier des CGI en plusieurs fichiers,
cette compréhension devient indispensable.

Asterbing

28/04/2006 à 17:17

In article <e2t7ve$2hv5$, nicolas$
s.org says...

La réponse à la question est le schéma d'URL data:. Voici comment il
s'utilise :

Voici mon
<img src="data:image/gif;base64,
R0lGODdhCAAIAJEAAP///6bK8Cpf/wAAACwAAAAACAAIAAACEIx/ojux7J5ocsZHZRu8jwIAOw=="
/>
image.

Cela marche dans Netscape mais pas dans IE.

Je rappelle qu'au passage qu'en HTML, une image ne peut pas apparaître à
même dans un document, elle doit être incorporée à un paragraphe ou un autre
élément de type bloc.

Merci papa.

L'idéal serait bien sûr de passer par un truc comme "print <img
src="display_image_value.cgi"></img>"; avec l'image POStée
(puisqu'impossible de passer les data de l'image en GET sur l'url elle-
même), mais comment simule-t-on le POST sans formulaire et son action ?

On ne peut pas faire un POST sans formulaire. En revanche, un GET, c'est
trivial.

Ma question était bien sur le POST. Quand au GET, je sais faire, merci.

Je ne veux pas paraître méchant, mais il me semble qu'il manque un certain
niveau de compréhension des mécanismes mis en jeu. Je conseille donc, avant
de poursuivre la réalisation de CGI en Perl, d'apprendre le minimum sur,
dans l'ordre :

Sais-tu comment on appelle ton mode de communication en psychologie (oh
peut-être cela sort-il de ta compétence) : le mode de communication
paradoxal. Le savoir pourrait ne pas être inutile.

Celui qui avance n'est pas celui qui se tait pour paraitre érudit, mais
celui qui parle sans fioriture dans le seul but de réaliser une
solution. Je pose et poserai mes questions quand il me semblera
nécessaire avec ou sans ton aval... Quant à mon niveau nous pourrions en
parler mais je ne crois pas qu'il y aurait grand intérêt pour ceux qui
nous lise et peut-être perdrais tu un peu de ton vernis l'ami.

Paul Gaborit

28/04/2006 à 17:59

À (at) Fri, 28 Apr 2006 17:17:51 +0200,
Asterbing écrivait (wrote):

Sais-tu comment on appelle ton mode de communication en psychologie (oh
peut-être cela sort-il de ta compétence) : le mode de communication
paradoxal. Le savoir pourrait ne pas être inutile.

Vous posez des questions et vous vous permettez de donner des
leçons... Belle manière de remercier ceux qui tentent de vous aider.

Personnellement, je pense que les conseils de Nicolas George étaient
tout à fait adaptés. Si mes souvenirs sont bons, ce n'est d'ailleurs
pas le premier à vous donner de tels conseils.

Votre question qui ne concerne qu'un problème de HTML/HTTP et qui n'a
aucun rapport avec Perl pouvait être compriese de deux manières :

soit vous n'avez pas bien fait la séparation entre ce que fait
HTML/HTTP et ce que fait Perl. C'est, à mon avis, ce qu'a supposé
Nicolas George et ce qui l'a amené à formuler ses conseils (il a
même pris de gants en précisant "je ne veux pas être méchant"). Et
il a aussi pris le temps de vous donner quelques éléments de
réponse...

soit vous faites tout à fait la différence et alors vous vous
permettez de poser une question qui n'a rien à faire sur ce forum au
mépris des quelques règles d'usage.

À vote place, j'aurais préféré la première manière : mieux vaut passer
pour un ignorant que pour un incompétent.

Je pose et poserai mes questions quand il me semblera nécessaire
avec ou sans ton aval...

Puisque c'est là votre manière de voir les choses, appliquez cela à
vous-même et admettez donc que les autres vous répondent quand ils le
veulent et de la manière qu'ils veulent.

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>

kurtz le pirate

28/04/2006 à 18:15

In article ,
Asterbing wrote:

Sais-tu comment on appelle ton mode de communication en psychologie (oh
peut-être cela sort-il de ta compétence) : le mode de communication
paradoxal. Le savoir pourrait ne pas être inutile.

Celui qui avance n'est pas celui qui se tait pour paraitre érudit, mais
celui qui parle sans fioriture dans le seul but de réaliser une
solution. Je pose et poserai mes questions quand il me semblera
nécessaire avec ou sans ton aval... Quant à mon niveau nous pourrions en
parler mais je ne crois pas qu'il y aurait grand intérêt pour ceux qui
nous lise et peut-être perdrais tu un peu de ton vernis l'ami.

monsieur joue les analystes ? mdr !!

puisque tu en ai là, ta question n'a rien à voir avec perl. c'est le
html qu'il faut apprendre.

--
klp

Asterbing

28/04/2006 à 19:35

In article ,
says...

monsieur joue les analystes ? mdr !!

Pourquoi présager lorsque l'on ne sait pas qui est en face, exactement.
Je ne comprendrai jamais ce type de penser, pas plus que ces modes de
communication paradoxaux dont je vous ai déjà trop parlé. Ce n'est pas
inintéressant.

puisque tu en ai là, ta question n'a rien à voir avec perl. c'est le
html qu'il faut apprendre.

Alors, si je vais sur alt.html, viendras-tu me livrer LA solution ? Je
n'attends que ça : la solution... Puisque le chemin passant par data:
URI ne fonctionne pas dans Internet Explorer.

Asterbing

28/04/2006 à 19:35

In article ,
says...

Vous posez des questions et vous vous permettez de donner des
leçons... Belle manière de remercier ceux qui tentent de vous aider.

Je n'ai jamais reproché à quiconque de m'aider ainsi que je ne rechiogne
jamais à aider lorsque le sujet tombe dans ma compétence plus directe.
Relisez-moi.

Personnellement, je pense que les conseils de Nicolas George étaient
tout à fait adaptés. Si mes souvenirs sont bons, ce n'est d'ailleurs
pas le premier à vous donner de tels conseils.

Sa solution n'en est pas une puisqu'elle ne fonctionne pas dans le
navigateur le plus utilisé. Quand à la forme, c'est justement contre
celle-ci que je m'insurgeais. Etes-vous allez vous renseigner sur ce
qu'est la "communication paradoxale" ? Ce n'étais pas un effet de style
mais l'énoncé de quelque chose de précisément défini et qui pour la
bonne entente général est à bannir le plus souvent.

Concernant vos réponses (vous, Paul), elles ne m'ont jamais blessées,
simplement parce que vous ne pratiquez pas cette fameuse communication
paradoxale, ce qui n'est pas le cas de Nicolas George : chacun a a
apprendre chaque jour : moi et lui tout autant ! Alors, disons que j'ai
à travailler mes connaissance HTTP/CGI et qu'il a à travailler son mode
de communication.

Votre question qui ne concerne qu'un problème de HTML/HTTP et qui n'a
aucun rapport avec Perl pouvait être compriese de deux manières :

soit vous n'avez pas bien fait la séparation entre ce que fait
HTML/HTTP et ce que fait Perl. C'est, à mon avis, ce qu'a supposé
Nicolas George et ce qui l'a amené à formuler ses conseils (il a
même pris de gants en précisant "je ne veux pas être méchant"). Et
il a aussi pris le temps de vous donner quelques éléments de
réponse...

soit vous faites tout à fait la différence et alors vous vous
permettez de poser une question qui n'a rien à faire sur ce forum au
mépris des quelques règles d'usage.

Aucun des deux options : il aurait par exemple pu exister un module que
je ne connaitrais pas (ce qui est assez aisé), qui résoudrait ce sujet
et que je pourrais aller voir. Parler Perl n'est pas nécessairement
parler syntaxe et langage pur, ce peut être aussi d'aborder tous sujet
dès lors que le langage utilisé est celui-ci dans 'application
concernée. Par exemple, ce fil récent concernant un "Portail".

Enfin et pour préciser mon intervention, ce "je ne veux pas être
méchant" est précisément ce qui rend son discours paradoxal. Si l'envie
vous titille de chercher sur ce "mode de communication paradoxal", trop
souvent utilisé de nos jours, j'en serai heureux.

À vote place, j'aurais préféré la première manière : mieux vaut passer
pour un ignorant que pour un incompétent.

Il ne me semble pas cacher mon ignorance actuelle dans les sujets que
sont le CGI/HTTP et Perl. Où avez-vous vu ça ?

Je pose et poserai mes questions quand il me semblera nécessaire
avec ou sans ton aval...

Puisque c'est là votre manière de voir les choses, appliquez cela à
vous-même et admettez donc que les autres vous répondent quand ils le
veulent et de la manière qu'ils veulent.

C'est de toute façon ce que chacun fait ! Celà ne me dérange pas le
moins du monde dès lors que la règle est *réciproque*... Acceptez donc
que je ne sois pas complètement stoïque lorsque quelqu'un vient me dire
les choses sur un mode bien loin du convivial et cordial qu'il pourrait
être (et ce pour la seconde fois, au moins)...

In article <r7odylzo5x.fsf@vaugirard.enstimac.fr>,
Paul.Gaborit@invalid.invalid says...

Vous posez des questions et vous vous permettez de donner des
leçons... Belle manière de remercier ceux qui tentent de vous aider.

Je n'ai jamais reproché à quiconque de m'aider ainsi que je ne rechiogne
jamais à aider lorsque le sujet tombe dans ma compétence plus directe.
Relisez-moi.

Personnellement, je pense que les conseils de Nicolas George étaient
tout à fait adaptés. Si mes souvenirs sont bons, ce n'est d'ailleurs
pas le premier à vous donner de tels conseils.

Sa solution n'en est pas une puisqu'elle ne fonctionne pas dans le
navigateur le plus utilisé. Quand à la forme, c'est justement contre
celle-ci que je m'insurgeais. Etes-vous allez vous renseigner sur ce
qu'est la "communication paradoxale" ? Ce n'étais pas un effet de style
mais l'énoncé de quelque chose de précisément défini et qui pour la
bonne entente général est à bannir le plus souvent.

Concernant vos réponses (vous, Paul), elles ne m'ont jamais blessées,
simplement parce que vous ne pratiquez pas cette fameuse communication
paradoxale, ce qui n'est pas le cas de Nicolas George : chacun a a
apprendre chaque jour : moi et lui tout autant ! Alors, disons que j'ai
à travailler mes connaissance HTTP/CGI et qu'il a à travailler son mode
de communication.

Votre question qui ne concerne qu'un problème de HTML/HTTP et qui n'a
aucun rapport avec Perl pouvait être compriese de deux manières :

soit vous n'avez pas bien fait la séparation entre ce que fait
HTML/HTTP et ce que fait Perl. C'est, à mon avis, ce qu'a supposé
Nicolas George et ce qui l'a amené à formuler ses conseils (il a
même pris de gants en précisant "je ne veux pas être méchant"). Et
il a aussi pris le temps de vous donner quelques éléments de
réponse...

soit vous faites tout à fait la différence et alors vous vous
permettez de poser une question qui n'a rien à faire sur ce forum au
mépris des quelques règles d'usage.

Aucun des deux options : il aurait par exemple pu exister un module que
je ne connaitrais pas (ce qui est assez aisé), qui résoudrait ce sujet
et que je pourrais aller voir. Parler Perl n'est pas nécessairement
parler syntaxe et langage pur, ce peut être aussi d'aborder tous sujet
dès lors que le langage utilisé est celui-ci dans 'application
concernée. Par exemple, ce fil récent concernant un "Portail".

Enfin et pour préciser mon intervention, ce "je ne veux pas être
méchant" est précisément ce qui rend son discours paradoxal. Si l'envie
vous titille de chercher sur ce "mode de communication paradoxal", trop
souvent utilisé de nos jours, j'en serai heureux.

À vote place, j'aurais préféré la première manière : mieux vaut passer
pour un ignorant que pour un incompétent.

Il ne me semble pas cacher mon ignorance actuelle dans les sujets que
sont le CGI/HTTP et Perl. Où avez-vous vu ça ?

Je pose et poserai mes questions quand il me semblera nécessaire
avec ou sans ton aval...

Puisque c'est là votre manière de voir les choses, appliquez cela à
vous-même et admettez donc que les autres vous répondent quand ils le
veulent et de la manière qu'ils veulent.

C'est de toute façon ce que chacun fait ! Celà ne me dérange pas le
moins du monde dès lors que la règle est *réciproque*... Acceptez donc
que je ne sois pas complètement stoïque lorsque quelqu'un vient me dire
les choses sur un mode bien loin du convivial et cordial qu'il pourrait
être (et ce pour la seconde fois, au moins)...

Vous avez filtré cet utilisateur ! Consultez son message

In article ,
says...

Vous posez des questions et vous vous permettez de donner des
leçons... Belle manière de remercier ceux qui tentent de vous aider.

Je n'ai jamais reproché à quiconque de m'aider ainsi que je ne rechiogne
jamais à aider lorsque le sujet tombe dans ma compétence plus directe.
Relisez-moi.

Personnellement, je pense que les conseils de Nicolas George étaient
tout à fait adaptés. Si mes souvenirs sont bons, ce n'est d'ailleurs
pas le premier à vous donner de tels conseils.

Sa solution n'en est pas une puisqu'elle ne fonctionne pas dans le
navigateur le plus utilisé. Quand à la forme, c'est justement contre
celle-ci que je m'insurgeais. Etes-vous allez vous renseigner sur ce
qu'est la "communication paradoxale" ? Ce n'étais pas un effet de style
mais l'énoncé de quelque chose de précisément défini et qui pour la
bonne entente général est à bannir le plus souvent.

Concernant vos réponses (vous, Paul), elles ne m'ont jamais blessées,
simplement parce que vous ne pratiquez pas cette fameuse communication
paradoxale, ce qui n'est pas le cas de Nicolas George : chacun a a
apprendre chaque jour : moi et lui tout autant ! Alors, disons que j'ai
à travailler mes connaissance HTTP/CGI et qu'il a à travailler son mode
de communication.

Votre question qui ne concerne qu'un problème de HTML/HTTP et qui n'a
aucun rapport avec Perl pouvait être compriese de deux manières :

soit vous n'avez pas bien fait la séparation entre ce que fait
HTML/HTTP et ce que fait Perl. C'est, à mon avis, ce qu'a supposé
Nicolas George et ce qui l'a amené à formuler ses conseils (il a
même pris de gants en précisant "je ne veux pas être méchant"). Et
il a aussi pris le temps de vous donner quelques éléments de
réponse...

soit vous faites tout à fait la différence et alors vous vous
permettez de poser une question qui n'a rien à faire sur ce forum au
mépris des quelques règles d'usage.

Aucun des deux options : il aurait par exemple pu exister un module que
je ne connaitrais pas (ce qui est assez aisé), qui résoudrait ce sujet
et que je pourrais aller voir. Parler Perl n'est pas nécessairement
parler syntaxe et langage pur, ce peut être aussi d'aborder tous sujet
dès lors que le langage utilisé est celui-ci dans 'application
concernée. Par exemple, ce fil récent concernant un "Portail".

Enfin et pour préciser mon intervention, ce "je ne veux pas être
méchant" est précisément ce qui rend son discours paradoxal. Si l'envie
vous titille de chercher sur ce "mode de communication paradoxal", trop
souvent utilisé de nos jours, j'en serai heureux.

À vote place, j'aurais préféré la première manière : mieux vaut passer
pour un ignorant que pour un incompétent.

Il ne me semble pas cacher mon ignorance actuelle dans les sujets que
sont le CGI/HTTP et Perl. Où avez-vous vu ça ?

Je pose et poserai mes questions quand il me semblera nécessaire
avec ou sans ton aval...

Puisque c'est là votre manière de voir les choses, appliquez cela à
vous-même et admettez donc que les autres vous répondent quand ils le
veulent et de la manière qu'ils veulent.

C'est de toute façon ce que chacun fait ! Celà ne me dérange pas le
moins du monde dès lors que la règle est *réciproque*... Acceptez donc
que je ne sois pas complètement stoïque lorsque quelqu'un vient me dire
les choses sur un mode bien loin du convivial et cordial qu'il pourrait
être (et ce pour la seconde fois, au moins)...

kurtz le pirate

29/04/2006 à 09:50

In article ,
Asterbing wrote:

In article ,
says...
monsieur joue les analystes ? mdr !!

Pourquoi présager lorsque l'on ne sait pas qui est en face, exactement.
Je ne comprendrai jamais ce type de penser, pas plus que ces modes de
communication paradoxaux dont je vous ai déjà trop parlé. Ce n'est pas
inintéressant.

puisque tu en ai là, ta question n'a rien à voir avec perl. c'est le
html qu'il faut apprendre.

Alors, si je vais sur alt.html, viendras-tu me livrer LA solution ? Je
n'attends que ça : la solution... Puisque le chemin passant par data:
URI ne fonctionne pas dans Internet Explorer.

peut être justement que sur *.html, tu auras plus de réponses. le
problème (html je répète), c'est que ie ne supporte pas la construction
que Nicolas George a donné qui fonctionne bien avec d'autres vrais
navigateurs... et là, on s'éloigne encore de ce forum sur perl !

--
klp

Asterbing

29/04/2006 à 13:08

In article ,
says...

peut être justement que sur *.html, tu auras plus de réponses. le
problème (html je répète), c'est que ie ne supporte pas la construction
que Nicolas George a donné qui fonctionne bien avec d'autres vrais
navigateurs... et là, on s'éloigne encore de ce forum sur perl !

Bon, pour que ce fil n'ait pas été tout à fait vain, voici le compte
rendu final que je vous livre comme quelqu'un qui se préoccupe de ne pas
garder les choses pour lui-même :

J'avais tenté fr.comp.lang.perl parce qu'il n'est pas aisé de déterminer
le domaine d'un problème lorsqu'on ne cerne pas les solutions possible :
il aurait par exemple, et entre autres, été possible que Perl puisse
gérer la notion répandue aileurs de fichier mémoire (c.a.d. de traiter
un bloc mémoire RAM comme ,s'il s'agissait d'un fichier disque)...

Ensuite, sur vos conseils, j'ai tenté alt.html parce que je ne pense pas
qu'il s'agisse de quelque chose de couramment pratiqué en html, mais de
la recherche d'une voie alternative.

J'ai obtenu trois réponses sur alt.html qui ne me donnent rien de plus
que ce que Nicolas a exprimé : l'usage de data: URI. Mais IE rend cette
solution inopérante dans un contexte où les navigateurs visiteurs ne
sont pas maitrisés. Je me moque de savoir quels sont les vrais et faux
navigateurs, simplement je vois les logs et constate qu'IE reste
incontournable (70% des accès dans notre cas).

Fort de tout ça, je suis parti en quête d'autres voies qui présentent
chacune leur avantages et inconvénent... Puis ai fait mon choix ! En
guise de résumé de celles-ci, voici ce que j'ai mis sur alt.html :

"Well, thanks David, Jim and Alan, but it seems it's a no way problem
[parlant de data: pour IE]. Elsewhere, I've seen some solutions going
with <OBJECT> or XBM conversion or MIME encapsulation... But I think
I'll go to something easier like a POST (afraid of GET because of lengh
url limitation, knowing my largest images may be of 10KB, while smallest
50 bytes) of the image data toward a cgi which will sent it back to
browser in the framework of an <img> tag."

Voilà ! Ceci termine ce fil dans le but que chacun en tire quelque
chose. Merci tout de même à chacun (Nicolas compris), malgré nos coups
de gueule respectifs et la difficulté de toujours se comprendre sans
connaitre le tempérament de l'autre.

In article <kurtzlepirate-F34209.09504329042006@nnrp7-2.proxad.net>,
kurtzlepirate@yahoo.fr says...

peut être justement que sur *.html, tu auras plus de réponses. le
problème (html je répète), c'est que ie ne supporte pas la construction
que Nicolas George a donné qui fonctionne bien avec d'autres vrais
navigateurs... et là, on s'éloigne encore de ce forum sur perl !

Bon, pour que ce fil n'ait pas été tout à fait vain, voici le compte
rendu final que je vous livre comme quelqu'un qui se préoccupe de ne pas
garder les choses pour lui-même :

J'avais tenté fr.comp.lang.perl parce qu'il n'est pas aisé de déterminer
le domaine d'un problème lorsqu'on ne cerne pas les solutions possible :
il aurait par exemple, et entre autres, été possible que Perl puisse
gérer la notion répandue aileurs de fichier mémoire (c.a.d. de traiter
un bloc mémoire RAM comme ,s'il s'agissait d'un fichier disque)...

Ensuite, sur vos conseils, j'ai tenté alt.html parce que je ne pense pas
qu'il s'agisse de quelque chose de couramment pratiqué en html, mais de
la recherche d'une voie alternative.

J'ai obtenu trois réponses sur alt.html qui ne me donnent rien de plus
que ce que Nicolas a exprimé : l'usage de data: URI. Mais IE rend cette
solution inopérante dans un contexte où les navigateurs visiteurs ne
sont pas maitrisés. Je me moque de savoir quels sont les vrais et faux
navigateurs, simplement je vois les logs et constate qu'IE reste
incontournable (70% des accès dans notre cas).

Fort de tout ça, je suis parti en quête d'autres voies qui présentent
chacune leur avantages et inconvénent... Puis ai fait mon choix ! En
guise de résumé de celles-ci, voici ce que j'ai mis sur alt.html :

"Well, thanks David, Jim and Alan, but it seems it's a no way problem
[parlant de data: pour IE]. Elsewhere, I've seen some solutions going
with <OBJECT> or XBM conversion or MIME encapsulation... But I think
I'll go to something easier like a POST (afraid of GET because of lengh
url limitation, knowing my largest images may be of 10KB, while smallest
50 bytes) of the image data toward a cgi which will sent it back to
browser in the framework of an <img> tag."

Voilà ! Ceci termine ce fil dans le but que chacun en tire quelque
chose. Merci tout de même à chacun (Nicolas compris), malgré nos coups
de gueule respectifs et la difficulté de toujours se comprendre sans
connaitre le tempérament de l'autre.

Vous avez filtré cet utilisateur ! Consultez son message

In article ,
says...

peut être justement que sur *.html, tu auras plus de réponses. le
problème (html je répète), c'est que ie ne supporte pas la construction
que Nicolas George a donné qui fonctionne bien avec d'autres vrais
navigateurs... et là, on s'éloigne encore de ce forum sur perl !

Bon, pour que ce fil n'ait pas été tout à fait vain, voici le compte
rendu final que je vous livre comme quelqu'un qui se préoccupe de ne pas
garder les choses pour lui-même :

J'avais tenté fr.comp.lang.perl parce qu'il n'est pas aisé de déterminer
le domaine d'un problème lorsqu'on ne cerne pas les solutions possible :
il aurait par exemple, et entre autres, été possible que Perl puisse
gérer la notion répandue aileurs de fichier mémoire (c.a.d. de traiter
un bloc mémoire RAM comme ,s'il s'agissait d'un fichier disque)...

Ensuite, sur vos conseils, j'ai tenté alt.html parce que je ne pense pas
qu'il s'agisse de quelque chose de couramment pratiqué en html, mais de
la recherche d'une voie alternative.

J'ai obtenu trois réponses sur alt.html qui ne me donnent rien de plus
que ce que Nicolas a exprimé : l'usage de data: URI. Mais IE rend cette
solution inopérante dans un contexte où les navigateurs visiteurs ne
sont pas maitrisés. Je me moque de savoir quels sont les vrais et faux
navigateurs, simplement je vois les logs et constate qu'IE reste
incontournable (70% des accès dans notre cas).

Fort de tout ça, je suis parti en quête d'autres voies qui présentent
chacune leur avantages et inconvénent... Puis ai fait mon choix ! En
guise de résumé de celles-ci, voici ce que j'ai mis sur alt.html :

"Well, thanks David, Jim and Alan, but it seems it's a no way problem
[parlant de data: pour IE]. Elsewhere, I've seen some solutions going
with <OBJECT> or XBM conversion or MIME encapsulation... But I think
I'll go to something easier like a POST (afraid of GET because of lengh
url limitation, knowing my largest images may be of 10KB, while smallest
50 bytes) of the image data toward a cgi which will sent it back to
browser in the framework of an <img> tag."

Voilà ! Ceci termine ce fil dans le but que chacun en tire quelque
chose. Merci tout de même à chacun (Nicolas compris), malgré nos coups
de gueule respectifs et la difficulté de toujours se comprendre sans
connaitre le tempérament de l'autre.

Nicolas George

29/04/2006 à 13:47

Asterbing wrote in message
:

afraid of GET because of lengh
url limitation, knowing my largest images may be of 10KB, while smallest
50 bytes

Cette parenthèse suffit à montrer que comme je le soupçonnais il y a un gros
problème de compréhension des mécanismes mis en jeu à la base. Mais je n'ai
vraiment aucune envie de perdre du temps à expliquer ça à quelqu'un qui
méprise mes explications et mes conseils.

Patrick Texier

29/04/2006 à 17:46

Le Sat, 29 Apr 2006 13:08:06 +0200, Asterbing a écrit :

Ensuite, sur vos conseils, j'ai tenté alt.html parce que je ne pense pas
qu'il s'agisse de quelque chose de couramment pratiqué en html, mais de
la recherche d'une voie alternative.

Sur fr.* le groupe html,cgi a effectivement un nom épouvantable :
<news:fr.comp.infosystemes.www.auteurs>.

Afficher une image en RAM parmi du texte

10 réponses

Veuillez sélectionner un problème