Werte MacTechNews-Leser,

die Zeit, als Apple eine Menge Energie darauf verwendete, Safari zum führenden Browser zu machen (ACID 3), ist schon etwas her. Der in OS X eingebaute PDF-Generator (Mac OS X Quartz PDFContext) ist eine feine Sache. Schön wäre allerdings, wenn er auch etwas präziser arbeiten würde. Die Beispieldatei https://macshot.de/linien.html enthält Linienstärken ab 0,2mm bzw. 0,98Px. Angezeigt wird erst ab einer Linienstärke von 1px mit einer kleinen Ungenauigkeit (0,99).

Das Ausweichen auf den anderen PDF-Generator PDF Pronto bringt nichts. Obwohl auch in OS X 10.11 der Quartz PDFContex eine PDF-Datei in Version 1.3 erzeugt, gibt es aber eine Abweichung: wenn denn eine Linie sichtbar ist, dann werden auch feine Unterschiede in der Linienstärke gemacht, wo bisher Linienstärken nur in ganzzahligen Vielfachen von Px ausfielen.

Die drei Beispiele:
PDF Pronto
Mac OS X 10.7.5
OS X 10.11 PB5

Kennt jemand noch weitere PDF-Generatoren unter (Mac) OS X?
PDF-Generatoren im Internet auf Servern mal nicht gemeint, weil ich da kein gutes Gefühl hätte, auch wenn PDF Pronto so zu funktionieren scheint (Generator: Qt 4.8.6). Die Neugierde war letztendlich größer als die Befürchtungen. Und wenn einer es ausprobiert für andere, dann ist das Risiko für die anderen kleiner

MacRudi

Also mich wundert da gar nix. Bei meinem 30" von Dell sehe ich zB die Linie bei ,99px im unteren Bild nicht.
Und wen ich mir ein PDF im Illustrator anschaue (1x Save as AdobePDF und einmal über OSD erstellt dann wird so manches klar. Im PDF sind gar keine Linien sondern alle Linien werden als Rechteck erstellt. Da liegt wohl eines der Probleme. Die Umsetzung von HTML in PDF.
Ich denke man sollte daher mal einen Test mal mit verschiedenen Browsern machen.

Dürfte daran liegen, dass Du ein relativ neues OS X verwendest.Das erklärt, warum die feinste Linie nicht 1px, sondern immer gleich 2px ist! Das scheint also noch ziemlich schnell gestrickt zu sein. Wenn man also mal ganz normal dran gehen würde, könnte das deutlich besser werden. Mal sehen, wann das geschieht

Danke für die Info!

Einen anderen Browser hatte ich schon mal probiert, der einen eigenen PDF-Generator hatte (Opera?). Das war anders, aber auch nicht besser. Kann ja mal wieder mit neueren Browser-Versionen unter 10.11 testen

Ja, ich habs mit 10.10.5 und dem da aktuellen Safari getestet. Ich denke nicht das sich da so schnell was dran ändert.
Vielleicht solltest du aber die zugrundeliegende HTML-Datei mal überarbeiten. Erstelle dort zum Vergleich mal nur Linien, keine Rechtecke. Und zwar jeweils eine waagerechte, horizontale, einem mit 45° und je eine mit 20° und eine mit 80°. Ma sehen, ob da dann echte Linien im PDF raus kommen.

Die augenblicklichen Rechtecke sind Umrandungen (border) von divs. Ich möchte feine komplette Umrandungen und feine Linien haben. Linien allein gibt es nicht wirklich. Es gibt zwar ein Objekt <hr> (horizontale Linie), diese ist aber - das sieht man schon in HTML - auch wahrscheinlich ein Rechteck. Dürfte historisch bedingt sein (border mit 3D-Effekt).

+1

Zumal mein Firefox 41b4 da durchaus Linien im Browser anzeigt und auch im erzeugten PDF, wo der allerneueste Safari 8.08 unter OSX 10.10.5 bei mir nichts anzeigt.

Wieso ist das Ausgangsdokument zum Beispiel HTML 4.01 transitional vom Doctype her und nicht strict?

Abgesehen davon, dass weder das HTML des Ausgangsdokuments noch das CSS jeweils valide sind (die Fehler im HTML in Zeile 104 sind zwar nicht ergebnisverändernd, aber trotzdem. Und die beiden Fehler im CSS in Zeile 28 und 57, die SIND auschlaggebend, da fehlt nämlich jeweils die Einheit, kein Wunder, dass da dann im Zweifel keine Linie gezeichnet wird).

Erstmal ein sauberes, valides Ausgangsdokument herstellen, das in sich ohne Fehl und Tadel ist. Dann kann man weitersehen. Zumindest jetzt ist für mich jedenfalls schon ersichtlich: Firefox rendert da offenbar besser als Safari, zeigt da so manche Linie an, die Safari nicht anzeigt. Im resultierenden PDF genauso. Firefox erzeugt da das PDF bei mir, wie Safari auch, via Mac OS X 10.10.5 Quartz PDFContext. Aber offenbar, sowohl im Browser als auch im resultierenden PDF, mit einem besseren Ergebnis. Obwohl denselben systemeigenen Renderer benutzend. Also liegt's wohl sehr am Input, der vom Browser aus in diesen Renderer hineingeht. Bzw. an der Kombination Ursprungsdokument + Browser, der's an den von beiden genutzen gleichen Renderer weiterreicht. Auf mich wirkt das grad' so, als würde Firefox da seinen Job besser machen als Safari.

Mal abgesehen vom Ausgangsdokument und dort bereit eingebauten Fehlern und implizierten Unkorrektheiten (die erstmal beseitigt werden sollten). Valide, und vor allem bitte Strict und nicht Transitional! Damit der Browser bzw. dessen Rendering-Engine angehalten wird, nicht zu raten und ungenau zu rendern. Sondern peinlichst genau das umzusetzen, was ihm da vorgegeben wird. Genau das ist mit Transitional ausgeschaltet, ganz bewusst ausgeschaltet, der Browser rendert da ganz bewusst und gewollt "wie ihm der Schnabel gewachsen ist" und eben NICHT genau! Zumal genau dieser Doctype ganze bewusst "Transitional" heißt, also "Für den Übergang bestimmt", also nur für den Notfall und vor allem für ALTE Dokumente vorbehalten ist und bleiben sollte. HTML 4.01 hat diesen Doctype aus gutem Grund, und er sollte auch möglichst ausschließlich genutzt werden, es gibt eigentlich keinen nachvollziehbaren Grund, im Jahre 2015 erste recht nicht mehr, noch irgendwie, irgendwo bewusst den Transitional Doctype (der den Browser zu Ungenauigkeiten geradezu einlädt, ja ihn dazu zwingt, nicht so genau zu sein) zu verwenden. XHTML 1.1 und auch HTML5/XHTML5 kennen deshalb nur einen Doctype, da gibt es diese Unterscheidung nicht mehr, und dieser einzige Doctype heißt: Strict. Damit der Browser nicht rät und seine Fehlerkorrektur nicht eingreifen muss (was ihn auch immer ein bisschen langsamer macht beim Rendern, wenn das geschieht). Damit genau gerendert wird und vorhersagbare Ergebnisse erzielt werden können und für den Vergleich eine solide Basis gegeben ist. Die ist nicht gegeben, wenn der Browser im Ungefähr-Modus rendert und da auch noch jeder Browser-Hersteller sein eigenes Süppchen kocht, was "ungefähr" denn zu bedeuten hat.

Erstmal eine verlässliche Ausgangsbasis schaffen also und eigene Fehler und Unkorrektheiten ausmerzen und den Browsern etwas an die Hand geben, das verlässliche Ergebnisse produziert. Dann erst kann man vergleichen und wirklich was dazu sagen. Vorher ist das nur Stochern im Nebel bzw. geht aus wie das Hornberger Schießen.

ann wirst du wohl auf "HTML 2.0" oder so warten müssen. Ist nicht mein Gebiet aber wenn es da von Haus aus keine Linien gibt dann wirst du um Grafiken nicht drum herum kommen. HTML scheint nicht wirklich zum Zeichnen gemacht worden sein. Daher auch diese "Übersetzungsprobleme" zu PDF.

Yes We Can Do Fraction Of A Pixel

W3C: em, px, pt, cm, in…

Zudem: warum sind in den CSS media queries für das Ausgabemedium screen Millimeter-Angaben drin und in den CSS media queries für das Ausgabemedium print Pixel-Angaben? Also in dem jeweiligen Ausgabemedium Größeneinheiten, die da im Grunde völlig fehl am Platze sind und für das betreffende Zielmedium ungeeignet, weil die Ergebnisse, die damit erzielt werden, mindestens auflösungs- und geräteabhängig sind und je nach Gerät und Auflösung zu unterschiedlichen Ergebnissen führen (und auch sollen).

Ich frage mich bei dem Ganzen zudem, was Ziel der Übung sein soll. Was soll eigentlich herausgefunden oder gezeigt werden, was soll erreicht werden? Was ist Ziel und Zweck? Oder wobei braucht der Fragesteller ggf. Hilfe?
Bisher wirkt das auf mich eher so: "Guck' mal, (mir war ein wenig langweilig) das hier habe ich gemacht." – Ja, und nun? Und weiter? Was ist damit, wo soll die Reise hingehen?

Zunächst mal zitierst Du, machst ein +1, dabei hat er es ganz anders gemeint als Du. Wenn Du also so pingelig bist, das alt-Attribut zu bemängeln, was in meinen Augen völlig zu unrecht postuliert wird, dann benutze Zitate nicht missbräuchlich.

Den von Dir angesprochenen Fehler mit fehlender Einheit im CSS kannst Du nicht besser wissen, weil er erst beim Testen ganz bewusst von mir so gewählt wurde. Die Anzahl der Stellen im CSS ist nämlich begrenzt und ich musste die Einheit weglassen, damit die Nachkommastellen auch überhaupt beim Browser berücksichtigt wurden.

Auf die vielen Sätze mit Transitional und Strict gehe ich nicht ein, weil sie zu unkonkret sind. Eine Wiederholung macht aus einem Argument keine weiteren. Wenn Du mit Strict und Transitional mal rumgespielt hättest, wüsstest Du, wie viel Auswirkung das hat. Ich hatte es nämlich bei diesem Beispiel und anderen schon durchgespielt.

Haut euch nicht
@Sierkb: da du die "angeblichen" Fehler bereits alle erkannt hast, magst du nicht deine Fassung der Datei zum Vergleich irgendwo hochladen? Dann mach ich zum Vergleich mit Firefox mal PDFs und schau die mal im Illustrator an.

Wenn er schreibt, dass Du die HTML-Datei überarbeiten solltest, schließe ich mich dieser Aussage an, und ich hab's auch begründet, warum.

Du selber solltest Dir selber im Sinne dessen, was Du vorhast, pingelig sein. Was Du abschätzig als pingelig bezeichnest, nennt man schlicht und einfach sauberes Arbeiten. Im Sinne sauberer Ergebnisse. Und genau das strebst Du ja an.

Dann bist Du im Unrecht mit Deiner Auffassung, und der Validator ist da im Recht. Er bemängelt das zurecht als Fehler an und nicht als Warnung, und dafür gibt es auch gut durchdachte Gründe. Wir haben uns jahrelang gestritten im Validator-Team, ob derlei als Fehler oder lieber lediglich als Warnung gelten soll. Verblieben ist man, dass es weiterhin als Fehler angekreidet wird, es gibt dafür Gründe.
Ich habe zudem obig ja geschrieben, dass es das Ergebnis in Deinem Fall nicht beeinträchtigt. Trotzdem sei darauf hingewiesen. Ein Fehler ist ein Feher, auch wenn Du selber das tausendmal zugunsten Deiner eigenen Nachlässigkeit anders sehen magst.

Siehe zuvor Gesagtes. Ich habe hier gar nichts missbräuchlich genutzt.

Und woher soll der Browser wissen, wie er das rendern soll, wenn er die Einheit nicht weiß? Soll er das in Kartoffel-Längen rendern? Oder in Ellen? Oder in Fuß oder Pi mal Daumen? Oder wie oder was?

Nein, sie sind sogar SEHR konkret. Du scheinst nicht zu wissen, was Du tust, das scheint mir hier durch. Ob Du Transitional oder Strict benutzt hat GANZ KONKRETE Auswirkungen auf das Rendering, auf das Ergebnis, auf die Darstellung. Nur deshalb habe ich es angemerkt. Die Browser rendern dann ANDERS, berechnen das Dokument ANDERS. Und nicht unbedingt so wie Du es gerne möchtest und beabsichtigst. Wenn Du also vorhersagbare Ergebnisse haben möchtest, die dazu auch noch in verschiedenen Browsern und Ausgabemedien miteinander verglichen werden sollen, dann solltest Du tunlichst die Finger vom Transitional-Modus lassen, sondern Strict erzwingen.

Und wenn es für Dich nach Deinem Augenschein (der täuschen kann) keinen Unterschied gemacht hat, was spricht dann dagegen, dann ERST RECHT Strict zu verwenden statt Transitional? Eben einfach deswegen, um auf der SICHEREN Seite zu sein und möglichst keine Unsicherheiten auch noch künstlich hineinzubringen?
Es gibt keinen nachvollziehbaren Grund, hier Transitional zu verwenden, und eine echte Begründung sehe ich von Dir auch nicht, das machen zu MÜSSEN, denn Du verwendest kein HTML-Element, das deprecated (also missbilligt) ist, also somit auch kein Transitional-Modus notwendig, der diese missbilligten Elemente enthält. Und dafür dann eben der Modus, der den Browser bzw. das endgerät dazu anhält, GENAU zu berechnen und darzustellen, das erreichst Du eben nur im Strict-Modus.

Nicht ich. Er hier, W3Cs Unicorn:

Hatte ich erst vor, doch wozu? Kann das unser MacRudi nicht selber auch? Er ist doch selber vom Fach nach eigener Auskunft.

Siehe grad' Gesagtes. Hatte ich ursprüngl. sogar vor, habe mich dann aber dagegen entschieden. MacRudi hat sicher selber Firefox installiert (sollte er, wenigstens zum Testen, als Mann vom Fach).

Weil ich zudem auch nicht so wirklich den Sinn erkennen kann, der hinter dem Ganzen stecken soll, wozu er das alles macht bzw. wozu wir uns hier damit weiter beschäftigen sollen, was Ziel des Ganzen sein soll. Was soll herausgefunden oder bestätigt/nicht bestätigt werden? Dass Safari offenbar ein paar Dinge nicht oder nicht korrekt rendert? Browser der Konkurrenz hingegen durchaus?
Bin im Moment zudem noch mit etwas Anderem beschäftigt.

Aus HTML-Dateien eine PDF zu machen und da genaue Ergebnisse zu erwarten ist reine Illusion und nicht Sinn und Zweck der PDF-Druck Funktion. Wenn die Quelle genau genug ist (z.B. Cad-Programm) sieht alles klasse aus (OSX 10.3 - 10.10).

Ich habe mich im PHP-Bereich etwas intensiver damit auseinandergesetzt und selbst mit allen möglichen "Tools" die das angeblich möglich machen sollen klappt es nicht wirklich.

Deshalb erstelle ich die PDF-Dateien direkt mit TCPDF wenn ich sie im Browser ausgeben will. Da kann ich es eben ganz genau definieren.

Ansonsten brauche ich eben ein "vernünftiges" Programm wie z.B. Illustrator oder AffinityDesigner.

Fazit: HTML und PDF passen nicht wirklich zueinander und machen keinen Sinn wenn man exakte Ergebnisse "braucht".

buck:

Ich bin geneigt, Dir zuzustimmen. Zudem gibt es extra für solche Zwecke im Bereich der Webstandards solche Sprachen wie XSLT und XSL-FO. Die sind genau dafür da, um aus einem Quell-Dokument in dem einen Format, ein anderes Dokument in einem anderen Format zu erzeugen, es dahin zu transferieren. Grad' auch, was PDF als Zielformat angeht, das aus einer XML-Datei oder HTML-Datei erzeugt werden soll. Zumal jeder moderne Browser inzwischen einen XSLT-Transformator eingebaut hat, der es ermöglichst, unter Einbeziehung eines entsprechenden XSLT Stylesheets, on-the-fly ein anderes, gewünschtes Ausgabeformat zu bringen. Lokal. Serverseitig geht's sowieso, prima per PHP oder Java bzw. JSF. Und lokal gibt es im Unix-System von Haus aus auch XML- und XSLT-Prozessoren, womit man das ggf. per CLI machen und auf diese Weise PDF erzeugen könnte: Quelldokument rein (XML oder HTML), Zieldokument im PDF-Format raus.

Aber erstmal sollte man überhaupt erstmal HTML und CSS richtig anwenden können, um zu sehen, was damit geht oder nicht geht. Damit geht nämlich durchaus sehr viel. Wenn man es richtig und korrekt macht.

HTML und CSS funktionieren mittlerweile ja glücklicherweise ziemlich gut - aber eben nur "ziemlich gut". Wenn ich die "Umwandlung" in PDF dem User überlasse weiß man nicht zwangsläufig so genau was dabei rauskommt weil da ja u.U. persönliche Einstellungen im Browser noch reinspielen.
Die "Umwandlung" sollte dann auf jeden Fall unter kontrollierten Bedingungen stattfinden (also z.B. auf dem Server) und die Ausgabe im Zielformat (also PDF) erfolgen. Dann kann ich auch dafür sorgen, dass alles passt.

Kommt immer drauf an, was für Ergebnisse man beabsichtigt. In sehr vielen Fällen ist es gut genug oder gar perfekt, um ein bestimmtes Ergebnis zu erreichen, in anderen Fällen wiederum nicht so sehr.

+1

Zudem: Browser-Add-Ons, Erweiterungen, Filter haben da durchaus auch noch Einfluss auf das Render-Ergebnis, auf die Darstellung, auf das, was am Ende beim Benutzer ankommt. Eigentlich müsste man die alle total ausschalten, die Broeser in ihrer Werkseinstellung haben, browserübergreifend eine solide gleichwertige Basis schaffen, wenn es um Referenz-Ergebnisse gehen soll, die möglichst genau sein sollen und die man in den verschiedenen Browsern miteinander vergleichen will.

Obig wurde der ACID-Test erwähnt. Der setzt solche sauberen "Reinraum"-Bedingungen bzw. einen Plain-Vanilla Browser in seinem Urzustand ohne Erweiterungen oder vom Auslieferungszustand abweichenden Konfigurationen grundsätzlich voraus, wenn man ihn ernsthaft anwenden und z.B. Bugs offenbaren will, sonst kann es nämlich sein, dass er nicht richtig funktioniert bzw. unkalkulierbare Ergebnisse hervorbringt.

+1

Genauso. Mein Reden.

Du machst alles richtig, was andere sagen ist falsch und andere sind Stümper.

Ich habe meine Pyjama-Hose nicht gebügelt, darf ich trotzdem hier Posten?

Während MikeMuc eine Anregung geben wollte mit dem HTML-Code überdenken, willst Du hier den Validator befriedigen. Na klar möchte ich einen Code als Ausgangsbasis nehmen, der auch dafür taugt. Aber das geht nicht so weit, dass ich irrelevante alt-Attribute verwende. Schließlich sollt ihr das auch lesen und alles was Müll ist, lasse ich raus. Das nennt man eine Reduktion, dürfte Dir sicherlich nicht unbekannt sein. Das alt-Attribut wäre genau dann enthalten, wenn es relevant wäre, isses aber nicht.

Browser-Plug ins und -Extensions könnten reinspielen, aber auch das ist zu weit ausgeholt. Also wenn Du was forderst, dann mit Augenmaß und nicht kategorisch. Oder fehlt Dir eine Einschätzung, ob etwas relevant ist? Gut, dann muss man den 100%igen Code nehmen. Ich entbinde Dich dann von einer Teilnahme an dieser Diskussion.

Grundsätzlich bin ich erstaunt darüber, dass in CSS Linienstärken unter 1px ausdrücklich erlaubt sind, sie in Browsern aber erst dann sichtbar sind, wenn die dadurch errechnete anzuzeigende Linienstärke mindestens 1px erreicht. Die Browser machen es sich da leicht. Oder anders ausgedrückt: man hat offensichtlich andere Sachen, an denen man gerade in Browsern arbeitet, also andere Prioritäten. Das zur Darstellung in Browsern.

Der nächste Schritt ist die Abspeicherung in PDFs. Auch da wird nur übernommen, was im Browser angezeigt wird, obwohl PDFs sicherlich in der Lage sind, Linien mit einer Linienstärke feiner als 1(HTML-/CSS-)px zu enthalten. Das ist das, was mich nervt. Und ich suche danach, ob es PDF-Generatoren gibt, die von HTML mehr übernehmen ins PDF-Format.

PDF Pronto interpretiert HTML selbst (bekommt also nicht von Safari oder Firefox oder Opera … gesagt, was zu drucken ist) und wäre theoretisch dazu in der Lage, mehr zu übernehmen. Aber auch da hat man sich auf das beschränkt, was ein Browser anzeigt, welche Rendering engine weiß ich nicht. Hat als PDF-Generator dann wkhtmltopdf 0.12.2.1-rc-f77d32f genommen.

Zu sagen, HTML und PDF passen grundsätzlich nicht zusammen, mag eine Sichtweise sein, wenn man aus einem anderen Umfeld kommt. Mein Umfeld ist aber HTML und ich suche nach einer besseren PDF-Generierung.

Vervollständigung:

Ich behaupte einfach mal das PDF Pixel als Einheit nicht kennt. Es kommt ja von PostScript und da gilt eher der Punkt als Einheit. Wobei es bei Punkt auch mind. 2 unterschiedliche Definitionen gibt. Sierkb kann das sicher genau belegen.
Das Linien unter 1px nicht zur Ausgabe führen ist somit für mich nachvollzs iehbar. Es wird das konvertiert was bei der Ausgabe auf den Screen bei 100% sichtbar ist, nicht was theoretisch in einem anderen Ausgabeformat max möglich ist. Hier gilt also das System "kleinster gemeinsamer Nenner".

Und wenn Sierkb auf "strict" besteht weil nur dann den Browser ein exaktes vorbestimmbares Rendering vorgeschrieben wird so ist das für mich auch nachvollziehbar.
Nur weil bei dir im konkreten Fall mit transitional das Ergebnis deiner Zielsetzung näher gekommen ist heißt das ja nicht daß es "richtig" ist.
Ich denke da, das Sierkb Recht hat.

Wenn du also auf Genauigkeit und gleicher Ausgabe an allen Stellen Wert legst mußt du auch überall für gleiche Ausgangsbedingungen sorgen. Und im Fall von Zeichnungsgenauigkeit darüber nachdenken ob diese Stellen nicht mit anderen Mitteln erzielt werden kann / muß. Dazu hat es hier ja auch schon einige Hinweise gegeben.
Ob und wie du das nun umsetzt kommt auf den konkreten Einsatzzweck an und ob sich der Aufwand dazu lohnt.
Bisher sieht es ja nur nach einem Versuch deinerseits aus bei den du festgestellt hast das unterschiedliche Ergebnisse erzielt werden. Was unter anderen anscheinend an "transitional" liegt was den Browser zum Würfeln von Ergebnissen anregt

Die CSS-Norm definiert 1px nicht als Gerätepixel, sondern als Längeneinheit. (Ausnahmen sind nur für Wiedergabemedien mit sehr geringer Auflösung erlaubt. Hier darf ausnahmsweise 1px = 1 Pixel gelten.)

1px hat eine Länge von 0,264583 mm. Die HTML/CSS-Normen schreiben ausdrücklich nicht vor, wie ein Dokument auf einem rasterorientierten Medium wie einem Bildschirm wiederzugeben ist, wenn bei der Umrechnung der CSS-Längenangaben in Gerätekoordinaten Objekte auf nicht-ganzzahlige Pixelkoordinaten fallen, bzw. Objekte kleiner als ein Pixel sind. Das bleibt der Rendering-Komponente überlassen.

Safari stellt auf einem Retina-Bildschirm Linienstärken kleiner als 1px dar (weil dies dort technisch machbar ist) und auf einem Standardbildschirm nicht, so wie es laut Norm zulässig ist.

Interessant
Wo kommt der Wert her? Oder hat man einfach den Wert genommen der beim "Erfinder" von CSS auf dessen System gerade vorhanden war.
Entfernt kommt mir das so vor wie Linienstärke 0, Haarlinie und kleinste darstellbare Lininienstärke bei PostScript Rips. Da weis man auch nich was der Dienstleister bei sich eingestellt hat. Manchmal weis es nicht mal der und man sieht erst später was passiert. Da hat es dann auch mal Unterschiede zwischen Blaupausen und Druck gegeben

Was sierkb schrieb ist warme Luft. Im konkreten Fall keine Ahnung und mit einer allgemeinen Sichtweise auf das Problem eingehen. Das ist für mich das Kennzeichen eines Besserwissers, wenn es denn auch noch mit dem Anspruch gepaart ist, "Ich habe Recht". Die allgemeine Sichtweise ist als Anregung ja nicht verkehrt, aber mehr gibt sie auch nicht her. Transitional oder Strict macht an dieser Stelle null Unterschied. Ich habe die HTML-Datei modifiziert, und zwar gleich zu HTML5

Die Definition von 1px hat wohl in alten Fassungen der CSS-Norm immer wieder zu Praxisproblemen geführt. Man hat sich dann zur pragmatischen Lösung nach dem Motto "wie groß ist ein Pixel bei der Mehrheit aller Web-Nutzer" entschlossen. Das war zu der damaligen Zeit der typische Windows-Benutzer, wo standardmäßig eine physische Auflösung von 96 ppi angenommen wird. 1px ist somit als "ein Sechsundneuzigstel Zoll" oder als 0,75 pt definiert.

Grundsätzlich hat MacRudi schon Recht: Beim Ausgabemedium Druck müsste die Rendering-Komponente eine höhere physische Auflösung annehmen und das Dokument entsprechend neu aufbereiten. Es wird aber offenbar (soweit die jeweilige CSS-Angabe für "@media print" das zulässt) nur eine Art "Bildschirmkopie" erzeugt. Möglicherweise passt man sich da auch dem Massengeschmack an. Die Mehrheit der Nutzer wird sagen, "ich will das so gedruckt haben, wie es auf meinem Monitor aussieht".

Aha, Windows
Und ja, üblicherweise will man das was auf dem Bildschirm ist gesichert haben. Alles andere macht normalerweise ja auch keinen Sinn außer man macht ein "Onlinezeichenprogramm". Da darf es dan geben beim Ausdruck besser sein.

MacRudi: Mr ist egal wer da Recht hat oder nicht. Und was richtig oder nicht ist, ebenfalls.
Aber beide HTML-Seiten von dir zeigen bei mir in Firefox bei allen Texten einen farbigen Rahmen, bei Safari bei allem unter 0,3 keinen Rahmen (siehe Screenshot)

Womit sich eventuell die Irrelevanz der von Sierkb bemängelten Fehler auf meinem System auf unterschiedliche Renderings von Safari und Firefox reduziert. Aber in die Richtung diskutiere ich nicht weiter da es nicht mein Metier ist.

Noch ein paar Auffälligkeiten ohne weitere Wertung:
- auf beiden Monitoren HP Z30i 30" 2560x1600 (Pixelgröße 0,25mm) und dem internen vom MacbookPro 15" mit 1680*1050 (Pixelgröße ~0,196mm) ist das Ergebnis das selbe. Firefox zeigt immer alle Linien. Es kommt also auf den Browser an.
- Der PDF-Export übers System und "Safe as Adobe PDF" (hab hier Acrobat X installiert) ergeben unterschiedliche PDFs. Beide erzeigen Linien! Das passiert bei Safari nicht) Aber beim Systemexport kann ich die Linien nicht auswählen im Illustrator, im AdobePDF schon. Dann haben alle Linien ≤ 2px und ≤ 0,8mm eine Linienstärke von 0,35.

Daraus mag nun jeder seine eigenen Schlüsse ziehen, ich bin raus hier. Denn alles weitere ist akademisch und da kann ich mangels Wissen nicht mithalten

Eigentlich nicht mal das, es müsste nur das HTML in PDF umgesetzt werden, ungeachtet, auf welchen Drucker oder anderes Ausgabemedium das PDF mal stoßen wird. Ich gehe geistig gerade davon aus, dass ein HTML-Objekt in ein PDF-Objekt umgewandelt wird. Vielleicht ist die Realität eine andere, dass das gerenderte Bild, also eine Bitmap ans PDF übergeben wird. Damit wäre klar, dass es nur eine Art Bildschirmfoto sein kann und nicht höher aufgelöst.
Ich hatte für Bildschirm und Druck die CSS-Definitionen gemacht, um fürs PDF-Erzeugen ausdrücklich gesagt zu haben, was ich möchte. Hat aber leider auch nichts gebracht

Was Du beobachtet hast, ist doch schon mal sehr gut. Nicht nur vorhandenes Wissen berechtigt zum Mitreden, sondern auch Mitdenken oder Beobachten

Nein! Du hast aber ein ganz dickes Problem damit, Widerspruch auszuhalten und auszuhalten, wenn Dir jemand anderes sagt, dass Du mit Deiner Sichtweise nicht ganz richtig liegst. Hast Du selber mal eingestanden. Darin scheint mir das eigentliche Problem zwischen Dir und speziell mir zu liegen bzw. darin zu akzeptieren, dass Du evtl. vielleicht umdenken solltest/musst, um zur Lösung zu kommen.

So kann man natürlich auch mit jemandem umgehen, desse Meinung einem nicht passt und der einem widerspricht. Indem man ihm einfach sagt: "Deine Visage passt mir nicht – halt's Maul."
Und ich weiß, dass Dir meine Visage nicht passt, Du hast es mir öffentlich wie privat oft genug zu verstehen gegeben. Ich könnte deshalb auch sagen: "Sieh' selber zu, wie Du mit Deinem Problem klarkommst, für Dich reiße ich mir jetzt kein Bein aus." Tue ich aber nicht.

Warum erstaunt Dich das? Es ist völlig logisch und nachvollziehbar. Die Rendering-Engine rechnet damit, benutzt auch krumme und Fließkommazahlen zur internen Berechnung. Was das Display davon darstellen kann oder nicht, woher soll sie das denn wissen, und das ist der Rendering-Engine auch völlig egal und wurscht, muss es ihr auch sein. Sie berechnet. Völlig egal, wo das Ergebnis dargestellt wird und was damit gemacht wird. Zumal durch Addition bzw. Multiplikation (von Linienstärken zum Beispiel) selbst von kleinsten Werten sich ja größere ergeben können, die wiederum sehr wohl dargestellt werden könenn oder gerundet und abhängig von der Auflösung ein Teil von ihnen dargestellt werden können.

So kann man natürlich mit einer anderen Meinung, die einem nicht passt, auch umgehen. Oder aber Du bist Dir nicht so wirklich im Klaren darüber, über was Du hier redest.

Hat er wirklich? Ich meine: hat er nicht. bzw. er geht da mit der Holzhammer-Methode ran und wundert sich dann über das grobschlächtige, nicht in seinem Sinne stattfindende Ergebnis.

Nicht nur müsste. Sondern das geht auch. CSS Media Queries geben einem da Einiges an die Hand an Möglichkeiten, ermöglichen u.a. genau das. Unter anderen, indem man die DPI-Zahl der oder des anvisierten Ausgabemediums mit angibt (min-resolution) bzw. einen Pixel-Ratio (min-device-pixel-ratio).
Grad' Retina & Co und die damit verbundene Neubetrachtung "Was ist ein Pixel? Und wenn ja, wieviele?" und auch hochauflösende andere Ausgabeformen haben CSS da neu bereichert und erweitert.

Laber Rhababer. Er hat das Offensichtliche benannt. Das Du selber hättest genauso gut benennen können, Screenshots inklusive. Und das ich Dir, weil ich's ausprobiert habe, auch schon obig benannt habe (dass z.B. Firefox alles anzeigt wie es soll, Safari aber offenbar Probleme mit der Darstellung hat), nur haste es nicht akzeptiert, weil's von mir kam.

Akzeptiere einfach mal, dass so mancher, der Dir was anderes sagt, das von Deiner Sichtweise abweicht bzw. Deiner Sichtweise entgegensteht, vielleicht auch mal tatsächlich Recht hat oder mehr Recht hat als Du. So wie Du Dich mir gegenüber auch im privaten Austausch bisher gegeben hast, scheint mir da in Dir ein ganz großes Problem zu liegen. Und genau dann gehst Du immer auf die Barrikaden. Du kannst mit einer anderen Meinung, die möglicherweise richtiger ist als die Deinige, offenbar nicht umgehen, für Dich ist der Andere dann im Negativen immer gleich ein Bessewisser, jemand, der Dich gegen Deinen Willen belehren will. Vielleicht liegt es aber auch lediglich an Deinem Problem, das DU selber hast und gar nicht so sehr an dem Anderen. Da kommt in Dir der Sturkopp durch, nur Deine Sichtweise zählt, und jemand, der Dir widerspricht, wird von Dir aggressiv und feindselig angegangen, den betitelst Du abwertend als Besserwisser.
manchmal weiß so mancher Mensch auch was besser als Du. Ist doch ein völlig normaler Vorgang! Was ist denn Schlimmes daran? Es gibt viele Menschen, die was besser wissen als ich selber! Und darüber freue ich mich sogar und höre mir interessiert an, was sie zu sagen haben und sauge es ggf. sogar begierig in mich auf, auf dass ich dadurch lerne und mein Wissen erweitere. Und stoße sie nicht weg.
Aber das nur am Rande.


Sie ist essentiell, sage ich mal. Grad' im Bereich Web und Webentwicklung. Nicht mal nur so zur Anregung. Das sind Basics, wichtige Basics. Grundlagenwissen, dass man unbedingt braucht, um das was man macht, überhaupt zu verstehen und um bestimmte Auswirkungen überhaupt zu begreifen, warum und wieso etwas passiert oder nicht passiert.

Ich behaupte das Gegenteil. Erst recht, wenn Du testest und bestimmte Ergebnisse vergleichen willst, die mit dem Rendering zu tun haben.

Gut! Damit hast Du zum Beispiel eine noch bessere Grundlage geschaffen, grad' auch, was das Rendering angeht, auf das Du ja im Moment gucken willst. Warum das eine bessere Grundlage ist, was HTML5 bzw. da für Vorteile bringt, grad' in Bezug aufs Parsing und Rendering, also auf die Art, wie die Browser-Engines intern rechnen und welche Algorithmen sie dazu verwenden und warum, und warum sich das ggf. und durchaus unterscheidet vom Parsen/Berechnen eines HTML 4 oder XHTML-Dokuments, ist Dir hoffentlich auch klar?

Nachdem PDF Pronto keine grandiosen Dinge leistet, ich aber neuerdings durch folgende Meldung genervt werde, würde ich von einer Installation abraten.

1. Warum überhaupt eine Installation, ist doch das Ganze eh webbasiert.
2. Was soll das, dass ich deren Suchmaschine nutzen soll. Da wird etwas verquickt miteinander, was erst im Nachhinein klar wird.
3. Und dieses Fenster ist einfach nur nervig. Kommt einmal die Woche etwa. Man weiß nicht, was man da gutheißen soll. Und egal, ob man Cancel oder Next macht, das Fenster verschwindet danach. Wenigstens bei Next sollte ja noch etwas kommen.

Also ziemlich suspekt und nicht vertrauenerweckend. Da die Tage meines Systems bereits gezählt waren und eh eine Neuinstallation anstand, bin ich das Risiko eingegangen. Aber ansonsten lieber Finger weg davon.

Das zu diesem Fenster gehörende Programm AppYM ist ebenfalls minimalistisch und undurchschaubar.