Warum werden gedruckte Seiten immer abgeschnitten?
Dominik Schmidt
das Problem habe ich nun eigentlich schon seitdem ich Browser benutze.
Seiten, die im Browserfenster perfekt angezeigt werden, werden beim
Ausdrucken (genau wie in der Druckvorschau) abgeschnitten (rechts).
Beispiel: Ebay-Artikelseiten: Der Text läuft nach rechts einfach über den
Seitenrand hinaus und wird somit abgeschnitten (übrigens Adresse und
Uhrzeit vom Druck auch - weiß nicht, ob das zusammenhängt).
Beim Fuchs gibt's ja eine Funktion um die Seite verkleinert zu drucken -
das bringt aber auch nichts, dann wird bloß woanders abgeschnitten (und die
Lesbarkeit leidet).
Die Standardeinstellung "Shrink To Fit" funktioniert offenbar auch nicht -
das gedruckte wird abgeschnitten und damit "fittet" es eben nicht.
Woher kommt das Problem?
Warum scheint der Browser beim Drucken nicht zu wissen, wo die Ränder sind,
obwohl er das bei der elektronischen Anzeige weiß?
Was kann man machen?
Danke...
Hartmut Figge
>Beispiel: Ebay-Artikelseiten: Der Text läuft nach rechts einfach über den
>Seitenrand hinaus und wird somit abgeschnitten (übrigens Adresse und
>Uhrzeit vom Druck auch - weiß nicht, ob das zusammenhängt).
Mit meinem SM konnte ich das Problem nicht reproduzieren. Möglicherweise
lag es an der verwendeten Seite.
Gib doch mal eine bestimmte an. Ein Screenshot vom Print Preview
derselben wäre auch nicht schlecht.
>Beim Fuchs ...
Ach ja, bei welchem Fuchs?
Hartmut
--
Usenet-ABC-Wiki http://www.usenet-abc.de/wiki/
Von Usern fuer User :-)
Micha Kuehn
> Mit meinem SM konnte ich das Problem nicht reproduzieren. Möglicherweise
> lag es an der verwendeten Seite.
Ich nutze (noch) SM 1.1.10 und da gibt es sowas auch, siehe z.B.
http://www.bm-kuehn.de/temp/080923-screenshot-seamonkey.jpg (160 KB)
gedruckt wurde
http://www.druckerzubehoer.de/shop/faqsubcategory.phtml?catid=Fragen%20Druckerzubeh%F6r&subcatid=Fragen%20Druckerzubeh%F6r-Erlischt%20die%20Herstellergarantie&shopid=8504887c22126f89792701a34be789ca&lng=de_DE&visitid=aXyTuuYvqUyXpJEBxhHQzh7K6q3aq3GqInnuuUnnHGuur#garantie
(sorry für den langen URL, die Seite war gerade offen).
Ich denke, dass das an der Seite selbst liegt: Wenn da Tabellenlayout
verwendet wurde, gibt es offenbar Probleme.
Und das Datum oder was unten rechts steht wird bei mir auch öfter
(immer?) abgeschnitten, aber das nicht im Preview.
Micha
--
Persönliche Mails: Bitte nur als reply - und als Wurmkur werden alle
Mails > 100 KB automatisch und unbesehen gelöscht!
Ilja Sekler
> Hartmut Figge schrieb:
>
>> Mit meinem SM konnte ich das Problem nicht reproduzieren.
>> Möglicherweise lag es an der verwendeten Seite.
>
> Ich nutze (noch) SM 1.1.10 und da gibt es sowas auch, siehe z.B.
> http://www.bm-kuehn.de/temp/080923-screenshot-seamonkey.jpg (160 KB)
SeaMonkey kann doch "Shrink to fit". Die Einstellung auf dem Screenshot:
"Skalierung: 100%".
> Ich denke, dass das an der Seite selbst liegt: Wenn da Tabellenlayout
> verwendet wurde, gibt es offenbar Probleme.
>
> Und das Datum oder was unten rechts steht wird bei mir auch öfter
> (immer?) abgeschnitten, aber das nicht im Preview.
Nach meiner Erfahrung muss man Mozillen zuallererst die Vorliebe zu
US-Letter austreiben. Dann klappt es auch mit dem Drucken.
Gruß,
Ilja
Hartmut Figge
>Hartmut Figge schrieb:
>> Mit meinem SM konnte ich das Problem nicht reproduzieren. Möglicherweise
>> lag es an der verwendeten Seite.
>
>Ich nutze (noch) SM 1.1.10 und da gibt es sowas auch, siehe z.B.
>http://www.bm-kuehn.de/temp/080923-screenshot-seamonkey.jpg (160 KB)
Sieht bei mir so aus:
http://www.triffids.de/pub/screenshot/sm080923.jpg (263 KB)
Trotz Verminderung der Qualität auf 70% immer noch eine ziemliche
Dateigröße. Sorry.
>gedruckt wurde
>http://www.druckerzubehoer.de/shop/faqsubcategory.phtml?catid=Fragen%20Druckerzubeh%F6r&subcatid=Fragen%20Druckerzubeh%F6r-Erlischt%20die%20Herstellergarantie&shopid=8504887c22126f89792701a34be789ca&lng=de_DE&visitid=aXyTuuYvqUyXpJEBxhHQzh7K6q3aq3GqInnuuUnnHGuur#garantie
>(sorry für den langen URL, die Seite war gerade offen).
Macht ja nichts. :)
>Ich denke, dass das an der Seite selbst liegt: Wenn da Tabellenlayout
>verwendet wurde, gibt es offenbar Probleme.
Auch jetzt kann ich bei mir keine feststellen.
>Und das Datum oder was unten rechts steht wird bei mir auch öfter
>(immer?) abgeschnitten, aber das nicht im Preview.
Also Unterschiede zwischen Preview und Ausdruck?
Ilja Sekler
> Hartmut Figge schrieb:
>
>> Mit meinem SM konnte ich das Problem nicht reproduzieren.
>> Möglicherweise lag es an der verwendeten Seite.
>
> Ich nutze (noch) SM 1.1.10 und da gibt es sowas auch, siehe z.B.
> http://www.bm-kuehn.de/temp/080923-screenshot-seamonkey.jpg (160 KB)
SeaMonkey kann doch "Shrink to fit". Die Einstellung auf dem Screenshot:
"Skalierung: 100%".
> Ich denke, dass das an der Seite selbst liegt: Wenn da Tabellenlayout
> verwendet wurde, gibt es offenbar Probleme.
>
> Und das Datum oder was unten rechts steht wird bei mir auch öfter
> (immer?) abgeschnitten, aber das nicht im Preview.
Nach meiner Erfahrung muss man Mozillen zuallererst die Vorliebe für
Andreas Schnellbacher
> Micha Kuehn:
>
> Sieht bei mir so aus:
> http://www.triffids.de/pub/screenshot/sm080923.jpg (263 KB)
>
> Trotz Verminderung der Qualität auf 70%
70%? Wo ist eine Einheit dafür normiert? JPEG reduziert auch bei
"100%".
> immer noch eine ziemliche Dateigröße. Sorry.
Ohne jetzt das eigentliche Thema zu kennen, möchte ich einen Tipp von
der Seite loswerden: Es gibt nur wenige Fälle, bei denen ein
Screenshot als JPG gespeichert kleiner wird, als das gleiche Bitmap in
PNG: Man muß dafür dann schon heftigst viel vom aufwendigen
Desktop-Hintergrundbild zeigen.
PNG ist für Screenshots besser geeignet. Außerdem treten keine
Infoverluste auf, außer man arbeitet mit Programmen die gleichzeitig
JPG-mäßige Komprimierung vornehmen. Dagegen ist JPEG immer (!) ein
verlustbehaftetes Format.
--
Andreas Schnellbacher
Lutz Illigen
> Woher kommt das Problem?
Unfähigkeit der webdeseiner.
> Was kann man machen?
Ich nehme in solchen Fällen zwangsweise den IE und easy webprint das
dem hier stehendem Canon Drucker beilag. Schrift ist zwar kleiner
aber es reicht.
Lutz
Hartmut Figge
>On 23.09.08 21:18, Hartmut Figge wrote:
>> Trotz Verminderung der Qualit�t auf 70%
>
>70%? Wo ist eine Einheit daf�r normiert? JPEG reduziert auch bei
>"100%".
Bei Einzelbildern bietet z.B. gimp die M�glichkeit, beim Speichern auch
die Qualit�t festzulegen. Bei einem ganzen Schwung von Photos benutze
ich einen Einzeiler zur Umwandlung in eine f�r News geeignete Gr��e und
zur Reduzierung der Dateigr��e.
for i in `ls *.JPG`;do convert -scale 800 -quality 70 $i t/$i; done
Mal schaun, ob ich f�r ImageMagick was im Web finden kann ... ah ja.
http://www.imagemagick.org/script/command-line-options.php#quality
>Ohne jetzt das eigentliche Thema zu kennen, m�chte ich einen Tipp von
>der Seite loswerden: Es gibt nur wenige F�lle, bei denen ein
>Screenshot als JPG gespeichert kleiner wird, als das gleiche Bitmap in
>PNG: Man mu� daf�r dann schon heftigst viel vom aufwendigen
>Desktop-Hintergrundbild zeigen.
Es kommt darauf an. :)
>PNG ist f�r Screenshots besser geeignet.
Jein. F�r Screenshots von Men�s stimmt es und daf�r nehme ich auch PNGs.
Sobald aber Screenshots vom Inhalt eines Browserfensters gemacht werden,
in dem etliche Farben vorkommen, sind JPGs von der Dateigr��e her
deutlich �berlegen.
Zeigt meine Praxis in den vergangenen Jahren.
>Au�erdem treten keine Infoverluste auf, au�er man arbeitet mit
>Programmen die gleichzeitig JPG-m��ige Komprimierung vornehmen.
>Dagegen ist JPEG immer (!) ein verlustbehaftetes Format.
Die Verminderung der Qualit�t auf 70% bei JPGs ist auf dem Bildschirm
kaum erkennbar, der Gewinn bei der Dateigr��e aber enorm.
Dominik Schmidt
Hartmut Figge schrieb:
> Gib doch mal eine bestimmte an. Ein Screenshot vom Print Preview
> derselben wäre auch nicht schlecht.
Also ein Beispiel:
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&Item=330273536783&Category=114728
Screenshot - Druckvorschau Firefox:
http://img510.imageshack.us/img510/4331/s1md1.jpg
(Wenn der Link nicht geht:
http://img510.imageshack.us/my.php?image=s1md1.jpg)
Screenshot - Druckvorschau Internet Explorer:
http://img58.imageshack.us/img58/6365/s2xi9.jpg
(Wenn der Link nicht geht:
http://img58.imageshack.us/my.php?image=s2xi9.jpg)
Wie deutlich sieht, ist die Umrandung mit der Palme abgeschnitten und der
Text darin auch.
Wieder meine Frage:
Wie kommt es, dass der Browser die Seite korrekt anzeigen kann, aber nicht
korrekt an den Drucker gibt?
> Ach ja, bei welchem Fuchs?
Spielt keine Rolle, denn das Problem habe ich, wie gesagt, seitdem ich
Browser benutze. Also auch vor vielen Jahren schon.
Im Screenshot: Firefox 3.0.1 und Internet Explorer 7
Dominik Schmidt
> Unfähigkeit der webdeseiner.
Wie bitte?
Da habe ich jetzt aber Mühe, das zu glauben...
Diese problematischen Webseiten werden doch im Browser korrekt angezeigt.
Und der Job des Webdesigners ist es in erster Linie, die Webseite für die
Anzeige am normalen Bildschirm zu optimieren. Natürlich sollte eigentlich
Design und Inhalt getrennt werden, sodass die Seite überall angezeigt
werden könnte - aber das wird doch (auch wegen mehr Designmöglichkeiten)
kaum gemacht...
Aber um es einfacher zu sagen: Wenn der Browser die Seite am Bildschirm
korrekt anzeigt - warum gibt er sie dann nicht korrekt an den Drucker
weiter?
>> Was kann man machen?
>
> Ich nehme in solchen Fällen zwangsweise den IE und easy webprint das
> dem hier stehendem Canon Drucker beilag. Schrift ist zwar kleiner
> aber es reicht.
Also hier noch mal ein Beispiel (hab ich oben schon mal gepostet):
Dominik Schmidt
> Nach meiner Erfahrung muss man Mozillen zuallererst die Vorliebe für
> US-Letter austreiben. Dann klappt es auch mit dem Drucken.
Das klingt höchst interessant finde ich.
Aber wie macht man das? Wo hat der Firefox das Papierformat gespeichert?
Und warum holt er sich die Papierformat-Einstellung nicht vom gewählten
Drucker?
Denn das tut er ja schon für die Vorschau: Die Druckvorschau zeigt bei mir
immer brav A4-Seiten an, deren Inhalt dann offensichtlich/möglicherweise
auf US-Letter-Format skaliert ist.
Warum skaliert er dann denn nicht auch auf das richtige A4-Format?
Ist das ein Fehler im Browser oder ein Fehler bei mir?
Danke...
Hartmut Figge
>Hartmut Figge schrieb:
>
>> Gib doch mal eine bestimmte an. Ein Screenshot vom Print Preview
>> derselben w�re auch nicht schlecht.
>
>Also ein Beispiel:
>http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&Item=330273536783&Category=114728
>
>Screenshot - Druckvorschau Firefox:
>http://img510.imageshack.us/img510/4331/s1md1.jpg
Mit dieser Seite habe ich auch Probleme. Ist aber zweifelhaft, ob man FF
oder SM daf�r verantwortlich machen kann, denn http://validator.w3.org/
liefert f�r diese Seite:
| Validation Output: 355 Errors
>Wieder meine Frage:
>Wie kommt es, dass der Browser die Seite korrekt anzeigen kann, aber nicht
>korrekt an den Drucker gibt?
Gute Frage. Vielleicht ist der Drucker-Teil nicht so tolerant gegen�ber
Fehlern. ;)
Ruediger Lahl
> for i in `ls *.JPG`;do convert -scale 800 -quality 70 $i t/$i; done
70% ist noch viel zu viel. Wenn Text und die abgebildeten Fotos selbst
unwichtig sind, so wie in diesem Fall, reicht 30% vollkommen aus.
--
bis denne
Hartmut Figge
>*hafi* schrieb:
Obige Zeile verwende ich f�r Photos meiner Canon, wenn ich sie in dadm
zeige. 30%, hm.
Lutz Illigen
>> Unf�higkeit der webdeseiner.
> Wie bitte?
> Da habe ich jetzt aber M�he, das zu glauben...
Ist aber so, es fehlt eine print CSS.
> Diese problematischen Webseiten werden doch im Browser korrekt
> angezeigt. Und der Job des Webdesigners ist es in erster Linie,
> die Webseite f�r die Anzeige am normalen Bildschirm zu
> optimieren.
Und f�r den Druck.
> Aber um es einfacher zu sagen: Wenn der Browser die Seite am
> Bildschirm korrekt anzeigt - warum gibt er sie dann nicht
> korrekt an den Drucker weiter?
s.o.
>>> Was kann man machen?
Ich habe mir schon Seiten lokal gespeichert und optimiert.
> Also hier noch mal ein Beispiel (hab ich oben schon mal
> gepostet):
[ebay link]
Wenn es denn ebay sein muss drucke ich im Querformat.
Lutz
Dominik Schmidt
> Mit dieser Seite habe ich auch Probleme.
Gut, aber das war ja nur 1 Beispiel.
Wie gesagt habe ich dieses Problem fast immer wenn ich etwas drucken will -
auch früher schon.
> Gute Frage. Vielleicht ist der Drucker-Teil nicht so tolerant gegenüber
> Fehlern. ;)
Genau diesen Gedanken hatte ich bisher auch.
Das war bislang mein einziger Erklärungsversuch, der sinnvoll zu sein
scheint.
Vielleicht auch noch interessant:
Ich habe es eben mit Opera probiert.
Der scheint einen fehlertoleranteren Druckerteil zu haben.
Die von mir genannte Beispielseite wird offenbar nicht abgeschnitten,
allerdings sehr fehlerhaft dargestellt - nur im Druckerteil (Druckvorschau
- Ausdruck)!
Siehe:
http://img49.imageshack.us/img49/7214/97878858wi8.jpg
(Wenn der Link nicht geht:
http://img49.imageshack.us/my.php?image=97878858wi8.jpg )
Im Opera habe ich auch über Print Options - Paper and Orientation unterhalb
der Druckerauswahl noch eine Papierformatauswahl. Dort kann ich unter
anderem A4 und Letter einstellen.
Wenn ich A4 einstelle, wird der Ausdruck normal zentriert, beim
Letter-Format geht's eben etwa 1 - 2 cm rechts raus.
Abgeschnitten wird aber trotzdem nichts.
Dominik Schmidt
> Ist aber so, es fehlt eine print CSS.
Print CSS? Ist das ein eigener CSS-Teil nur für Ausdrucke?
>> Diese problematischen Webseiten werden doch im Browser korrekt
>> angezeigt. Und der Job des Webdesigners ist es in erster Linie,
>> die Webseite für die Anzeige am normalen Bildschirm zu
>> optimieren.
>
> Und für den Druck.
Meiner Meinung nach nicht, denn...
>> Aber um es einfacher zu sagen: Wenn der Browser die Seite am
>> Bildschirm korrekt anzeigt - warum gibt er sie dann nicht
>> korrekt an den Drucker weiter?
>
> s.o.
Meinst du "print CSS"?
Dann wird es ja wieder auf den Webdesigner geschoben.
Ich sehe das so: Wenn ein Browser eine Webseite am Bildschirm korrekt
anzeigen kann, dann sollte er diese ebenfalls korrekt an den Drucker
weitergeben können. Ich verstehe nicht, warum der Browser beim Drucken die
Seite falsch interpretiert (bzw. allgemein Fehler macht), wenn bei der
normalen Anzeige alles funktioniert.
Ich sehe das Problem also beim Browser.
Ich höre aber gerne auch andere Meinungen...
>>>> Was kann man machen?
>
> Ich habe mir schon Seiten lokal gespeichert und optimiert.
Na ja, wenn du da Zeit und Nerv hast...
Das wäre mir VIEL zu umständlich wenn ich einfach eben mal schnell eine
Seite drucken will. Da drucke ich wenn's sein muss lieber ein (oder zwei)
Screenshot, als dass ich mich eine halbe Stunde hinsetze und da irgend was
zurecht biege...
> Wenn es denn ebay sein muss drucke ich im Querformat.
Workaround - habe ich auch schon gemacht.
Behebt aber das Problem nicht.
Ilja Sekler
> Ilja Sekler schrieb:
>
>> Nach meiner Erfahrung muss man Mozillen zuallererst die Vorliebe
>> für US-Letter austreiben. Dann klappt es auch mit dem Drucken.
>
> Das klingt höchst interessant finde ich. Aber wie macht man das?
Unter Linux: File => Page Setup... => Format für: [$DRUCKER]
Eigenschaften: [A4]
Voreingestellt ist "US Letter", die locale wird ignoriert. Unter Windows
könnte es ähnlich oder auch ganz anders sein. Ich kann
nicht mal sagen, ob dieser Bug unter Windows noch existiert, ein
scheinbar passender Bug
<https://bugzilla.mozilla.org/show_bug.cgi?id=123554> ist VERIFIED FIXED.
Hast Du schon mal ein neues Profil angelegt? Wenn jede
Firefox-Installation unter Windows betroffen wäre, hätte es eine Flut
von Fragen wie Deine geben müssen.
> Wo hat der Firefox das Papierformat gespeichert?
In prefs.js:
user_pref("print.printer_$DRUCKER.print_paper_name", "iso_a4");
user_pref("print.printer_$DRUCKER.print_paper_width", "210,00");
user_pref("print.printer_$DRUCKER.print_paper_height", "297,00");
$DRUCKER ist der Name des Standard-Druckers.
> Und warum holt er sich die Papierformat-Einstellung nicht vom
> gewählten Drucker?
Das ist ein Bug im Firefox für Linux.
> Warum skaliert er dann denn nicht auch auf das richtige A4-Format?
Weil er konfiguriert ist, auf Letter zu skalieren.
> Ist das ein Fehler im Browser oder ein Fehler bei mir?
Hättest Du Linux benutzt, würde mir die Antwort leicht fallen.
Gruß,
Ilja
Ilja Sekler
> Also ein Beispiel:
> http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&Item=330273536783&Category=114728
>
> Screenshot - Druckvorschau Firefox:
> http://img510.imageshack.us/img510/4331/s1md1.jpg
>
> Wie deutlich sieht, ist die Umrandung mit der Palme abgeschnitten und
> der Text darin auch.
Same here, aber nur in der Druckvorschau. Auf dem Ausdruck fehlt nichts.
Gruß,
Ilja
Dominik Schmidt
> Same here, aber nur in der Druckvorschau. Auf dem Ausdruck fehlt nichts.
Wie gesagt - bei mir sieht der Ausdruck genau so aus, wie die Druckvorschau
(Screenshot), also abgeschnitten.
Micha Kuehn
Dass bei dir hier nichts abgeschnitten wird, k�nnte daran liegen, dass
du Querformat eingestellt hast.
Wenn ich das tue, wird da auch nichts mehr abgeschnitten - allerdings
taucht dann der Seitenkopf alleine auf einer Seite auf, der eigentliche
Text beginnt dann erst auf S. 2 - ein Ph�nomen, dass ich schon �fter
beim SM hatte, auch bei eigenen Seiten. Dort konnte ich nichts am
Quelltext finden, was so ein Ph�nomen verursachen k�nnte, hier habe ich
keine Lust, den Quelltext anzusehen.
Micha
--
Pers�nliche Mails: Bitte nur als reply - und als Wurmkur werden alle
Mails > 100 KB automatisch und unbesehen gel�scht!
Ilja Sekler
> Hartmut Figge schrieb:
>
>> Sieht bei mir so aus:
>> http://www.triffids.de/pub/screenshot/sm080923.jpg (263 KB)
>
> Dass bei dir hier nichts abgeschnitten wird, könnte daran liegen,
> dass du Querformat eingestellt hast.
Auch im Hochformat wird nichts abgeschnitten. Die alte Gecko in Deinem
SM 1.1.10 kann's halt nicht besser.
> Wenn ich das tue, wird da auch nichts mehr abgeschnitten - allerdings
> taucht dann der Seitenkopf alleine auf einer Seite auf, der
> eigentliche Text beginnt dann erst auf S. 2 - ein Phänomen, dass ich
> schon öfter beim SM hatte, auch bei eigenen Seiten.
Auf dem Trunk sind etliche Page-Break-Bugs wie dieser gefixt. Wenn Dir
das Warten auf SM 2.0 zu lange wird, gib Firefox 3 eine Chance. Zwar
auch "nur" ein Branch (1.9.0.x), aber auf grausam verunstaltete
Ausdrucke wirst Du, zumal unter Windows, kaum treffen.
Unter Linux ist Gecko 1.9.0.x und das Drucken ein anderes, trauriges Thema.
Gruß,
Ilja
Lutz Illigen
> Lutz Illigen schrieb:
>> Ist aber so, es fehlt eine print CSS.
> Print CSS? Ist das ein eigener CSS-Teil nur für Ausdrucke?
Yepp.
>>> Diese problematischen Webseiten werden doch im Browser korrekt
>>> angezeigt. Und der Job des Webdesigners ist es in erster
>>> Linie, die Webseite für die Anzeige am normalen Bildschirm zu
>>> optimieren.
>> Und für den Druck.
> Meiner Meinung nach nicht, denn...
Ein Monitor ist kein Blatt Papier.
>>>>> Was kann man machen?
>> Ich habe mir schon Seiten lokal gespeichert und optimiert.
> Na ja, wenn du da Zeit und Nerv hast...
Ist in der Regel schnell gemacht wenn man sich etwas mit CSS
auskennt.
Lutz
Susanne Jäger
> Ich sehe das so: Wenn ein Browser eine Webseite am Bildschirm korrekt
> anzeigen kann, dann sollte er diese ebenfalls korrekt an den Drucker
> weitergeben können. Ich verstehe nicht, warum der Browser beim Drucken die
> Seite falsch interpretiert (bzw. allgemein Fehler macht), wenn bei der
> normalen Anzeige alles funktioniert.
> Ich sehe das Problem also beim Browser.
>
> Ich höre aber gerne auch andere Meinungen...
Ohne jetzt die Gecko-Print-Fähigkeiten allzusehr verteidigen zu wollen -
die fallen leider gerade was CSS angeht weiter hinter das zurück, was in
der Screendarstellung möglich ist - so einfach ist es dann doch nicht.
Wenn ich auf einer Webseite mehr oder größere Blöcke (Bilder, Texte ohne
Umbruchmöglichkeit, ...) nebeneinander packe als auf den Bildschirm
passen, gibt es einen horizontalen Scrollbalken, diesen Ausweg gibt es
bei Papier nicht ohne weiteres und wenn dann noch zusätzlich
unaufmerksame Autoren CSS-Anweisungen wie overflow: hidden; in
allgemeingültige Stylesheets packen, ist das Chaos eigentlich
vorprogrammiert.
Gruß
Susanne
Dominik Schmidt
> Wenn ich auf einer Webseite mehr oder größere Blöcke (Bilder, Texte ohne
> Umbruchmöglichkeit, ...) nebeneinander packe als auf den Bildschirm
> passen, gibt es einen horizontalen Scrollbalken, diesen Ausweg gibt es
> bei Papier nicht ohne weiteres und wenn dann noch zusätzlich
> unaufmerksame Autoren CSS-Anweisungen wie overflow: hidden; in
> allgemeingültige Stylesheets packen, ist das Chaos eigentlich
> vorprogrammiert.
Das ist mir grundsätzlich schon klar.
Aber dann sollte der Browser doch die Bildschirmausgabe soweit verkleinern,
bis sie auf ein Blatt Papier passt. Damit dürfte doch das Problem erledigt
sein...? Immerhin geht eine Webseite i.d.R. ja nicht besonders weit in die
Breite, sondern stattdessen in die Länge. Damit dürfte diese Verkleinerung
auch nicht so gravierend sein.
Und eine Funktion "Stretch To Fit", wie sie bspw. im Fuchs angezeigt wird,
klingt doch so ähnlich, oder nicht?
Wolfgang Hauser
>> Mit dieser Seite habe ich auch Probleme.
>
>Gut, aber das war ja nur 1 Beispiel.
>Wie gesagt habe ich dieses Problem fast immer wenn ich etwas drucken will -
>auch früher schon.
Im Fall von eBay gibt es eine einfache Abhilfe: klicke mal bei
Artikelbeschreibungen ganz unten auf "Druckansicht". Die Bahn bspw.
hat so einen Modus auch bei ihren Fahrplanauszügen.