nicht angemeldet
NS 4.78 druckt mit JavaScript erzeugte Seite falsch aus
Hallo allerseits,
beim Entwickeln eines Online-Shops mit Hilfe von ShopFactory V5.40 Developer bin ich auf ein Problem mit NS 4.78 gestoßen (unter Win XP, falls das etwas damit zu tun haben sollte...):
Ich erzeuge mit JavaScript dynamisch ein neues Browser-Fenster, in dem Informationen über die zu tätigende Bestellung in Tabellenform zum Druck bereitgestellt werden. Der Druck funktioniert in IE 6, NS 6.1, Opera 6 und Mozilla 0.9.8. In NS 4.78 wird die Seite ebenfalls korrekt dargestellt, in der Druckvorschau und logischerweise auch beim Druck werden die Buchstaben jedoch durch Quadrate sowie ganz selten auch andere, exotische Zeichen ersetzt, so als ob die Schriftart nicht vorhanden sei, was jedoch nicht der Fall ist (Arial, korrekt installiert und funktionsfähig). Es erscheinen zudem weniger Quadrate als sonst Buchstaben. Die Quadrate sind von der Anordnung und der Größe her korrekt gesetzt. Die horizontal rules und Tabellenumrandungen erscheinen ebenfalls korrekt.
Wer es sich ansehen möchte: http://www.ccswebdesign.de/scharpenberg-shop/ (als Benutzernamen und Passwort jeweils "shoptest" eingeben). Einen Artikel in den Warenkorb packen, zur Kasse gehen, "Deutsche Post" als Versandart wählen, Button "Weiter" drücken, Daten eingeben, nach unten blättern und auf den Drucker klicken. Es erscheint das besagte Fenster.
Eigenartig ist Folgendes: Wenn ich den Quellcode des generierten Fensters kopiere, abspeichere und diese Datei in NS 4.78 lade, funktioniert die Druckfunktion korrekt!
Ein Leeren des Caches, Anzeige nur mit Standardschriftarten (Times New Roman) und ein Wechsel des Druckertreibers (anderes Druckermodell) waren erfolglos.
Für Hilfe wäre ich sehr dankbar!
Gruß,
Jan
-
Holladiri
In NS 4.78 wird die Seite ebenfalls korrekt dargestellt, in der Druckvorschau und logischerweise auch beim Druck werden die Buchstaben jedoch durch Quadrate sowie ganz selten auch andere, exotische Zeichen ersetzt, so als ob die Schriftart nicht vorhanden sei, was jedoch nicht der Fall ist (Arial, korrekt installiert und funktionsfähig). Es erscheinen zudem weniger Quadrate als sonst Buchstaben. Die Quadrate sind von der Anordnung und der Größe her korrekt gesetzt. Die horizontal rules und Tabellenumrandungen erscheinen ebenfalls korrekt.
Na, da hast Du aber echt Glück gehabt ;-)
Bei mir hat Netscape schon ganz andere Sachen gemacht, als da wären:- Gar nicht drucken
- Pro Zeile ein Zeichen drucken
- Grafiken kaputt drucken
- Alles nur noch untereinander und gar nix mehr nebeneinander drucken
- viele tolle Sachen mehr.
Finde Dich damit ab: Die Druckfunktion dieses Browser ist sch****. Punkt. Stefan hat selbst schon den Tip gegeben: Es wird Zeit, NC4 Benutzer etwas "anzuschupsen". Wer noch NC4.X benutzt, bekommt zwar eine benutzbare Seite, aber alle Zusatzsachen (z.B. korrektes Layout, und IMHO auch Druckfunktion etc) gibt's nur noch für moderne Browser.
Ciao,
Harry
-
Finde Dich damit ab: Die Druckfunktion dieses Browser ist sch****. Punkt. Stefan hat selbst schon den Tip gegeben: Es wird Zeit, NC4 Benutzer etwas "anzuschupsen". Wer noch NC4.X benutzt, bekommt zwar eine benutzbare Seite, aber alle Zusatzsachen (z.B. korrektes Layout, und IMHO auch Druckfunktion etc) gibt's nur noch für moderne Browser.
Das ist schon wahr, nur finde ich es auf einer kommerziellen Seite nicht so wunderschön, den Kunden zu sagen, das eine Feature funktioniert nicht bei Browser A, das andere nicht bei Browser B und das dritte nur bei Browser C und D. Macht irgendwie nicht den allerbesten Eindruck. Bisher habe ich's auch immer irgendwie geschafft, zumindest Workarounds zu finden, wenn keine elegante Lösung möglich war, aber in diesem Fall habe ich leider so ganz und gar keine Vorstellung, was eigentlich abläuft. Vielleicht weiß jemand, woran NS sich verschlucken könnte? Im Web habe ich leider so schnell keine Informationen über dieses Problem finden können, aber ich kann mir andererseits nicht vorstellen, dass nur ich betroffen sein soll... ;-)
Ciao,
Jan-
Hallo,
aber ich kann mir andererseits nicht vorstellen, dass nur ich
betroffen sein soll...da mach Dir keine Sorgen, beim Netscape 4.xy sind immer viele betroffen ;-) (oder besser ;-/)
Dein Problem hatte ich auch schon vor einiger Zeit gehabt, bei mir waren es dynamisch eingefügte Div-bereiche mit dort eingebeteten Bildern die er nicht druckte. Das Problem scheint in der tat das "dynamisch gerenrierte" zu sein, habe zwar keine Ahnung vom NS und Browser Programmieren, aber beim Drucken schein der NS in der Tat nicht den Quellcode, den der Browser gerade "im Kopf hat" und anzeigt zur Druckroutiene zu übergeben, sondern "nur" die Seite, die per Internetanbindung zu ihm gekommen ist. Und da stehen ja defacto die nachträglich eingefügten Code-Schnipsel nicht drin. (Wie sie ja auch nicht im Cache drin stehen, sondern nur auf dem Weg zum Auge des Betrachters "irgendwo" dazugeneriert werden....)
Eine Lösung gibts scheinbar nicht, die Erfahrung muste ich schon mal selber machen. Bleibt nur, das Leute mit einem kaputen browser eben die Seite nicht ausdrucken können.... sehr ärgerlich, wenn man aufs Geld der leute mit kaputten Browser rechnen möchte/muß (was ich sehr verstehen kann....)
Chräcker
-
Das Problem scheint in der tat das "dynamisch gerenrierte" zu sein, habe zwar keine Ahnung vom NS und Browser Programmieren, aber beim Drucken schein der NS in der Tat nicht den Quellcode, den der Browser gerade "im Kopf hat" und anzeigt zur Druckroutiene zu übergeben, sondern "nur" die Seite, die per Internetanbindung zu ihm gekommen ist. Und da stehen ja defacto die nachträglich eingefügten Code-Schnipsel nicht drin. (Wie sie ja auch nicht im Cache drin stehen, sondern nur auf dem Weg zum Auge des Betrachters "irgendwo" dazugeneriert werden....)
Ich bin nicht ganz sicher, ob ich mich klar genug ausgedrückt habe... Datei A erzeugt ein neues Browserfenster und schreibt in dieses Fenster lediglich HTML-Daten. Die so erzeugte "Datei" B besteht also ebenso aus HTML-Daten wie jede andere, die der Browser aufruft. Und zumindest zum Teil scheint er diese ja wohl korrekt zu interpretieren, denn sie wird korrekt angezeigt und "bis auf die Buchstaben" (ist ja auch unwichtig... ;-) ) auch korrekt ausgedruckt. Jedenfalls ist es nicht die über das Internet geladene Datei A, die gedruckt wird!
Gruß,
Jan-
Hallo,
Jedenfalls ist es nicht die über das Internet geladene Datei A,
die gedruckt wird!doch, ja, genau so habe ich es auch verstanden. Und da steckt (wohl) das Problem. denn die Seite A könnte er drucken, die ist übern Draht gekommen, in sein Hirn gerutscht und wurde so, wie sie gekommen ist, dargestellt. Aber das neue fenster mit dem neuen Code hat er "im kopf" zusammengesetzt. Die neue html-Seite im neuen fenster existiert ja nirgends wirklich sondern wurde generiert. Dynamisch eben. Er zeigt sie an, immerhin, (landen solche Seiten eigendlich auch im Cache?), aber sie ist so nicht "zu ihm " gekommen. und da scheint(!) der alte NS seine Probleme zu haben. Denn dieses nachträglich generirete html" ist der gemeinsame Nenner "unserer beider Probleme beim ausdrucken von "beim besuchercomputer" generierten html-Code.
Chräcker (wie gesagt, nur eine vermutung und die Bestätigung, daß auch andere Schwierigkeiten haben beim ausdrucken von dynamisch erzeugten html-Code....)
-
Holladiri
Chräcker (wie gesagt, nur eine vermutung und die Bestätigung, daß auch andere Schwierigkeiten haben beim ausdrucken von dynamisch erzeugten html-Code....)
Ich kann mich Deiner Vermutung nur anschliessen. Bei mir ging es auch um dynamisch generierte Divs. Ganz nebenbei scheint er aber auch irre Probleme mit per CSS absolut positionierten Divs zu haben :-(
Ich hasse dieses Ding.
Ciao,
Harry
-
Ich hasse dieses Ding.
Diesen Gedanken hatte ich auch schon mehrfach... ;-))
Tja, dann muss ich mich wohl zunächst einmal damit abfinden, vielen Dank jedenfalls! Sollte ich doch noch ein Workaround finden, werde ich's an dieser Stelle posten.
Ciao,
Jan-
Hallo,
ich hab's doch noch herausgefunden. Für den Fall, dass die Lösung jemanden interessiert: ShopFactory setzt in den Head-Bereich den Meta-Tag <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> hinein - und just dieses UTF-8 verursacht die Probleme. Bei Verkürzung auf <meta ... "text/html"> ist alles wieder, wie es sein soll. Kleine Ursache, große Wirkung. Darauf hätte ich wohl auch früher kommen können, aber irgendwie habe ich den Tag völlig ignoriert... :-(
Ich verstehe zwar immer noch nicht, warum keine Probleme entstehen, wenn genau der gleiche Quelltext aus einer Datei geladen wird, aber das wird wohl für immer Netscapes Geheimnis bleiben...
Bye,
Jan
-
-
-
-
-
-