Discussion :

[cmail]

Si l'impression des cartes de l'api sous ff3 ne me pose pas de problème, il en est différemment sous ie8.

J'ai bien noté la discussion sur l'impression des cartes portée par 404error ici. Aujourd'hui y-a t'il des nouveautés de ce coté là?

Sinon, luigifab avait mentionné une pseudo solution ici que je n'arrive pas à mettre en oeuvre sous ie8. Une url d'un exemple qui marche me serait utile pour comprendre...

Pour ma part, soit j'introduis un link vers un fichier css media="print" avec
body { display:inherit !important; }

soit j'introduis

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<style type="text/css">
<!--
@media print
{
  body { display:inherit !important; }
}
-->
</style>

dans le "head" de mon fichier html contenant l'api.

Mais je n'ai rien en mode aperçu avant impression de ie8...

[dgrichard]

Si l'impression des cartes de l'api sous ff3 ne me pose pas de problème, il en est différemment sous ie8.

quel est le problème ?

J'ai bien noté la discussion sur l'impression des cartes portée par 404error ici. Aujourd'hui y-a t'il des nouveautés de ce coté là?

Non, c'est vraiment un sujet complexe : l'impression requiert de mettre en place (si le besoin fonctionnel est élevé comme imprimer les données vectorielles locales) une infrastructure côté serveurs importante ... sans compter la partie logicielle (rapatriement des données, mise en légende, fabrication de la carte, mise en page, etc ...)

Sinon, luigifab avait mentionné une pseudo solution ici que je n'arrive pas à mettre en oeuvre sous ie8. Une url d'un exemple qui marche me serait utile pour comprendre...

Je ne comprends pas il te suffit d'insérer la surcharge CSS en respectant les règles habituelles (donc, en insérant les CSS de l'API dans ta page) ?!

Pour ma part, soit j'introduis un link vers un fichier css media="print" avec
body { display:inherit !important; }

soit j'introduis

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<style type="text/css">
<!--
@media print
{
  body { display:inherit !important; }
}
-->
</style>

dans le "head" de mon fichier html contenant l'api.

Mais je n'ai rien en mode aperçu avant impression de ie8...

Toujours pareil, as-tu d'abord inséré dans ta page les CSS de l'API ?

[cmail]

Ma page d'essai (des plus simples) est ici
Sous ff3, quand je fais un "Fichier>Aperçu avant impression", ma carte s'affiche bien.
Par contre sous IE8, la même demande ne donne pas la carte de l'API...

Toujours pareil, as-tu d'abord inséré dans ta page les CSS de l'API ?

Il me semble. Voir ma page d'essai.
Sinon voici le code concernant les css dans cette page pour t'éviter de perdre du temps:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
   ....     map.setCenterAtLonLat(4.24003,45.02590, 12);
    }
   </script>Fin des scripts et début des données css
   <!-- include CSS for easying overwriting of styles : -->
    <!-- OpenLayers styles : -->
    <link rel="stylesheet" type="text/css" href="http://api.ign.fr/geoportail/js/1.0/theme/default/style.css"/>
    <!--[if lte IE 6]>
    <link rel="stylesheet" type="text/css" href="http://api.ign.fr/geoportail/js/1.0/theme/default/ie6-style.css"/>
    <![endif]-->
    <!-- if OpenLayer.Layer.Google is used : -->
    <!--
    <link rel="stylesheet" type="text/css" href="http://api.ign.fr/geoportail/js/1.0/theme/default/google.css"/>
      -->
    <!-- if OpenLayers.Popup.FramedCloud is used : -->
    <!--
    <link rel="stylesheet" type="text/css" href="http://api.ign.fr/geoportail/js/1.0/theme/default/framedCloud.css"/>
      -->
    <link rel="stylesheet" type="text/css" href="http://api.ign.fr/geoportail/js/1.0/theme/geoportal/style.css"/>
    <!-- if Geoportal.Viewer.Standard is used : -->
    <!--
    <link rel="stylesheet" type="text/css" href="http://api.ign.fr/geoportail/js/1.0/theme/geoportal/standard.css"/>
  -->
<link href="./css/cmailCadastre.css" rel="stylesheet" type="text/css" media="screen" />
 
<style type="text/css">
<!--
@media print
{
  body { display:inherit !important; }
}
-->
</style>

</head>
<body ....

[dgrichard]

Il me semble. Voir ma page d'essai.
Sinon voici le code concernant les css dans cette page pour t'éviter de perdre du temps:

Les URLs des styles sont faux ... 404
Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

http://api.ign.fr/geoportail/js/1.0/theme/default/style.css

alors que :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

http://api.ign.fr/geoportail/api/js/1.0/theme/default/style.css

Sinon, en essayant aussi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
<style type="text/css">
<!--
@media print
{
  body { display:block !important; }
}
-->
</style>

cela donne quoi ?

[cmail]

Les URLs des styles sont faux

Bizarre... Je ne sais pas d'où cela vient... Maintenant c'est changé d'une manière uniforme...
Mais cela ne changeait rien au problème ie8.
En passant avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 Code  :
     <style type="text/css">
<!--
@media print
{
  body { display:block !important; }
}
-->
</style>

C'est mieux, mais pas parfait.
Mieux parce que le cadre de l'api s'affiche avec parfois (rarement) quelques tuiles. Mais en général, il n'y a pas de tuiles et de vilaines croix rouges.

[cmail]

En complément d'information, si cela peut aider à débloquer le problème.
Sous IE8, avec modification "css print" comme énoncé plus haut, en mode "Fichier>Aperçu avant impression", on constate qu'en changeant l'orientation de la feuille (paysage<>portrait) certaines tuiles apparaissent ou disparaissent... Mais je n'arrive jamais à avoir l'ensemble des tuiles déjà affichées par ailleurs sur l'écran en mode consultation classique .

Ultime question: Quelqu'un a-t-il déjà imprimé sa carte API via IE8?

[dgrichard]

C'est mieux, mais pas parfait.
Mieux parce que le cadre de l'api s'affiche avec parfois (rarement) quelques tuiles. Mais en général, il n'y a pas de tuiles et de vilaines croix rouges.

Le cadre, c'est probablement du au 100% (ou pourcentage), la mise en page peut avoir des problèmes. J'ai pris pour habitude de donner des tailles fixes.

Les vilaines croix rouges sont des requêtes qui échouent ... Je ne sais pas comment IE fait !

[cmail]

Même si cela pourra paraitre évident à certain, je tiens à préciser qu'il n'y a pas de problème d'impression sous ie8 pour des fichiers vectorisés style KML. Le problème est lié uniquement à l'impression des "tuiles ign" qui ne s'affichent pas d'une manière complète.

Une idée?

[dgrichard]

Même si cela pourra paraitre évident à certain, je tiens à préciser qu'il n'y a pas de problème d'impression sous ie8 pour des fichiers vectorisés style KML. Le problème est lié uniquement à l'impression des "tuiles ign" qui ne s'affichent pas d'une manière complète.

N'importe quel KML ? Je veux dire : un KML avec légende embarqué et un KML pris en charge par l'API (labels, etc ...).

Sur les tuiles IGN, je reste persuadé que c'est lié au jeton, à la GeoDRM, ...

[cmail]

les tuiles IGN, je reste persuadé que c'est lié au jeton, à la GeoDRM, ...

C'est sûr! Mais comment on fait?

1. Est-ce un problème sur lequel ton service travaillera pour le résoudre?
2. Ou à chaque utilisateur de l'Api de se débrouiller? Ce qui ne sera pas à ma portée... Sauf à mentionner sur nos pages avec API que "l'impression n'est pas possible avec IE8"

[dgrichard]

C'est sûr! Mais comment on fait?

1. Est-ce un problème sur lequel ton service travaillera pour le résoudre?

Oui, à terme

1. Ou à chaque utilisateur de l'Api de se débrouiller? Ce qui ne sera pas à ma portée... Sauf à mentionner sur nos pages avec API que "l'impression n'est pas possible avec IE8"

En attendant ... Maintenant, l'impression sert à quoi ? As-tu vraiment besoin d'avoir un 100% en largeur ? etc .... Une copie d'écran ne fera pas mieux !

Il faut prendre conscience du coût de l'impression :

* si elle est faîte côté client (butineur par exemple) : néant pour l'infrastructure ;
* si elle est faîte côté serveur (Géoportail par exemple) : énorme, combien d'impressions gérer ? quels formats ? quelles orientations? quelles résolutions ? comment importer les données locales (KML, GPX) ? Les mettre en cartographie ? quelles couches s'afficheront en fonction de la résolution choisie ?

C'est donc un problème d'équilibre économique / technique qui est à trouver et pour lequel je n'ai pas de réponse aujourd'hui.

[cmail]

L'impression papier est importante en fonction des services qu'on veut rendre...
Personnellement, je me passe très bien d'impression papier.

Mais je suis en train de proposer à ma petite commune (1000 habitants) une gestion du cadastre via l'API. Et il se trouve que le Conseil municipal souhaiterait que cette possibilité d'imprimer un parcellaire soit accessible. Et en effet, dans ce cas là, pour le commun des administrés surtout en milieu rural, cela se comprend assez bien. L'idée était donc d'utiliser les fonctions d'impression des navigateurs (avec des css print adaptés) mais manque de bol, sous ie8 les tuiles ne s'affichent pas (et cela quelque soit la largeur (fixe ou proportionnelle) donnée à l'api)... C'est quand même très dommage puisque cela comblerait les besoins élémentaires sans partir dans des considérations très sophistiquées coté serveur
Alors faire une impression écran, puis l'imprimer, certes, mais cela complique un peu les manips pour le rendre accessible à tous...

2/ Je vois aussi un autre cas, qui pourrait être plus fréquent que le mien défini ci-dessus, ou l'impression papier est souhaitable. C'est dans le cas des circuits de randonnée... Il est quand même plus facile de se déplacer avec un plan papier, que son micro! En attendant la généralisation des ipad! Prenons le cas de notre ami zébulon. Un dijonnais veut faire une sortie, consulte le site de valroc, trouve une rando qui lui convient.... Pas de pot! Il est sous ie8. Les dijonnais ne sont pas tous des pro du clavier, et la touche "impr écr" est souvent ignorée du commun des mortels.

Aussi, ce serait vraiment sympa que cette question "impression basique avec les fonctions d'impression d'IE8" soit un peu déboquée. De mon coté, cela tourne en rond. Je n'ai aucune demande du type "impression coté serveur"

[cmail]

Mes bouderies sont très passagères...

Sinon. OK, le problème provient probablement de IE8, mais
1/ MS ne répond évidemment pas (et je comprends assez bien pourquoi) à mes différentes demandes sur ce problème.
2/ Alors ma question serait plutôt de savoir si du coté de l'IGN, il n'y aurait pas une astuce API/OL pour "maintenir les tuiles lors de l'impression" sous IE8.

Ce qui me chagrine avec l'intégration d'une impression pdf, c'est que je perderai (sauf erreur de ma part) l'interêt de mes css media print que j'ai peaufinés et qu'il faudra rajouter un bouton outil "impression" dans mon interface, avec son flot de tests et de codage... Alors qu'on a l'utilitaire dans le navigateur...

[Jérôme_C]

Une impression PDF reste une impression (l'envoi d'un fichier postscript au driver d'impression ? ), si tu fais une impression pdf, tous tes css media print devrait être utilisé !


Tu as essayé de voir ce qu'a donné cette fameuse impression pdf, juste pour voir ? Le dgrichard, ce n'est pas un SAV à l'autre bout du monde qui suit une checklist, je pense que tu peux au moins tester cette impression pdf

[cmail]

Tu as essayé de voir ce qu'a donné cette fameuse impression pdf, juste pour voir ?

Décidément beaucoup d'humour!
Mais mon problème n'est pas d'imprimer en pdf. Je vois mal un service en ligne centré sur l'API, dire à sa majorité de visiteurs (sous IE8) : "Pour imprimer la carte de l'IGN, installez d'abord pdfcreator, puis....". Bonjour l'ergonomie!
Mon problème (encore une fois) est d'utiliser la fonction "Fichier>imprimer" de IE8 et que les tuiles IGN soient prises en compte.

[mga_geo]

L'impression via un driver pdf est juste un moyen de faire un diagnostic si j'ai bien compris les échanges précédents.
Effectivement l'installation d'un pilote "pdf" n'est pas la solution.
De même l'utilisation d'un seul navigateur ne permet pas de satisfaire à tous les besoins. Il faut alors passer par l''éducation de ses utilisateurs ce qui est une tâche plus facile que de faire évoluer les mastodontes.

[cmail]

@mga_geo (ou acign?????) : Parole de sage

Et histoire d'en rajouter une couche ...
http://forum.joomla.fr/showthread.ph...ortail-dans-ie

[dgrichard]

L'impression via un driver pdf est juste un moyen de faire un diagnostic si j'ai bien compris les échanges précédents.
Effectivement l'installation d'un pilote "pdf" n'est pas la solution.

De mon point de vue, l'impression PDF est plus "green" et pas simplement une procédure de diagnostic : le PDF est réutilisable, réimprimable, peut être inséré dans un rapport, une page web, etc ... La dématérialisation des documents administratifs est donc plus orienté PDF que papier

De même l'utilisation d'un seul navigateur ne permet pas de satisfaire à tous les besoins. Il faut alors passer par l''éducation de ses utilisateurs ce qui est une tâche plus facile que de faire évoluer les mastodontes.

Quelqu'un a-t-il essayé IE9 bêta (sous Windows7) ?

[cmail]

J'ai testé le nouveau control Printmap ... Même si je n'ai pas encore bien vu tout et notamment comment le css print (ou les paramètres header, prolog, etc.) était introduit dans l'exemple http://api.ign.fr/geoportail/api/doc...rtalAlert.html
Cela ouvre de nouvelles perspectives... Encore merci pour vos (toute l'équipe de Api-IGN) incessantes améliorations.
Je ne doute pas que vos essais sous IE8 ont été corrects.
Cependant, je tiens à vous transmettre la copie d'écran d'un résultat d'impression (pdf) ici sous IE8 qui ne manque pas de relancer le débat. Non?

[dgrichard]

J'ai testé le nouveau control Printmap ... Même si je n'ai pas encore bien vu tout et notamment comment le css print (ou les paramètres header, prolog, etc.) était introduit dans l'exemple http://api.ign.fr/geoportail/api/doc...rtalAlert.html
Cela ouvre de nouvelles perspectives... Encore merci pour vos (toute l'équipe de Api-IGN) incessantes améliorations.

Il faut regarder Geoportal.Control.PrintMap.js

Je ne doute pas que vos essais sous IE8 ont été corrects.

Le composant reste expérimental. Tous les tests n'ont pas été concluants (en particulier sous Safari). Mais, on continuera à améliorer (dans la limite de nos capacités) le composant.