Erstellen von Seitenumbrüchen für Chrome, Explorer und Word in HTML

8

Ich kann keine einheitliche Methode finden, um einen Seitenumbruch zu erstellen, der zwischen Word, Internet Explorer und Chrome funktioniert.

Im folgenden Beispiel (aus Seitenumbrüche für Google Chrome-Druckseiten ) werden Seitenumbrüche erstellt richtig für Chrome und Internet Explorer, aber hat keine Seitenumbrüche in Wort.

%Vor%

Nachdem ich mit dem Wort herumgespielt habe, das ich entdeckt habe, können Sie mit folgendem Text einen Seitenumbruch hinzufügen:

%Vor%

Das Problem hier ist, dass Internet Explorer auch dies als Seitenumbruch sieht. Wenn Sie also die Methoden kombinieren, haben Chrome und Word Seitenumbrüche korrekt, aber Internet Explorer fügt zwei Seitenumbrüche ein. Wenn Sie nur einen verwenden, dann ist entweder Chrom und Explorer richtig und das Wort nicht und so weiter.

    
Matthew Sanford 04.05.2012, 21:03
quelle

5 Antworten

4

Versuchen Sie Folgendes:

%Vor%

Passt das zu Ihren Bedürfnissen? (Beachten Sie, dass diese in reinem alten HTML arbeiten. Ich habe in Chrome und MS Word (zusammen mit IE) getestet und sie funktionierten gut.)

    
Vreality 04.05.2012, 21:30
quelle
1

Dies ist ein Unterschied zwischen IE8 und IE9 (vorausgesetzt IE9 ist im Standardmodus), Sie müssen also irgendwie zwischen diesen Browsern unterscheiden - entweder mit einem bedingten Kommentar oder einem CSS-Hack wie diesem:

%Vor%

(Getestet in Chrome, Firefox, OpenOffice Writer [hoffentlich ein passender Ersatz für Word] und IE 7,8,9)

Zum Schutz gegen Browser, die beide Seitenumbrüche auf br anwenden und verstehen: nicht, könnten Sie dies hinzufügen, obwohl ich keinen Browser kenne, der es benötigt:

%Vor%     
Brilliand 11.05.2012 00:11
quelle
0

Setzen Sie das relevante CSS in! IE bedingte Kommentare. Alles andere kann so bleiben wie es ist.

%Vor%

Explorer behandelt alles zwischen <!--[if !IE]> und <![endif]--> Tags als Kommentare und Word reagiert nicht darauf. Alle anderen Browser werden weiterhin wie zuvor angezeigt.

    
ColBeseder 09.05.2012 09:02
quelle
0

Ich weiß, dass solche Beiträge mich kosten können, aber, ernsthaft, mach einen Schritt zurück und denke darüber nach, was du zu erreichen versuchst.

Ein Nutzer, der Ihren Bericht mithilfe von Word ansehen und drucken kann, verfügt ebenfalls über den IE und hat höchstwahrscheinlich einfachen Zugriff auf Chrome. Meine Vermutung ist, dass Word nicht nur zum Anzeigen und Drucken, sondern vor allem zum Bearbeiten dient.

Ich folgte Ihrem Beispiel und mein (in jedem Aspekt unmodifizierter) IE9 druckt keine Seitenumbrüche, die mit Word 2010 eingefügt wurden, und das resultierende HTML-Dokument hat kaum Ähnlichkeit mit dem ursprünglichen, besonders die DIVs sind weg, also das Dokument vorausgesetzt druckt immer noch das selbe, nachdem Wort zu Wort gekommen ist, ist fast unvorsichtig optimistisch.

Diese ganze Idee scheint gebrochen:

  • das Schreiben von HTML scheint dir sinnlos, wenn man bedenkt, was Word damit macht
  • selbst ein neuer IE kann nicht mit Ihrem einfachen Beispiel umgehen, bei dem Seitenumbrüche mit Word
  • eingefügt wurden
  • Beim Speichern von Word wurde ein spezifisches Verzeichnis für die Spracheinstellung und drei neue Dateien erstellt, die für jedes Produkt eine lächerlich große Menge an notwendigen Tests erzeugen
  • Eine Menge Benutzerwissen (das Erstellen von Verzeichnissen, das korrekte Speichern und das korrekte Kopieren des gesamten Dokuments) scheint erforderlich zu sein, damit dies auch innerhalb eines statischen Microsoft-Ökosystems funktioniert
  • es scheint, dass benutzerdefinierte Einstellungen leicht jede Lösung mit HTML
  • brechen können

Ich würde vorschlagen, Ihren Bericht zunächst als Word-Dokument zu schreiben. Obwohl gezippt, sind Word-Dokumente immer noch Markup wie HTML. Wenn Sie also bereits HTML generieren können, können Sie Word mit wenig zusätzlichem Aufwand generieren. Da Sie Word-Viewer für praktisch jedes x86- oder ARM-basierte Gerät erhalten können, scheint dies eine vernünftige Richtung zu sein, als in einer Richtung zu suchen, in der selbst die einfachen Beispiele fehlschlagen.

    
user1129682 15.05.2012 10:38
quelle
0

Eine weitere Ergänzung, die für einige Leute, die diese Art von Problem behandeln, hilfreich sein könnte: Die Änderung gilt nur für das Blockelement. In unserem alten Test hat jemand einen Block mit 'span' codiert. Ich habe mehrere Tests durchgeführt und konnte die Lösung von Vreality nicht zum Laufen bringen. Dann dachte ich, dass es vielleicht daran liegt, dass span kein Blockelement ist, also füge 'display: block' zu Element hinzu, das standardmäßig kein Blockelement ist.

Eine andere Sache: Ich benutze die neueste Chrome (v.25), die "Seitenumbruch-innen: vermeiden;" Fix scheint nicht mehr benötigt.

    
obvdso 05.03.2013 20:30
quelle

Tags und Links