Wikipedia Diskussion:Technik/MediaWiki/Collection

Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 17. Juli 2009 um 15:26 Uhr durch Volker.haas (Diskussion | Beiträge) (Bearbeitungsansicht). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Vorlage:Navigationsleiste Buchfunktion

en:Help:Books/Feedback

fr:Aide:Livres/Problèmes

Die Entwickler der Bucherweiterung sind im IRC #pediapress erreichbar. 
Nicks: hejko, jojob, schmir, v0lk3r
Urheberrechtsfragen werden unter Hilfe:Buchfunktion/Lizenzprobleme diskutiert.


Skin

Dieses Thema wird auch in der FAQ behandelt.
Zu diesem Problem gibt es ein Ticket.
Bugzilla 17693: Article->PDF not available in classic skin

Die Buchfunktion scheint zu den vielen Funktionen zu gehören, die (zunächst) nur mit Monobook-Skin funktionieren. Mit meinem Cologne-Blue-Skin sehe ich nirgendwo einen entsprechenden Menüpunkt. Wenn ich mich auslogge, erscheint der Link an zentraler Stelle im Menü. Bitte ändern, sonst ist das sozusagen ein Verstoß gegen den NPOV.--MSchnitzler2000 02:36, 27. Jan. 2009 (CET)Beantworten

Ich habe hier den Hook SkinBuildSidebar verwendet, der mir von Brion Vibber zu diesem Zweck genannt wurde. Ist der Hook Monobook-spezifisch? Der generische Name des Hooks lässt ja das Gegenteil vermuten. Jbeigel 11:07, 27. Jan. 2009 (CET)Beantworten
Ich weiß nicht, was der Hook ist oder wie der funktioniert. Ich sehe aber nach wie vor im Cologne-Blue-Menü keinen Link für die Buchfunktion. Hoffentlich wird das noch korrigiert, denn die Funktion scheint mir sehr interessant zu sein.--MSchnitzler2000 01:36, 2. Feb. 2009 (CET)Beantworten
Müsste dann im MediaWiki gefixt werden. Jbeigel 14:17, 2. Feb. 2009 (CET)Beantworten

Für die Klassik/Standard-Skin gilt dasselbe: keine Links auf die neuen Funktionen zu finden. -- Nina 22:27, 5. Feb. 2009 (CET)Beantworten

Mein Warnhinweis, den ich auf der Hilfe-Seite eingefügt hatte, wurde mit der sehr seltsamen Begründung „nicht-Monobook Skins sind für Experten“ ersatzlos gelöscht. Was soll das? Um einen Skin auszuwählen, braucht man kein Uni-Zeugnis, sondern lediglich einen Klick auf die eigenen Einstellungen. Es ist wohl eher so, dass die Buchfunktion zu früh und unausgereift freigeschaltet wurde (siehe die endlose Liste der Kritikpunkte) und sich die Entwickler jetzt nicht damit aufhalten wollen, die Funktion so zu programmieren, dass sie für alle Skins verfügbar ist. So lange diese Diskriminierung bestehen bleibt, ist die Buchfunktion für mich gestorben.--MSchnitzler2000 00:15, 8. Feb. 2009 (CET)Beantworten

Ich habe deinen Hinweis wieder reinrevertiert und um den Modern-Skin ergänzt. Tatsache ist aber, dass die anderen Skins eigentlich von gar keinem Entwickler mehr gepflegt werden. Das kann man den pediapress-Entwicklern nicht zum Vorwurf machen. Im übrigen ist es mit MediaWiki und seinen Extensions so wie mit der Wikipedia selber auch: Die Software ist nie fertig und Weiterentwicklungen geschehen immer zusammen mit der Community. Eine Extensions kann monatelang öffentlich in einem Testwiki getestet werden, die wahren Fehler und Wünsche werden erst bekannt, wenn die Software auch in der Wikipedia aktiv wird. — Raymond Disk. Bew. 01:00, 8. Feb. 2009 (CET)Beantworten
Tatsache ist aber, dass die anderen Skins eigentlich von gar keinem Entwickler mehr gepflegt werden. Dann sollte man den Benutzern nicht vortäuschen, dass sie die Auswahl zwischen gleichberechtigten Skins haben, und auf der Einstellungsseite einen weiteren Warnhinweis hinzufügen: „Wer die Wikipedia komplett nutzen will, muss Monobook wählen. Alle anderen Skins funktionieren nur eingeschränkt.“ Bei den Artikeln achtet man sehr genau darauf, dass niemand benachteiligt wird (NPOV). Warum gilt das nicht auch für die Funktionen? --MSchnitzler2000 02:44, 8. Feb. 2009 (CET)Beantworten
Skins sind auch eine MediaWiki-Erweiterung und sollten wesentliche Änderungen wie den von Jbeigel genannten (im MW-Kern implementierten) Hook zeitnah unterstützen. Es wäre nett, wenn du die Entwickler, der von dir verwendeten Skin, direkt bezüglich der Fehlfunktion kontaktierst. Den Hinweis auf die derzeitige Limitierung halte ich (im zweiten Satz) auf der Hilfe zur Buchfunktion für unangebracht. Diese Seite ist vorrangig für Besucher der Wikipedia konzipiert. Diese können mit Begriffen wie Skin und Monobook wahrscheinlich wenig anfangen. Registrierten Nutzern, die eine von der Vorauswahl abweichende Skin gewählt haben, kann m.E. hingegen zugemutet werden, sich bis zur FAQ-Seite durchschlagen um hinsichtlich der Limitierung informiert zu werden. Weiterhin ist es so, dass die Hilfe zur Buchfunktion für Nutzer anderer Skins in der Sidebar derzeit - und das ist das eigentliche Problem - ja gar nicht verlinkt ist und diese daher die Hilfe i.d.R. nicht besuchen um von der Information profitieren zu können. Meine Empfehlung wäre deshalb a) die Entwickler der betroffenen Skins zu kontaktieren b) den Hinweis auf die Limitierung in die FAQs zu übernehmen und sich in der Hilfe zur Buchfunktion inhaltlich auf das für den Großteil der Nutzer wesentliche zu konzentrieren. -- he!ko
Hier noch der Link zur verwendeten Technologie, die in der Skin unterstützt werden müsste. he!ko 11:04, 8. Feb. 2009 (CET)Beantworten
Naja, nicht ganz. Die in MediaWiki vorhandenen Skins sind keine Erweiterung im Extensionsinne. Sie sind Bestandteil des Cores und haben meines Wissens nach keine zuständigen Entwickler mehr, da es einfach Altlasten sind. Sie wurden alle vor Jaaaahren entwickelt, bevor Monobook als Standard eingeführt wurde (und letztes Jahr noch Modern als gepflegter Skin dazukam). Seitdem kümmert sich niemand mehr darum. Wenn ich dürfte wie ich wollte, würde ich CologneBlue, Classic und Chicken sofort rauswerfen, da die Nutzer immer wieder Probleme mit den Skins melden und sich niemand findet, diese Skins zu pflegen. Ich weiß, dass es immer noch viele Benutzer gibt, die aus Gewohnheit, Liebe oder bestimmten Vorteile diese alten Skins noch nutzen und sie vermissen würde, aber … siehe einen Satz zuvor. — Raymond Disk. Bew. 11:37, 8. Feb. 2009 (CET)Beantworten
Ok, wenn die MW-Entwickler sich nicht kümmern, muss man sich selbst helfen. Man kann die Skins ja über JS (auch global) erweitern. Evtl. findet sich jemand, der die Grundfunktionen ("Artikel hinzufügen und Buch zeigen) des "Buch erstellen"-portlets in JS reimplementiert. Zum Hinweis im dritten Satz der Hilfe: Diese Information gehört eher in die FAQ (s.o). Idealerweise finden wir eine Lösung (ggf. CSS?) bei der dieser Hinweis nur für Nutzer einer nicht unterstützen Skin angezeigt werden, dann gerne auch bold im ersten Satz der Hilfe. he!ko 13:03, 8. Feb. 2009 (CET)Beantworten
Ich habe den Warnhinweis von der Hilfe in die FAQ verschoben. he!ko 17:52, 8. Feb. 2009 (CET)Beantworten

Da offensichtlich alle Benutzer zu Monobook gezwungen werden, habe ich jetzt meinen Skin entsprechend gewechselt, um die Wikipedia auch in Zukunft gleichberechtigt nutzen zu können. Nicht weil es mir gefällt, sondern weil es nötig ist, um nicht diskriminiert zu werden. --MSchnitzler2000 23:59, 8. Feb. 2009 (CET)Beantworten

Buch laden

Dieses Thema ist ein Kandidat für die FAQ

Ich habe nun ein buch erstellt - wenn ich jetzt ein nicht von mir erstelltes buch anklicke dann erscheint diese meldung: Dein Buch enthält bereits Seiten. Möchtest du das aktuelle Buch überschreiben, die neuen Seiten anhängen oder das Laden dieses Buches abbrechen? Wird dann mein buch gelöscht? Gruß--ot 07:27, 27. Jan. 2009 (CET)Beantworten

Hier geht es um das aktuell in deiner Session gespeicherte Buch. Je nachdem, welchen Button du klickst wird dieses gelöscht oder nicht: Bei "Überschreiben" wird dein altes Buch "gelöscht" oder eben überschrieben, bei "Anhängen" werden die neuen Artikel an dein bereits bestehendes Buch angehängt. Als eingeloggter Benutzer, kannst du Bücher aber in Form von regulären Wiki-Seiten speichern (Box unten rechts auf Spezial:Buch), diese werden bei obiger Aktion nicht überschrieben. Jbeigel 11:11, 27. Jan. 2009 (CET)Beantworten

Inhaltsverzeichnis

Dieses Problem sollte nach der nächsten Aktualisierung der Software behoben sein.

Meiner Meinung nach wäre es nützlich, ein Inhaltsverzeichnis erzeugen zu können. Andim 08:55, 27. Jan. 2009 (CET)Beantworten

+1--ot 08:57, 27. Jan. 2009 (CET)Beantworten
Dazu gibt es in unserem Issuetracker bereits ein Ticket http://code.pediapress.com/wiki/ticket/277 . Ich werde mich bemühen das in Bälde einzubauen. - Volker.haas 10:19, 27. Jan. 2009 (CET)Beantworten
Ich habe mal das drucken ausprobiert. Da gibt es denn eine druckvorschau. Da ist ein sinnvolles inhaltsverzeichnis vorhanden und eine stichwortverzeichnis am ende des buches. Gruß--ot 18:16, 27. Jan. 2009 (CET)Beantworten
Da hatte ich mich wohl etwas missverständlich ausgedrückt. Für den Buchdruck wird ein anderes PDF erzeugt als das herunterladbare. Das "Buchdruck-PDF" hat - wie du richtig bemerkst - ein automatisch erzeugtest Inhaltsverzeichnis, Index und Abbildungsverzeichnis (inkl. Lizenzen, Autoren von Bildern und Artikeln) -- Volker.haas 11:45, 28. Jan. 2009 (CET)Beantworten
Dieser Abschnitt kann archiviert werden. Volker.haas 14:42, 17. Jul. 2009 (CEST)

Antrag auf wiki-übergreifende Bücher/Sammlungen

Zu diesem Problem gibt es ein Ticket.

Antrag auf wiki-übergreifende Bücher/Sammlungen – etwa um auch Wikisource-Quellen oder einen englischen Artikel mit in ein Buch aufzunehmen. (im Original von Benutzer:Melancholie).

Siehe auch das Ticket in unserem Bug-Tracker. Jbeigel 11:12, 27. Jan. 2009 (CET)Beantworten
Ja, das ist eine interessante Idee. Leider ist das nicht einfach zu implementieren. Es gibt aber einen Workaround (mit der Hilfe eines Bookmarklets) der hier beschrieben ist. he!ko 11:34, 27. Jan. 2009 (CET)Beantworten

Bilder in Infoboxen und Hieroglyphen

Zu diesem Problem gibt es ein Ticket.

Infoboxen, die ein Bild enthalten, werden etwas seltsam zerrissen, weil das Bild umformatiert wird und zentriert wird (z.B. Djoser-Pyramide). Hieroglyphen werden gar nicht dargestellt und einige Hieroglyphenelemente wie Kartuschen oder Serechs werden riesengroß erzeugt, aber nicht mit Hieroglyphen gefüllt (z.B. Userkaf-Pyramide) --GDK Δ 11:54, 27. Jan. 2009 (CET)Beantworten

Bemerkung zu den Infoboxen: In der Tat sieht die Infobox im Artikel Djoser-Pyramide nicht sehr schön aus. Das ganze zu "optimieren" ist leider nicht trivial. Um das zu erklären muss ich etwas ins Detail gehen. Beim Rendern von Tabellen verfolgen wir eine "defensive" Strategie um möglichst alle Tabellen ordentlich darstellen zu können - bei der genannten hat das den gegenteiligen Effekt. Ein Teil der defensiven Strategie ist es einspaltige Tabellen zu entfernen (der Inhalt wird beibehalten). Das ist nötig, da eine Tabellenzelle nicht größer als eine Seite sein darf - das ist aber teilweise der Fall. Der zweite zu beobachtende Effekt ist die Tatsache, dass alle nicht-geschachtelten Tabellen auf die volle Seitenbreite gerendert werden. Das liegt daran, dass die Berechnung der Zellenbreiten nicht immer exakt möglich ist - daher wird sicherheitshalber die volle Breite ausgenutzt. --> Um zu vermeiden, dass die Tabelle auseinander gerissen wird, könnte man das Template anpassen sodass die Tabelle mehrspaltig (in diesem Fall zweispaltig) ist. -- Volker.haas 17:42, 27. Jan. 2009 (CET)Beantworten
Bemerkung zu Hieroglyphen: Dazu gibt es ein Ticket #395. Allerdings ist die Lösung des Problems wohl sehr komplex. -- Volker.haas 17:42, 27. Jan. 2009 (CET)Beantworten

Kategorien

Zu diesem Problem gibt es ein Ticket.

Wenn man im Kategorienamensraum ist wird einem statt Artikel hinzufügen der Eintrag Kategorie hinzufügen angezeigt der statt der Kategorie die enthaltenen Artikel zum Buch hinzufügt, was sinnvoll ist. Dazu zwei Anmerkungen:

  1. Die übernommene Artikelanzahl ist auf 500 beschränkt, obwohl mehr Artikel manuell hinzugefügt werden können.
  2. Wenn ich auf Kategorie hinzufügen klicke und dann auf Buch löschen erscheint nicht wieder Kategorie hinzufügen sondern Artikel hinzufügen auf dessen Klick die Kategorie und nicht die Kategorieartikel einem Buch zugeordnet werden. Diese Inkonsistenz sollte behoben werden.

Außderdem, statt Buch zeigen (x Seiten) sollte vielleicht Buch zeigen (x Artikel) oder so ähnlich stehen, da ich mir bei einem Buch unter Seiten etwas anderes vorstelle. --Mps 17:59, 27. Jan. 2009 (CET)Beantworten

Zu 1.: Wir überlegen, ob wir diese Einschränkung herausnehmen sollen: siehe dieses Ticket in unserem Issue-Tracker mit der Antwort von Brion Vibber. Zu 2.: Das ist ebenfalls ein bekannter Bug, um den man sich noch kümmern muss. Jbeigel 10:27, 28. Jan. 2009 (CET)Beantworten
2. ist mit dieser Änderung gefixt. Jbeigel 12:04, 18. Feb. 2009 (CET)Beantworten
Ja, bei 10 Seiten hatte ich mich schon gewundert, dass das so "kurz" ist. Aus 18 *Artikeln* wurden dann auch 98 *Seiten*. Eine Änderung des Worts würde ich mir wünschen. -- Louisana 15:56, 28. Jan. 2009 (CET)Beantworten

Wie kann man angeben, dass auch Artikel in Unterkategorien zum Buch hinzugefügt werden? Dies ist vor allem bei sehr verschachtelten Kategorien sinnvoll. Zum Beispiel bei der Kategorie:Island mit nur wenigen Artikeln pro Kategorie ist es derzeit sehr umständlich, jede einzelne Unterkategorie hinzuzufügen. Gruß Mike Krüger, ?! 17:40, 16. Feb. 2009 (CET)Beantworten

Gerenderte Formeln

Also auch nochmal hier: Gerenderte Formeln sehen sehr unscharf/pixelig aus. Ich habe es mal mit Maxwell-Stefan-Diffusion probiert und das Ergebnis ist aus meiner Sicht schlechter als Formeln in Word und kommt ganz sicher nicht an mit echtem TeX erzeugte PDFs ran. Mir ist aber unklar, wie Du Dir vorstellst, dass ich das Beispiel hier zeigen soll. Soll ich das PDF hochladen? -- Rosentod 18:46, 27. Jan. 2009 (CET)Beantworten

Die Formeln werden mit TeX zu Grafiken gewandelt und diese im PDF eingebunden. Bei mir sehen die im PDF und im Druck gut aus. Es ist aber auch klar, dass sie bei starker Vergrößerung nicht so gut aussehen können, wie solche die mittels eines Fonts eingebunden sind. Der Link auf Artikel war hinreichend, danke. he!ko 20:09, 27. Jan. 2009 (CET)Beantworten
Mmh. Ich habe sie mir natürlich bei 100 % Zoom angeschaut. In Acrobat unter Windows waren sie "pixelig", auf meinem Mac sind sie dagegen unscharf. Wenn TeX eh schon im Spiel ist, kann man sie dann nicht mittels Fonts einbinden? -- Rosentod 20:16, 27. Jan. 2009 (CET)Beantworten
Die Formel werden mit texvc in Grafiken konvertiert - dies ist die gleiche Software wie sie in der Wikipedia zum Einsatz kommt. Der von dir angesprochene Nachteil ist, dass es keine Möglichkeit gibt die Auflösung der gerenderten Formeln zu erhöhen. Standardmässig werden sie zu 72 DPI Bildern gerendert - mit der Folge, dass sie im Vergleich zum Text nicht großartig aussehen. Diese Limitierung ist aber nur zu beheben wenn texvc dahingehend erweitert wird auch Grafiken mit höherer Auflösung zu erzeugen. -- Volker.haas 11:53, 28. Jan. 2009 (CET)Beantworten
Die Einbindung als Grafik halte ich nicht für optimal. Besonders bei Formeln im laufenden Text treten dabei unschöne Effekte auf. Langfristig sollten Formeln als Fonts eingebunden werden. Wenn ich daheim PDFs mit TeX erzeuge, klappt das ja auch. (Zugegeben, das heißt nicht, dass das leicht ist. Wie schwierig das zu machen ist, weiß ich nicht.) Abgesehen davon gefällt mir die Buchfunktion sehr gut. Auch einzelne Artikel sind ausgedruckt so wesentlich angenehmer zu lesen, als wenn man die Seite direkt ausdruckt. --GluonBall 18:17, 5. Feb. 2009 (CET)Beantworten
Ich stimme zu, dass die Qualität der Formeln verbesserungswürdig ist. Allerdings ist das momentan nicht möglich. Zur Erzeugung der runterladbaren PDFs wird das reportlab toolkit benutzt, welches momentan noch keine Einbindung von Formeln zulässt. Daher müssen momentan Grafiken erzeugt und eingebunden werden. -- Volker.haas 11:05, 6. Feb. 2009 (CET)Beantworten

Bei Wikibooks wird ein Skript eingesetzt, dass die Formeln druckreif rendert: b:Benutzer:Dirk Huenniger/wb2pdf. Es steht unter freier Lizenz. Matthias 16:03, 28. Jun. 2009 (CEST)Beantworten

Einzelnachweise

Dieses Problem sollte nach der nächsten Aktualisierung der Software behoben sein.

Die Überschrift zu den Einzelnachweisen wird nicht als "Einzelnachweis", "Fußnote" etc. wiedergegeben. Statt dessen steht da "Externe Links". Liesel 18:37, 27. Jan. 2009 (CET)Beantworten

Stimmt. Und eventuell vorhandene Geokoordinaten werden da mit reingeschoben. --Felix fragen! 18:43, 27. Jan. 2009 (CET)Beantworten
Das Überschriften wie etwa "Einzelnachweis" oder "Fußnote" in "Externe Links" geändert werden ist Absicht. Dies hat folgenden Grund: beispielsweise URLs werden bei der PDF Generierung nicht direkt ausgegeben sondern referenziert und als Endnoten ausgegeben. -> Die Software versucht nun eine Sektion zu finden, in der lediglich eine Liste von Referenzen (<references/>) steht und hängt die URL-Fussnoten an und ändert die Überschrift. Hierzu gibt es auch ein Ticket (#361) -- Volker.haas 12:16, 28. Jan. 2009 (CET)Beantworten
Die Software kann wohl aus diesem Grund auch nicht mit gruppierten Einzelnachweisen umgehen. Insbesondere wenn man Einzelnachweise und eventuelle Anmerkungen getrennt angeordnet hat ist das sehr ärgerlich (z.B. T-40, schaut da unten in der PDF ziemlich chaotisch aus).--D.W. 19:21, 28. Jan. 2009 (CET)Beantworten
Ticket angelegt. he!ko 21:27, 30. Jan. 2009 (CET)Beantworten
Dieser Abschnitt kann archiviert werden. Volker.haas 14:59, 17. Jul. 2009 (CEST)

Japanisch/Chinesisch

Zu diesem Problem gibt es ein Ticket.

Leider werden beim Export alle chinesischen bzw. japanischen (mit Koreanisch hab ich es nicht probiert, aber wird wohl ähnlich sein) Zeichen völlig übergangen. Könnte man das vielleicht noch einrichten? Wichtig wäre es auch noch, die lang-Vorlage dann zu beachten. In den Artikeln wird fast immer Japanisch, Chinesisch und Koreanisch entsprechend gekennzeichnet. Es sind also 3 (eigentlich 4, chinesische Kurzzeichen und Langzeichen) Fonts dafür notwendig. Siehe auch Vorlage:Lang#Verwendung bei CJKV -- Hellstorm 19:49, 27. Jan. 2009 (CET)Beantworten

Bei mir werden chin./jap. Zeichen angezeigt. Allerdings fordert Adobe vorher zur Installation der Schriften für vereinfachtes Chinesisch auf und zeigt auch japanische Schriftzeichen mit dem Zeichensatz für vereinfachtes Chinesisch an. Wenn man den Zeichensatz nicht installiert, wird ab dem ersten chin./jap. Zeichen die Ausgabe ein Teil des Artikels nicht mehr angzeigt. --Mps 20:52, 27. Jan. 2009 (CET)Beantworten
Momentan werden für die oben genannten Sprachen die Adobe Fonts benutzt und nicht in das PDF eingebunden. Daher müssen - wie mein Vorredner bemerkt - die entsprechende Fontpakete von Adobe installiert werden. Da dies nicht unbedingt wünschenswert ist, werden in Zukunft alle verwendeten Fonts in das PDF eingebunden. Siehe auch Ticket 363 -- Volker.haas 12:16, 28. Jan. 2009 (CET)Beantworten
 
Ein Zeichen, verschiedene Fonts
Das ist nur ein Teil des Problems. Der andere Teil ist, dass für als Japanisch, Koreanisch oder traditionelle chinesische Langzeichen ausgewiesenene chinesische Schriftzeichen nicht pauschal ein Font für vereinfachtes Chinesisch genommen werden sollte. Siehe auch das Bild rechts in dem dargestellt wird das dieselben 3 Unicode-Zeichen in China, Taiwan, Korea und Japan anders geschrieben werden. --Mps 13:27, 28. Jan. 2009 (CET)Beantworten
Sind diese Unterschiede im Mediawiki Markup zu erkennen? -- Volker.haas 16:38, 28. Jan. 2009 (CET)Beantworten
Ja, auf der Wiki-Markup-Ebene meist mittels der Vorlage Vorlage:lang für Japanisch und Koreanisch oder mittels Vorlage:zh für tradtionelles und vereinfachtes Chinesisch, siehe Vorlage:Lang#Verwendung bei CJKV und Wikipedia:NK/J#Sprachauszeichnung. Generischer aber an dem darin verwendeten lang- und xml:lang-HTML-Attribut. --Mps 17:25, 28. Jan. 2009 (CET)Beantworten
Zudem möchte ich anmerken, das die Adobe Schriftpakete nicht auf allen Systemen zur Verfügung stehen. Hier sollten die Schriftarten in das PDF eingebettet werden, sonst haben alternative Betrachter keine Chance, auch wenn das gesamte restliche System ohne Probleme mit chinesischen Zeichen umgehen kann. Ist denn dort kein alternativer "Fallback" eingebaut, falls die Schriftarten auf dem System nicht vorhanden sind? --Niabot議論+/− 11:05, 6. Feb. 2009 (CET)Beantworten
Tut sich in der Hinsicht schon etwas, außer das der Bug als critical eingestuft wurde? Macht nämlich so gut wie jeden Text mit japanischen Inhalten (Zitaten, Referenzen, ...) unbenutzbar. Bzw. die Buchfunktion dafür überflüssig. --Niabot議論+/− 13:22, 7. Mär. 2009 (CET)Beantworten
Zu diesem Problem gibt es ein Ticket.

Ich mir mal angeschaut, wie sich Hamza Hakimzoda Niyoziy als pdf macht und sehe, dass die arabischen Zeichen von seinem Namen a) in der genau falschen Reihenfolge stehen und b) nicht miteinander verbunden werden. Sollzustand siehe Artikel, Istzustand = ﻱزاﻱن ﻩداز مﻱکﺡ ﻩزمﺡ. Gruß, → «« Man77 »» 20:36, 27. Jan. 2009 (CET)Beantworten

Das ist leider ein momentan noch nicht gelöstes Problem - siehe Ticket 288. Vermutlich ist es nur ein geringfügiger Trost, dass im gedruckten PDF dieser Fehler nicht auftritt. -- Volker.haas 12:21, 28. Jan. 2009 (CET)Beantworten

Umgang mit Tabellen

Hallo Kollegen! Ich finde die Erweiterung super, jedoch habe ich zwei Anmerkungen. Haben die Funktion mit dem Artikel Salzburg ausprobiert und bin mehr als begeistert. Mir is jedoch aufgefallen, das Tabellen wie im Abschnitt "Politik" nicht richtig interpretiert werden. Müssen diese Tabellen extra gekennzeichnet sein, um sauber von der Software in PDF´s umgewandelt zu werden? Weiters ist mir aufgefallen das die Bilder zu groß sind. Kann man dies noch optimieren? LG, LiQuidator ;) Disk 20:42, 27. Jan. 2009 (CET)Beantworten

In der Regel müssen Tabellen nicht extra ausgezeichnet werden um "korrekt" gerendert zu werden. Im vorliegenden Fall war das Tabellen-markup aus meiner Sicht etwas abenteuerlich und konnte von unserem Parser nicht korrekt interpretiert werden. Ich habe das Markup minimal verändert um die Tabelle für das Rendern kompatibel zu machen (siehe Änderung). Dabei habe ich das Layout auch minimal verändert - aber ich glaube nicht, dass das vorherige Aussehen explizit so gewollt war. -- Volker.haas 12:54, 28. Jan. 2009 (CET)Beantworten
Bzgl. der Bildergrößen: Es gab schon diverse Diskussionen über Bildergrößen. Manchen Nutzern sind sie zu kleinen, machen zu groß. Das ist ein schwieriges Thema... Die Software versucht einen guten Kompromiss zu erreichen, was nicht immer für jeden zufriedenstellend gelingt. Falls doch der Fall auftritt wo ein Bildgröße fehlerhaft zu sein scheint, freuen wir uns über einen entsprechendes Ticket unter http://code.pediapress.com -- Volker.haas 12:54, 28. Jan. 2009 (CET)Beantworten
Mir sind massive Interpretationsprobleme beim Artikel "FC Bayern München" aufgefallen. Das Problem tritt bei sehr vielen Fussballvereinen auf. (z.B. auch: Eintracht Braunschweig) Woran liegt das in diesen Fällen? --92.76.156.170 23:08, 11. Feb. 2009 (CET)Beantworten

Jedes Buch heißt "collection.pdf"

Zu diesem Problem gibt es ein Ticket.
Bugzilla 17695: File names for generated PDFs are nondescript
Man sollte vor allem den Namen ändern, komischerweise heißt jedes „Buch“ collection.pdf --87.78.35.109 17:13, 28. Jan. 2009 (CET)Beantworten
Einfach z.B. den Titel eines Buches nehmen, kann zu Problemen führen, da versch. Betriebssysteme unterschiedliche Zeichen erlauben/verbieten. Ich halte den Punkt für nicht so kritisch, da man erstens die Datei anschließend noch umbenennen kann und zeitens direkt beim "mit Rechtsklick" den Speicherort & -namen auswählen kann. Jbeigel 15:51, 9. Feb. 2009 (CET)Beantworten
Das Umbenennen vom Originaltitel in ein für das Betriebssystem geeigneten Dateinamen übernehmen doch die Browser. Wenn ich mir den Artikel B*-Baum anschaue und beim Firefox unter Windows mit Seite speichern unter die Seite speichere, wird daraus B -Baum.htm, während beim Firefox unter Linux B*-Baum.html vorgeschlagen wird. Außerdem kann ich den vorgeschlagenen Namen ändern. Den Artikelnamen als Vorgabe zu haben ist daher sehr sinnvoll. Nur wenn mehrere Artikel in einem PDF enthalten sind geht das nicht. --Fomafix 15:00, 18. Feb. 2009 (CET)Beantworten

Schrift- und evt. Bildgrößenskalierung bzw. Seitenskalierung

Zu diesem Problem gibt es ein Ticket.

Ich möchte gerne eine etwas kleinere Darstellung haben - bei gleicher Druckseitenausnutzung - und möchte deshalb vorschlagen, einen Seitenskalierungsfaktor (Standard = 100%) zu implementieren, mit der man den Seiteninhalt verkleinern kann, z.B. um mehr Text und Bilder pro Druckseite darstellen zu können. Wäre dies machbar ? --Wikinaut 21:12, 28. Jan. 2009 (CET)Beantworten

In Zukunft soll es möglich sein, dass resultierende PDF besser zu konfigurieren. Dazu werden Schriftgrößen und maximale Bildgrößen zählen. So sollte das von dir gewünschte Resultat auch zu erreichen sein. Siehe auch Ticket 419. -- Volker.haas 17:06, 29. Jan. 2009 (CET)Beantworten

Wie ware es mit Namespace Buch: ?

Im übrigen, sollte man nicht besser einen (einfachen und kurzen) Namespace Buch: aufmachen, in dem die Bücher abgelegt werden ? --Wikinaut 11:41, 29. Jan. 2009 (CET)Beantworten

Oh, Parallelposting ;-) Als Kurzvermerk hier meine Antwort zur gleichen Frage an anderer Stelle. --:bdk: 12:10, 29. Jan. 2009 (CET)Beantworten

letzte gesichtete Version verwenden

Zu diesem Problem gibt es ein Ticket.

Vielen Dank für diese sehr übersichtliche, einfache und im Ergebnis schon recht anschaubare Möglichkeit der PDF Erstellung :) . Derzeit wird die aktuellste Version verwendet, wenn möglich sollte die letzte Gesichtete Version genommen werden. Grüße, Conny 19:57, 29. Jan. 2009 (CET).Beantworten

Man kann aus der Versionsgeschichte jede Version auswählen, auch die ganz erste von 2004 oder so, und diese hinzufügen. Das ergibt natürlich gute Anwendungsmöglichkeiten. Ausprobiert. -jkb- 20:06, 29. Jan. 2009 (CET)Beantworten
Händisch, klar. Ich möchte gern eine Kategorie hinzufügen und dort nur gesichtete Versionen verwenden. Bei Kategorien mit mehr als Einhundert Artikeln beispielsweise steigt die Wahrscheinlichkeit, dass Artikel gerade vandaliert wurden ;) . Conny 20:14, 29. Jan. 2009 (CET).Beantworten
Ticket angelegt. he!ko 21:08, 30. Jan. 2009 (CET)Beantworten

Was haltet ihr von dem Vorschlag im Ticket, bei Kategorien immer die gesichtete Version (falls vorhanden) der Artikel aufzunehmen? Das sollte m.E. in 99% der Anwendungsfälle dem gewünschten Verhalten entsprechen. he!ko 13:29, 31. Jan. 2009 (CET)Beantworten

Finde ich als Standardeinstellung sinnvoll. Vielleicht sollte das „wenn vorhanden“ bleiben, falls andere Wikipedias mit dem Sichten nicht so schnell vorran kommen und dann Artikel einer Kategorie gar nicht auftauchen. Mit Wahlmöglichkeit (so scheint mir das Ticket) ist für Leute sinnvoll, die aktuelleste Version erzwingen wollen. Grüße, Conny 23:20, 5. Feb. 2009 (CET).Beantworten

Hauptautoren einmal am Ende

Es ist m.E. viel übersichtlicher (wenn man bspw. 15 Artikel nimmt) die Hauptautoren am Ende nach Artikel zu sortieren, als immer mal zwischen drin. Es ist oft zusammenhängendes, dann stört das. --Gruß Herrenberger D / B 12:54, 30. Jan. 2009 (CET)Beantworten

Ob es übersichtlicher wäre ist wohl ein subjektiver Bewertungsansatz. Bedenken habe ich aber eher juristischer/lizenztechnischer Art - wenn ich nicht suche, könnte es ja den Eindruck machen, sie sind gar nicht da. Alaso finde ich die Autoren jeweils am Ende des jeweiligen Artikels angebrachter. -jkb- 16:14, 30. Jan. 2009 (CET)Beantworten
Bei WikiReader wurde es doch auch ohne Probleme ans Ende gesetzt? --Gruß Herrenberger D / B 18:21, 30. Jan. 2009 (CET)Beantworten
Referenzen funktionieren seit Jahrhunderten am Ende von gedruckten Werken. Warum sollte es hier nicht funktionieren. Desweiteren sollte man die Schriftgröße auch gleich mal anpassen, den wer erstellt sich schon gerne ein 200 seitiges Buch, bei dem 23 Seiten Autoren genannt werden. Nicht falsch verstehen, Autoren müssen genannt werden, aber bei einem "Buch" sind sie nach dem Inhalt erst einmal zweitrangig für den Leser. -- 91.55.14.112 18:36, 31. Jan. 2009 (CET)Beantworten
Gut, zweitrangig für den Leser, einverstanden. Es ist aber bei der unglücklichen GFDL jedoch erstrangig für die Litera der Lizenz, wo bei jedem Artikel die Autoren zu nennen sind, und die Zuordnung muss eindeutig sein. Übrigens, wenn Du die Autoren nach hinten verschiebst, bleiben es immer noch die 23 Seiten. Unter Umständen noch mehr, da dort noch zig-mal die Überschrift eigebaut werden müsste "... Hi, und dies sind die Autoren des Artikels ABC auf der Seite 123... ". Wenn's überhaupt ginge. -jkb- 18:51, 31. Jan. 2009 (CET)Beantworten
Ja mir persönlich geht es nicht wirklich um die zwei Seiten mehr am Ende. Wenn es lizenzrechtlich (was man sicher prüfen könnte) möglich wäre... könnte man doch sicher eine Checkbox machen beim Erstellen ob nach jedem Artikel oder einmal am Ende des Buches die Hauptautoren aufgelistet sind. Ich persönlich kann auch mit der jetzigen Lösung leben, wenn die Hauptautoren aber am Ende sind finde ich es aber wirklich lesefreundlicher. --Gruß Herrenberger D / B 19:24, 31. Jan. 2009 (CET)Beantworten
Die lizenzrechtlichen Auslegungen muß ich anderen überlassen. Nur um es einmal klar zustellen, ich spreche hier über das unter Special:Buch erstellbare .pdf. In dem unter pediapress verfügbaren Sample [1] ist diese Lösung bereits sehr übersichtlich und benutzerfreundlich umgesetzt. Technisch kann es also kein Problem sein. -- 91.55.14.112 20:38, 31. Jan. 2009 (CET)Beantworten
Dieser Abschnitt kann archiviert werden. Volker.haas 15:03, 17. Jul. 2009 (CEST)

Variablen wie {{CURRENTDAY}} im Titel/Untertitel/usw. erlauben --> vor der PDF-Generierung durch den Parser jagen

Zu diesem Problem gibt es ein Ticket.

Ich habe in meinem Buch im Untertitel die Variablen {{CURRENTDAY2}}, {{CURRENTMONTH}} und {{CURRENTYEAR}} verwendet. Leider werden diese bei der Bucherzeugung nicht ersetzt. Wäre aber sehr sinnvoll, wenn diese Werte nochmal durch den Wikiparser gehen, bevor das PDF generiert wird. Vorteil: meine andere Anfrage würde sich dann erledigen und jeder könnte das Generierungsdatum auf die Titelseite des Buches/PDF rendern lassen.

Siehe dazu auch oben Hilfe:Buchfunktion/Feedback_zur_Buchfunktion#Hilfe:Variablen.23Generelle.2C_konstante_Variablen.

--Wikinaut 23:05, 2. Feb. 2009 (CET)Beantworten

Ist im nächsten Update behoben. he!ko 23:59, 2. Feb. 2009 (CET)Beantworten
Im nächsten Update werden zwar Variablen wie die o.g. ersetzt, allerdings nicht im Titel oder Untertitel eines Buches. Ich habe ein Ticket aufgemacht. Jbeigel 11:50, 3. Feb. 2009 (CET)Beantworten

Bücherregal für gespeicherte Bücher

Da die Kategorie:Wikipedia:Bücher nicht sonderlich gut strukturiert ist und auch die Liste der gemeinschaftlichen Bücher mit der Zeit wohl unübersichtlich wird, planen wir mit Hilfe dieses Bots ein Bücherregal aufzubauen. Wie das aussehen könnte, kann man sich in hier schon einmal ansehen. Die Darstellung kann man über Vorlagen steuern. Neu ist auch, dass (seit gestern) gepeicherte Bücher am Anfang die Vorlage:gespeichertes Buch einbinden; Beispiel Wikipedia:Bücher/Computergrafik -- he!ko 15:51, 4. Feb. 2009 (CET)Beantworten

Gegenwärtig werden Weblinks und Email-Adressen an das Dokumentende geschrieben. Bei langen Artikeln ist das mühsam, sie nachzuschlagen. Vielleicht ist es besser, sie an den Ort des Aufrufs zu stellen, so wie dies beim Drucken geschieht. --RolandUnger 08:40, 5. Feb. 2009 (CET)Beantworten

fände ich nicht so hilfreich. das buch ist ja eher für "offline" gedacht. da ist mir der weblink eher nicht so wichtig. wichtiger ist mir da ein guter lesefluss der bei dazwischen auftretenden links unterbrochen wird. für e-mail-adressen ebenso wobei ich mich frage wo denn e-mail-adressen stehen? In den ANR gehören die eigentlich nicht?! ...Sicherlich Post 19:20, 5. Feb. 2009 (CET)Beantworten
Links sind nach meiner Erfahrung sehr oft lang - dies erschwert ordentliche Zeilenumbrüche und ist insbesondere in Tabelle noch problematischer, weil der Platz dort noch knapper ist. Daher werden URLs immer am Ende eines Dokumentes dargestellt. Fußnoten sind in den runterladbaren PDFs momentan nicht möglich, daher bleibt nur die Option Links am Ende des Artikels zu platzieren. -- Volker.haas 11:17, 6. Feb. 2009 (CET)Beantworten
Die Fußnoten wären auch eine nützliche Idee für die Zukunft. --RolandUnger 14:44, 6. Feb. 2009 (CET)Beantworten
Die Fußnoten sollten, wie im Druck üblich, auf der Seite angezeigt werden, auf der sie gesetzt werden. Nicht immer sind hier nämlich nur Literaturangaben oder Weblinks zu finden, sondern auch weiterführende Hinweise (bspw. in Carl Schmitt.) Ich verstehe auch nicht so recht, wie diese Problem auftreten konnten, wenn doch Latex genutzt wurde, das alle dafür nötigen Erweiterungen von Haus aus mitbringt? -- Tisch & Stuhl φιλο 10:54, 4. Mär. 2009 (CET)Beantworten

Einige Änderungsvorschläge

Ich hab hier ein paar Sachen, die ich verändern würde:

  • Der Link "Buch löschen" ist etwas verwirrend. Wenn man drauf klickt, wird ja die Liste gelöscht, aber als ich mein erstes Buch gespeichert hatte, wusste ich (noch) nicht, ob ich damit die Liste und/oder mein gespeichertes Buch lösche. Vieleicht lässt sich das günstiger formulieren.
  • Ich weiss, dass es in Büchern unüblich ist, Unterkapitel zu erzeugen, jedoch bieten diese sich bei mir und meinen "Raumfahrtbüchern" durchaus an.

Wenn irgentwas davon schon genannt wurde, sorry, aber ich hab keine Lust, den ganzen Kram hier durchzuwühlen (vilt ne ToDo über dem Inhaltsverz.?)--HarryDisk+/-Bau 19:14, 5. Feb. 2009 (CET)Beantworten

bzgl. "buch löschen" - das problem hatte ich auch :) ...Sicherlich Post 19:17, 5. Feb. 2009 (CET)Beantworten
Wie wäre es mit "Buch vergessen"?--Eloquence 19:26, 5. Feb. 2009 (CET)Beantworten
Buch-Charge leeren?--HarryDisk+/-Bau 21:28, 5. Feb. 2009 (CET)Beantworten
Nee, „Buch vergessen“ erinnert an das weitverbreitete „Passwort vergessen“. Würde also genau das Gegenteil meinen. --Mps 11:34, 6. Feb. 2009 (CET)Beantworten
"Buch verwerfen"? --GluonBall 14:51, 6. Feb. 2009 (CET)Beantworten
Ist nicht das Problem an der Formulierung, dass man nicht auf den ersten Blick erkennt, auf was sich "Buch" bezieht (aktuelles Buch in der Session vs. gespeichertes Buch)? Alle Vorschläge das Verb zu ersetzen, haben doch dasselbe Problem? Jbeigel 16:04, 9. Feb. 2009 (CET)Beantworten
Währe dann "(Buch-)Session beenden" ne möglichkeit?--HarryDisk+/-Bau 16:55, 9. Feb. 2009 (CET)Beantworten
Eine konzeptuell saubere Trennung im UI zwischen vergänglichen Büchern die an die Session gebunden sind und gespeicherten Büchern wird wohl schwierig. Allerdings würde ich empfehlen auf einer Seite mit einem gespeicherten Buch, den Menüpunkt Buch löschen einfach nicht anzuzeigen. he!ko 17:11, 12. Feb. 2009 (CET)Beantworten

Eigenes Vorwort

Dieses Problem sollte nach der nächsten Aktualisierung der Software behoben sein. Dieses Thema ist ein Kandidat für die FAQ

Vielen Dank für diese tolle neue Funktion. Ich find's großartig!

Meine Fragen:

Ich möchte ein VORWORT ins Buch aufnehmen, und experimentiere mit mehreren Versionen, die alle nicht funktionieren. Bitte helft mir.

Test 1 "Vorwort als Benutzerseite" http://de.wikipedia.org/wiki/Benutzer:Omdomo/B%C3%BCcher/Goanautenfutter_Band1_testing01 PHP fatal error in /usr/local/apache/common-local/php-1.5/includes/Article.php line 50: Argument 1 passed to Article::__construct() must be an instance of Title, null given, called in /usr/local/apache/common-local/php-1.5/extensions/Collection/Collection.body.php on line 550 and defined

Test 2 "Vorwort inline" http://de.wikipedia.org/wiki/Benutzer:Omdomo/B%C3%BCcher/Goanautenfutter_Band1_testing02 Das scheint zunächst zu funktionieren, aber dann FEHLT das Vorwort in der PDF-Datei.

Was kann ich tun?

Ausserdem: Wie erzeugt man ein Inhaltsverzeichnis? Wie erzeugt man ein Stichwortverzeichnis?


Dein Test 1 hätte eigentlich genau so funktionieren müssen. Das ist noch Bug, danke für den Hinweis. Der Fehler sollte nach dem nächsten Update behoben sein.
Hach, das ist ja schön, dass ich da helfen konnte...
Hierzu noch ein Tip: Du kannst die gespeicherte Buch-Seite editieren und den Titel der im PDF angezeigt werden soll setzen. Das geht so: [[Benutzer:Omdomo/Bücher/Goanautenfutter_Band1_Vorwort|Vorwort]]
Super-Sache, danke. Die Frage wäre tatsächlich gleich als nächstes aufgetaucht.
Dein Test 2 geht nicht. Das genaue Format gespeicherter Bücher ist auf Hilfe:Buchfunktion/für_Experten beschrieben.
Wie schade, denn eine "inline"-Textmöglichkeit könnte sehr leicht ein Buch erzeugen, in dem man immer mal wieder eigenen Kommentare, Vorworte etc. ganz unkompliziert einbauen kann.
Die Option Inhaltsverzeichnis wird es für PDFs wohl bald geben. Einen Index gibt es bisher nur in gedruckten Büchern. Im PDF-Reader wird in der Regel ja eine Suchfunktion angeboten, da macht ein Stichwortverzeichnis m.E. weniger Sinn. he!ko 17:28, 6. Feb. 2009 (CET)Beantworten
D'accord.
Zu dem o.g. Bug: Das sollte mit dieser Änderung behoben sein. Beim nächsten Update durch Brion sollte es also funktionieren.
Zum Inhaltsverzeichnis: Das Feature ist geplant
(Zumindest ein zunächst noch unklickbares) müsste ja sehr leicht sein - im Grunde genommen nur den Buchseite-Quelltext (leicht bereinigt) selbst nochmal reinkopieren, oder?


Zum Stichwortverzeichnis: Das gibt's momentan nicht im PDF (die PediaPress-Bücher beinhalten ein Stichwortverzeichnis; aufgrund der unterschiedlichen verwendeten Technologie ist der Code aber nicht ohne weiteres auf das herunterladbare PDF übertragbar). Jbeigel 17:22, 6. Feb. 2009 (CET)Beantworten
nebenbei, die idee mit dem eigenen Vorwort (was ja auch eine Widmung oder resume usw. sein kann) finde ich echt gut. -jkb- 17:51, 6. Feb. 2009 (CET)Beantworten
Danke. Ich auch :-)

Verschwundene Bilder?

Zu diesem Problem gibt es ein Ticket.

Bei Russisch-Orthodoxe Kathedrale (Wien) werden keine Bilder eingebaut, dafür steht „thumb“ und die Bildunterschriften im Text --Feldkurat Katz 22:10, 7. Feb. 2009 (CET)Beantworten

Habe dasselbe bei mehreren anderen Artikeln auch bemerkt, z.B. St. Elisabeth (Opladen). Scheint aber nicht auf Kirchen-Artikel beschränkt zu sein. -- DrTom 22:52, 7. Feb. 2009 (CET)Beantworten
Dieses Problem grenzt an Sabotage ;) Ich habe mir beide Artikel angeschaut und festgestellt, dass in den Bildlinks unsichtbare Zeichen stehen. Diese Zeichen werden vom Mediawiki anscheinend ignoriert - das Bild wird korrekt dargestellt. Der mwlib Parser ignoriert die Zeichen aber nicht und erkennt daher den Bildlink nicht. Ich habe ein Ticket dafür angelegt. -- Volker.haas 16:28, 9. Feb. 2009 (CET)Beantworten
Stellt sich auch die Frage, wie die Zeichen dort hineinkommen: Es sind in beiden Artikeln dieselben (oktal 342 200 216). Dass innerhalb des Artikels dieselbe Sequenz mehrmals vorkommt, lässt sich durch cut-and-paste erklären, aber bei verschiedenen? --Feldkurat Katz 21:06, 9. Feb. 2009 (CET)Beantworten

hier und hier auch. die kommen wohl von pc's, die mit anderen schriftsystemen arbeiten: russisch, chinesisch, hindi, japanisch,...--toktok 19:50, 28. Feb. 2009 (CET)Beantworten

Probleme mit dem Seitenumbruch

Ich habe die Buchfunktion jetzt mit ein paar Artikeln erstmals ausprobiert und mir sind gleich drei Probleme in der PDF-Darstellung aufgefallen.

  1. Wenn sich Grafiken in der Nähe von Überschriften befinden, entstehen beim Seitenumbruch große Lücken. Auf einer Seite steht die Überschrift und dahinter eine leere Fläche. Auf der nächsten Seite geht es mit dem Text und den Grafiken weiter.
  1. Zum Thema Seitenumbrüche und Grafiken siehe bitte auch meinen Kommentar hier. Könntest du bitte ein Beispiel für den beschrieben Fall von dir nennen, möglicherweise ist das ein anderer Effekt/Bug. -- Volker.haas 17:20, 9. Feb. 2009 (CET)Beantworten
In der PDF-Version des Artikels Düren tritt das Problem mehrfach auf, z.B. bei den Überschriften „Stadtrat und Verwaltung“ sowie „Kultur und Sehenswürdigkeiten“.--MSchnitzler2000 18:15, 9. Feb. 2009 (CET)Beantworten
Danke für die Hinweise, ich kann das leider nicht ganz nachvollziehen, da inzwischen eine neuere Version online ist. Allerdings gibts in der heutigen Version ein Problem mit Seitenumbrüchen bei den Abschnitten "Einwohnerentwicklung" (8) und Kirchen (14) - diese Probleme sollten aber mit dem nächsten Update behoben sein. -- Volker.haas 17:20, 13. Feb. 2009 (CET)Beantworten
  1. Tabellen werden beim Seitenumbruch zerrissen. Sieht besonders dann blöd aus, wenn nur ein oder zwei Zeilen der Tabelle vor dem Seitenwechsel erscheinen.
  1. Das ist in der Tat leider nicht so schön. Hierfür habe ich ein Ticket angelegt. -- Volker.haas 17:20, 9. Feb. 2009 (CET)Beantworten
  1. Wenn man mehrere Artikel zu einem Buch zusammenfasst, wird der zweite Artikel direkt an das Ende des ersten gehängt (und natürlich auch der dritte an den zweiten usw.). Hier wäre es übersichtlicher, wenn jeder Artikel auf einer neuen Seite beginnt. Mit der Funktion "Kapitel erzeugen" kann man zwar einen Seitenumbruch erreichen, aber ich will vor allem bei umfangreicheren Büchern nicht gezwungen sein, für jeden Artikel ein Kapitel zu erzeugen.
  1. Zu diesem Thema gehen die Meinungen auseinander. Ich glaube wird hatten auf der Mailingliste zu diesem Thema schon einmal eine Diskussion. Sobald über die Collection Erweiterung einzelne Parameter bzgl. des PDF-Layouts einstellbar sind, wird diese Möglichkeit sicher dazu gehören. (Der PDF Renderer verfügt bereits über die entsprechende Option - sie kann vom Nutzer aber noch nicht geändert werden) -- Volker.haas 17:20, 9. Feb. 2009 (CET)Beantworten

--MSchnitzler2000 02:19, 9. Feb. 2009 (CET)Beantworten

Vorlage

Zu diesem Problem gibt es ein Ticket.

Die {{Vorlage:Schachbrett}} wird im PDF etwas "grob" umgesetzt. Gruß, Stefan64 23:33, 12. Feb. 2009 (CET)Beantworten

Das Schach Template wird leider wirklich nicht gut gerendert. Das Problem ist, dass momentan alle Tabellen auf die maximale Breite vergrößert werden. Das ist leider nicht einfach zu ändern, da ansonsten ab und zu Text über die Zellengrenzen läuft. Ich habe dafür aber ein Ticket angelegt. -- Volker.haas 17:39, 13. Feb. 2009 (CET)Beantworten
Kann die Vorlage nicht als Bild "gelesen" werden? --Stefan Stern 04:06, 1. Jun. 2009 (CEST)Beantworten

Anordnung der PDF-Überschrift „Lizenz“

Da die Lizenz für das ganze Dokument gilt, sollte die Abschnittsüberschrift „Lizenz“ eine Ebene höher angeordnet werden (wie die „Kapitelüberschriften“). Momentan erscheint sie im automatischen PDF-Inhaltsverzeichnis nur wie die Überschrift des letzten Artikels (unterhalb der letzten echten Kapitelüberschrift). -- \mu/ 19:11, 13. Feb. 2009 (CET)

Dieser Abschnitt kann archiviert werden. Volker.haas 15:11, 17. Jul. 2009 (CEST)

Kleinigkeiten zu Quelle, Bearbeiter und Lizenz

Ich möchte die zwei drei Kleinigkeiten die mir aufgefallen sind, einmal beispielhaft am PDF-Export einzelner Artikel erklären. Angefangen mit dem Export des Artikels Buchdruck in Venedig.

  • Unterhalb des Artikels steht „Quelle: http://de.wikipedia.org/w/index.php?title=Buchdruck_in_Venedig&oldid=49000270“, diese Quellenangabe passt allerdings nicht in eine Zeile und wird daher zweizeilig dargestellt. Das stellt zwar kein Problem da, jedoch wird die Quelle nun im Blocksatz dargestellt, was nicht gerade gut aussieht.
  • Der letzte Bearbeiter in diesem Dokument heißt „1 anonymous edits“. Hier sollte meiner Meinung nach eine Lokalisierung erfolgen. Dabei sollte auch darauf geachtet werden ob es sich wirklich um mehrere anonyme Bearbeitungen handelt (Singular/Plural).
  • Im PDF-Export von Saginaw Art Museum steht: „Bearbeiter: Minderbinder,“ hier steht am Ende ein Komma zuviel. Ich vermute dieses betrifft alle Artikel ohne anonyme Bearbeiter.
  • Im Abschnitt Lizenz heißt direkt zu Anfang: „Abkürzung: WP:GFDL“ meiner Meinung nach sollte hier eher etwas wie „GNU Free Documentation License (GFDL)“ stehen.
  • Der Letzte Absatz „How to use this License for your documents“ wird zwar wiedergeben, aber scheinbar selbst nicht erfüllt.

Ich finde die Buchfunktion eine große Bereicherung für unser Projekt. Vielen Dank für eure hervorragende Arbeit. --M.L 17:56, 14. Feb. 2009 (CET)Beantworten

Der Blocksatz in der Quellenangabe und die Lokalisierung sind gelöst und das Komma am Ende kommt auch weg. Zur Abkürzung in der Lizenz: Man könnte es einfach ändern. Es ist eine gewöhnliche Wiki-Seite die gezogen und eingebunden wird. Ich kenne leider die aktuelle Konfiguration nicht und weiß daher nicht welche es ist. Und wenn mir jemand das Titelblatt der Wikipedia zeigen kann, dann kümmere ich mich auch gerne darum, dass der GFDL im PDF bis auf's letzte Komma entsprochen wird :) --he!ko 01:32, 16. Feb. 2009 (CET)Beantworten
Hallo, ich würde vorschlagen, aus "anonyme Autoren" korrekt "unangemeldete Benutzer" zu machen. Darum geht es ja (unangemeldet: hat keinen Benutzernamen), während man ja auch als Angemeldeter "anonym" (genau: pseudonym) bleiben kann.-- Ziko 20:21, 3. Mär. 2009 (CET)Beantworten

Ich versuche herauszufinden, wie ausgehend von einem Inhaltsverzeichnis eine Navigation im gedruckten Buch erfolgen kann. Es werden im Inhaltsverzeichnis keine Seitenzahlen genannt. Auch werden in den Kapitelüberschriften keine Nummerierungen genannt(Beispiel 1.3 Unterverzeichnis einspunktdrei). Kann mir jemand einen Hinweis geben. Ich habe nichts dazu gefunden.

Gedruckte Bücher basieren auf einem anders erzeugten, speziell für den Buchdruck angepassten PDF-Dokument, welches selbstverständlich ein Inhaltsverzeichnis (Beispiel) und auch einen Index (Beispiel) enthält. --he!ko 16:04, 18. Feb. 2009 (CET)Beantworten
Danke für die Info. So wie ich es sehe, sind im gezeigten Inhaltsverzeichnis die einzelnen Artikel mit Seitenzahlen referenziert. Dabei werden weitere Untergliederungen allerdings unterschlagen. Wenn einzelne Artikel 50 Seiten lang sind, dann sind deren Inhalte nur äußerst schwer zugänglich. Beste Lösung, die ich bislang gefunden habe, ist ein Export als OpenDocument und das manuelle Hinzufügen eines Inhaltsverzeichnisses. --TrueType76 18:30, 18. Feb. 2009 (CET)Beantworten
Wir hatten früher im Inhaltsverzeichnis auch alle Sektionen der Artikel gelistet. Da wurde das Inhaltsverzeichnis (verteilt über viele Seiten) aber unübersichtlich. Ich denke, das ist Geschmackssache und wohl auch abhängig davon, ob man eher kurze oder eher lange Artikel im Buch hat. --he!ko 20:01, 18. Feb. 2009 (CET)Beantworten
wäre dann bestenfalls ein zusätzlicher Parameter, den man vor dem Druck angeben kann. --83.236.199.98 09:59, 19. Feb. 2009 (CET)Beantworten
Und wenn man die Seitenzahlen bei den Inhaltsverzeichnissen der einzelnen Artikel hinzufügt? Ich weis nicht, ob das technisch machbar ist, aber es würde das Problem bei langen Artikeln lösen, ohne dass das Inhaltsverzeichnis des Buches länger wird und ohne das das Buch insgesamt länger wird, da die Inhaltsverzeichnisse der Artikel ja ohnehin im Buch sind. Man würde dann über das Buch-Inhaltsverzeichniss die erste Seite des Artikels finden und im dortigen Artikel-Inhaltsverzeichnis dann die Seite des (Unter-)Kapitels. --78.51.18.23 21:32, 20. Feb. 2009 (CET)Beantworten

Die Datei wurde erfolgreich erstellt. Dokument herunterladen.

Teilweise tritt bei Firefox 3.0.6 das Phänomen auf, dass bei Rechtsklick auf Dokument herunterladen eine index Datei und nicht die collection.pdf als Ziel ausgegeben wird. Ich weiß nicht wie der Ablauf ist, wenn dieser Verweis für das fertige PDF trotzdem angeklickt und eine Öffnung im Browser abgewartet wird (hatte bisher immer schlechtere Erfahrungen damit).

Wenn man den Seitenverweis der Dokument herunterladen Seite in einem anderen Browser öffnet (zum Beispiel SRWare Iron), klappt es. Betrifft in meinem Fälle größere Dateien (hier jetzt 80 MB). Grüße, Conny 11:56, 19. Feb. 2009 (CET).Beantworten

Danke für den Hinweis. Ich habe gestern ein paar Änderungen am "Content-dispostion"-Header vorgenommen. Evtl. ist damit das Problem gelöst (nach dem nächsten Release und Update der Software auf dem Render-Server). Jbeigel 15:40, 24. Feb. 2009 (CET)Beantworten

letzte Blocksatzzeile bei Seitenwechsel mit Bild im Absatz

Zu diesem Problem gibt es ein Ticket.

Wenn ein Bild eingebunden ist, welches nicht mehr auf eine Seite passt, wird der durch einen Absatz endende Text auf der alten Seite trotz weniger Worte auf der letzten Zeile als Blocksatz erzwungen. Grüße, Conny 13:07, 19. Feb. 2009 (CET).Beantworten

Könntest du bitte einen Beispielartikel nennen bei dem das Problem auftritt. -- Volker.haas 15:41, 24. Feb. 2009 (CET)Beantworten
Im erstellten PDF von [2] auf Seite 8 letzte Zeile. Grüße, Conny 12:29, 4. Mär. 2009 (CET).Beantworten

PDF-Datei beschädigt und nicht reparierbar

Das "Bücher machen" habe ich erstmals ausprobiert - ist ja toll! Aber dann die kalte Dusche: Benutzer:Dark_Avenger/Bücher/Burgen_im_Allgäu sowohl als auch Wikipedia:Bücher/Ostfriesische_Inseln_und_Wattenmeer habe ich heruntergeladen, und dann sagt mir der Acrobat-Reader 8: Datei beschädigt und nicht reparierbar.

Was nun? Was tun? - geht nicht? gibt's nicht?--Agp 13:37, 19. Feb. 2009 (CET)Beantworten
Ostfriesische Inseln und Wattenmeer habe ich runtergeladen und es ging. Probier einfach nochmal? ..Sicherlich Post 13:45, 19. Feb. 2009 (CET)Beantworten
Das hatte ich auch schon mal. Nach einem Neustart von PC und Browser gings dann aber wieder. Gruß, Stefan64 13:49, 19. Feb. 2009 (CET)Beantworten
Ostfriesische Inseln und Warrenmeer geht, liegt an deinem System. Conny 14:12, 19. Feb. 2009 (CET).Beantworten

Kann man so oder so sehen: Ich habe den Acrobatreader auf Vers. 8.1.3 upgedatet, hat aber nichts genützt. Dann habe ich es mit dem Internet-Explorer von Microsaft probiert. Und da ging es - Sollte Wikipedia denn nicht auch mit Seamonkey laufen? --Agp 01:39, 20. Feb. 2009 (CET)Beantworten

Warum nicht gleich Reader Version 9? Aber ich habe mal Adobe Acrobat 6 Prof. probiert, der bei mir noch installiert ist, und da kommt der selbe Fehler. Vielleicht benutzt dein Seamonkey, ja nicht die 8.1.3, sondern eine ältere? --Mps 15:38, 20. Feb. 2009 (CET)Beantworten
Nein - der Fehler tritt im Acrobat-Reader 8.1.3 auf, aber eben nur bei Seamonkey, mit dem ich normalerweise arbeite und nicht im Internet-Explorer, den ich dann mal probiert habe. Der Fehler ist auch, wie ich jetzt sah, schon weiter oben mal beschrieben.--Agp 17:50, 20. Feb. 2009 (CET)Beantworten
Ich benutze auch immer Seamonkey (auf verschiedenen Rechnern, mit verschiedenen Acrobat-Reader-Versionen) und kann das Problem nicht nachvollziehen. Den Reader 8.1.3 habe ich im Moment nicht griffbereit, aber im 6.0.6 (jaja, das ist hier gerade ein alter PC mit diversem altem Zeug, aber aktuellem SeaMonkey 1.1.14) wird das "Burgen im Allgäu"-PDF jedenfalls anstandslos geöffnet. Gestumblindi 04:30, 25. Feb. 2009 (CET)Beantworten

Seitennummerierung

Die Seitennummerierung der PDFs sollte wechselseitig (linksoben, rechtsoben) sein, da man größere Dokumente meist beidseitig druckt. Vielleicht ist eine Auswahlmöglichkeit sinnvoll. Conny 15:28, 19. Feb. 2009 (CET).Beantworten

ODT auf englisch gestellt

Zu diesem Problem gibt es ein Ticket.

Wenn man sich jetzt eine Kollektion im Open Document Format runterlädt, wird der gesammte Text unterstrichen, weil die Textsprache auf Englisch eingestellt ist. Könnte man das noch an die sprache im jeweiligen Wiki anpassen? Gruß, --Revolus Echo der Stille 08:37, 20. Feb. 2009 (CET)Beantworten

Ich möchte hier noch einmal darauf hinweisen, dass eine Lokalisierung erwünscht ist. Ich vermute nämlich, dass damit auch das Problem gelöst wäre, dass Datumskonvertierungen falsch vorgenommen werden. Beispiel: Spremberg, in der Infobox wird "2007-12-31" zu "31. Dec 2007" konvertiert, obwohl "31. Dez. 2007" dort stehen sollte. --32X 17:24, 3. Mär. 2009 (CET)Beantworten

Silbentrennung

Zu diesem Problem gibt es ein Ticket.

Der Textsatz [im PDF] nutzt keine Silbentrennung, wie beim Buchdruck gebräuchlich. Durch den Blocksatz kommt es daher zu unruhigen Seiten und teilweise großen Lücken zwischen einzelnen Wörtern.

Automatische Silbentrennung ist momentan mit dem von uns verwendeten PDF Toolkit nicht möglich. -- Volker.haas 12:17, 26. Feb. 2009 (CET)Beantworten
Vorschlag: Keinen Blocksatz verwenden im Textsatz, Flattersatz ist in solchen Fällen besser zu lesen.
Mein Vorschlag: wenn Euer PDF-Toolkit bedingte Bindestriche ­ richtig anzeigt, könntet Ihr ein unabhängiges Silbentrennungstool als PräPostprozessor einsetzen. (Der Silbentrenner, wenn er denn gut ist, könnte gleichzeitig das Ligaturproblem lösen.) — Falk Sprichzumir … 12:34, 10. Jun. 2009 (CEST)Beantworten
Guter Idee. Bedingte Bindestriche werden in der PDF-Version anscheinend leider (noch) nicht interpretiert, wie beim Artikel Weiches Trennzeichen zu sehen ist. --Fomafix 12:43, 10. Jun. 2009 (CEST)Beantworten
Ok, das hätte ich natürlich selber überprüfen können.^^ Vielleicht in der Zukunft … — Falk Sprichzumir … 17:40, 15. Jun. 2009 (CEST)Beantworten

Ligaturen

Aufgrund fehlender Ligaturen [im PDF] wirkt das Schriftbild teils etwas unruhig, da die einzelnen Buchstaben nicht zusammengezogen werden.

Fehler in der PDF-Erstellung bei Aufzählungen

Dieses Problem sollte nach der nächsten Aktualisierung der Software behoben sein.

Beim Erstellen der PDF-Version des Wikipediaartikels zum Thema Fehlerrechnung [3] ist mir ein kleiner Fehler aufgefallen. Bei der Aufzählung innerhalb der Stichpunkte wird in der PDF die Zahl nicht hochgezählt. Entgegen der Online-Version steht in der PDF dann immer nur: 1. dfhsfghsd 1.dklfjhdslf 1.ldfhigsdf usw.

Das Problem ist bekannt. Wir sind gerade dabei den Parser (teilweise) neu zu entwickeln. In der neuen Version tritt der Fehler nicht mehr auf. Allerdings kann es noch ein klein wenig dauern bis der neue Parser fertig entwickelt und getestet ist. -- Volker.haas 12:14, 26. Feb. 2009 (CET)Beantworten

Ansonsten Respekt für die tolle Arbeit. Ich lese mir jetzt sehr oft lange Wikipediaartikel als PDF durch. Gegenüber der Druckversionausgaben ist das ein großer Fortschritt.

Dieser Abschnitt kann archiviert werden. Volker.haas 15:25, 17. Jul. 2009 (CEST)

Zwischentitel nach ; am Zeilenanfang

Titel
Das ist ein Beispiel.

Wäre es möglich, dass Zwischentitel, die mit dem Zeichen ; am Zeilenbeginn eingeleitet werden, beim Seitenumbruch nicht vom nachfolgenden Absatz getrennt werden? --Summ 14:04, 26. Feb. 2009 (CET)Beantworten

IMHO handelt es sich dabei nicht um einen Zwischentitel – bzw. um einen falsch formatierten Zwischentitel. Zwischenüberschriften werden mit Gleichheitszeichen erstellt. Mit Semikolon am Zeilenanfang erstellt mal eine "Definitionsliste". Siehe Hilfe:Textgestaltung. Nach eine Zeile mit Semikolon gehört eigentlich eine Zeile mit Doppelpunkt am Anfang. Wäre interessant zu erfahren, ob es dazwischen auch zu einem Seitenumbruch kommen kann. --Emkaer 09:25, 11. Apr. 2009 (CEST)Beantworten

Bearbeitungsansicht

Wie gelangt man zur Bearbeitungsansicht, wie in Buchfunktion/für Experten dargestellt ist? --Morten 16:04, 26. Feb. 2009 (CET)Beantworten

Wenn du das Bearbeiten von gespeicherten Büchern meinst:
  • Buch speichern (oder auf die Seite eines gespeicherten Buchs navigieren)
  • "Seite bearbeiten" klicken
Wenn du etwas anderes meintes, habe ich es nicht verstanden. --he!ko 17:07, 26. Feb. 2009 (CET)Beantworten
Danke. Genau das hab ich gemeint. Ich dachte man könne das Buch auch ohne Speichern bearbeiten. --Morten 17:15, 26. Feb. 2009 (CET)Beantworten
Dieser Abschnitt kann archiviert werden. Volker.haas 15:26, 17. Jul. 2009 (CEST)

Infoboxen

Zu diesem Problem gibt es ein Ticket.
Betrifft PDF-Version

Gerade erreichte mich (nach recht langer Lieferzeit) "mein" Buch (Thema Öland). Ich bin begeistert! Was mir auffällt ist, dass die Infoboxen zu den Orten nicht umgesetzt werden. Optisch möglicherweise zwar ein Gewinn, allerdings gehen zentralen Informationen (Einwohnerzahlen) damit verloren, falls sie nicht auch noch im Fließtext enthalten waren.--Olaf2 10:00, 27. Feb. 2009 (CET)Beantworten

Katastrophaler ist es bei den Infoboxen Osttimors. Bei der Geographie Osttimors. Die dort eingebundenen Karten und Bilder werden gar nicht oder unterschiedlich dargestellt. Schade. --JPF just another user 20:25, 27. Feb. 2009 (CET)Beantworten
Ach ja, gleiches gilt für Bilder die mit "left" neben die Tabelle oder neben ein anderes Foto gestellt wurden. --JPF just another user 20:28, 27. Feb. 2009 (CET)Beantworten
Du redest nicht von gedruckten Büchern wie Olaf2, sondern von den PDFs, oder? Ich konnte die Probleme in der PDF Version nachvollziehen. In den gedruckten Büchern sieht alles in Ordnung aus. --he!ko 10:54, 28. Feb. 2009 (CET)Beantworten
Hallo, kannst du einen konkreten Artikel nennen? Ich hatte es mit Mörbylånga (Gemeinde) probiert und die Infobox war sowohl im PDF als auch in der Vorschau bei PediaPress zu sehen. Manche Vorlagen sind ja auch der Kategorie:Vom Druck ausschließen zugeordnet, evtl. liegt es daran. --he!ko 20:29, 27. Feb. 2009 (CET)Beantworten
Zum Beispiel Aileu (Distrikt) oder als Beispiel für zwei Photos nebeneinander: Die Bilder von Premier und Präsident nebeneinander in Osttimor. --JPF just another user 20:53, 27. Feb. 2009 (CET)Beantworten
Kann ich im PDF nachvollziehen, aber nicht in gedruckten Büchern. --he!ko 10:54, 28. Feb. 2009 (CET)Beantworten
Es betrifft im Buch sämtliche dort aufgeführte Orte, also zum Beispiel auch Borgholm etc. Allerdings liegt die Buchbestellung sicherlich zwei bis drei Wochen zurück.--Olaf2 13:18, 1. Mär. 2009 (CET)Beantworten
Seltsam. Eventuell war diese Infobox (oder Infoboxen generell) zu diesem Zeitpunkt "vom druck ausgeschlossen". Jetzt geht es[4], sieht aber nicht schön aus, da die Vorlage:Positionskarte+ in der Kategorie Kategorie:Vom Druck ausschließen ist. Ich kümmere mich ... --he!ko 20:59, 1. Mär. 2009 (CET)Beantworten

Daß die Positionskarten verschwinden, mag ich noch verstehen, aber warum verschwinden die beiden Distriktkarten auch, die ganz normale PNG-Bilder sind? z.B. Cristo Rei (Subdistrikt) --JPF just another user 22:56, 3. Mär. 2009 (CET)Beantworten

Unterschiede zwischen PDF und ODT

Ich hatte mir einmal den Artikel Spremberg mittels Buchfunktion angsehen. Dabei sind mir beim ODT und PDF mehrere Unterschiede aufgefallen (nutzt ihr etwa unterschiedliche Parser?):

  • Während im PDF die nichtangezeigte Bildbeschreibung des Wappens (HTML: Tooltip) in der Infobox ebenfalls nicht angezeigt wurde, wurde sie im ODT unnötigerweise angezeigt.
  • Im Abschnitt Geschichte steht das zweite Bild vor dem dritten Absatz, wird im ODT jedoch vor den zweiten Absatz gestellt, zudem sind beide Bilder unerklärlicherweise links positioniert. Im PDF sieht das deutlich besser aus.
  • Der Abschnitt Spremberg#Nachbargemeinden wird im PDF (nicht aber im ODT) unerklärlicherweise auf eine neue Seite gesetzt, obwohl auf der alten noch ausreichend Platz zur Verfüng steht.

Druckt ihr eigentlich auch nachbereitete ODTs? --32X 17:35, 3. Mär. 2009 (CET)Beantworten

Wir verwenden keine unterschiedlichen Parser. Der Parse-Tree wird aber von unterschiedlichen Programmen in andere Ausgangsformate gewandelt, daher kann es tw. zu deutlichen Abweichungen kommen. Das ODT Dokument kann ja glücklicherweise bearbeitet werden, weshalb nicht sonderlich viel Aufwand in eine perfekte Darstellung gesteckt wurde. Der Quellcode ist aber übersichtlich und die meisten Verbesserungen sind wohl über Styles möglich. Wir würden uns freuen, wenn sich jemand findet, der den ODT-Export weiter verbessert (gilt natürlich auch für den Rest der Software). Den Druck von nachbereiteten PDFs bieten wir nicht an. Die Druckvorlage für gedruckte Bücher wird übrigens wiederum von einer anderen, auf den Buchdruck spezialisierten, Software erstellt, so dass sich dieses in der Regel auch vom PDF im Wiki unterscheidet. Im Zweifel einfach die Vorschau auf der Website betrachten. --he!ko 17:58, 3. Mär. 2009 (CET)Beantworten

EPUB

Habe gerade gelesen, dass es für E-Books einen offenen Standard gibt. Keine Ahnung ob das eine sinnvolle Erweiterung wäre. --Goldzahn 05:18, 4. Mär. 2009 (CET)Beantworten

Infoboxen-Workaround?

Zu diesem Problem gibt es ein Ticket.

Gibt es eigentlich irgendwo schon eine Infobox oder eine spezielle Printversion einer solchen, die tatsächlich als Infobox dargestellt wird? Oder irgend einen Workaround für das Problem? --GDK Δ 17:12, 4. Mär. 2009 (CET)Beantworten

Ein Anwendungsfall gibt es mit der Vorlage:Infobox Forschungsreaktor/Druck, hilfreich ist der Kommentar, der beim erstellen gesetzt wurde. Der Umherirrende 17:58, 4. Mär. 2009 (CET)Beantworten
Gut, diese Printversion zeigt zumindest das Bild, aber sie generiert keine InfoBox. Eine nach rechts gefloatede Tabelle von ca. 50% Seitenbreite scheint nicht möglich zu sein, oder? --GDK Δ 18:10, 4. Mär. 2009 (CET)Beantworten
Dazu kann ich nichts sagen, aber soweit ich das gelesen habe, wird jede Tabelle auf die gesamte Seitenbreite gebracht, sodass man keine Tabelle am rechten Rand hinbekommt. Der Umherirrende 18:16, 4. Mär. 2009 (CET)Beantworten
Mit "tatsächlich als Infobox dargestellt" meinst du "float right", oder? Das ist leider nicht ganz einfach, wenn so eine Box über mehrere Seiten geht (keine Scrollbars im Buch). Wir denken aber intensiv über eine Lösung nach. Es gibt hierzu auch ein ticket. --he!ko 10:14, 5. Mär. 2009 (CET)Beantworten
Da inzwischen ext. Links an Ort und Stelle ausgeschrieben werden (geht das auch optional?), werden Infoboxen, die ja gerade als bequeme Linksammlungen verwendet werden, ohnehin aufgebläht. Eine Zusammenquetschung an den Rand erscheint da fast widersinnig. -- Ayacop 10:40, 19. Mär. 2009 (CET)Beantworten

Tabellen und ODT

Das ist echt noch ziemlicher Murks. Während eine Druckversion einer Infobox (also einer eingebundenen Vorlage) im PDF einigermaßen vernünftig aussieht, kommt bei ODT nur eine völlig unsinnige Vermengung und Überlagerung von Zellen und deren Inhalt heraus. Da OpenOffice den PDF-Export unterstützt wäre es m.E. sinnvoll, bevorzugt die Generierung von ODT zu verbessern. Ein brauchbares ODT-Dokument kann man in der Applikation nach eigenen Vorstellungen formatieren und dann exportieren. Hier wird viel zu einseitig an der Verbesserung der PDF-Generierung gearbeitet. Überlassen wir das doch der Textverarbeitung von OpenOffice und sorgen wir für korrekte ODT-Dokumente. Cäsium137 (D.) 22:47, 6. Mär. 2009 (CET)Beantworten

Irgendwie gefällt mir der Tonfall nicht ("Das ist echt ein ziemlicher Murks") Bin selbst nur "Kunde", keiner der (vielen!) freiwilligen Wiki-Entwickler. Wenn ich aber einer wäre, würde ich mindestens eine konstruktivere Formulierung der Kritik erwarten - und natürlich ein *konkretes* Beispiel, wo etwas schiefging ... --Wikibernhard 10:40, 7. Mär. 2009 (CET)Beantworten
Das Thema wurde schon mal hier behandelt. Kurze Antwort: Du hast vollkommen Recht, dass der ODT-Export besser sein könnte. Anderseits ist dieser bearbeitbar, so dass sich die Nutzer bei Darstellungsproblemen recht gut selbst helfen können. --he!ko 20:20, 11. Mär. 2009 (CET)Beantworten
Zu diesem Problem gibt es ein Ticket.

In Stadtartikeln oder bei Unternehmen kommt es vor, das der Weblink in der Infobox und im Abschnitt Weblinks auftaucht. Die identischen Links könnte man zusammenfassen. Gesehen bei den Referenzen von Astana Der Umherirrende 12:05, 7. Mär. 2009 (CET)Beantworten

PDF-Version von Vorlagendokumentationen mit Vorlage:Dokumentation

Das erzeugen einer PDF-Version einer Vorlagenseite, welche Vorlage:Dokumentation verwendet, ergibt eine leere Seite (Beispiel). Den Vorteil beim ausdrucken von Vorlagendokumentationen sehe ich darin, das man so das "Handbuch" sich neben den PC legen kann und nicht immer das Fenster wechseln muss, wenn man eine Vorlage öfters verwendet und die Parameter füllen möchte. Vorlagendokumentation die nicht Vorlage:Dokumentation verwenden, werden richtig angezeigt (Beispiel). Mögliche Ursache: Die Variable SUBJECTPAGENAME könnte Probleme bereiten, da im Vorlagennamensraum keine "echten" Unterseiten (im Sinne von MediaWiki) möglich sind, in diesem Fall liefert die Variable das gleiche ergebnis wie PAGENAME. Der Umherirrende 13:07, 7. Mär. 2009 (CET)Beantworten


Bildlizenzen nicht eingebunden?

verschoben von Hilfe Diskussion:Buchfunktion --Frank Schulenburg 00:15, 11. Mär. 2009 (CET)Beantworten

Ich habe auf dem Hannover-Treffen einige Exemplare gesehen. Die Bildurheber und -lizenzen waren nirgends eingebunden. Für die private Nutzung kein Problem, aber beim Verteilen gehen die Anwender ein Rechtsrisiko ein. Bis zu einer Nachbesserung sollten wir die Buchfunktion hier nicht ohne Warnhinweis anbieten. Mit "speichern und teilen" fordern wir geradezu zum Lizenzverstoß auf. --Martina Nolte Disk. 00:09, 11. Mär. 2009 (CET) Ergänzung --00:11, 11. Mär. 2009 (CET)Beantworten

Das Problem wurde schon weiter oben unter Lizenzen angesprochen. Einen Warnhinweis habe ich heute eingebaut, siehe Quelle der Lizenzinformationen im PDF anpassbar. — Raymond Disk. Bew. 09:28, 11. Mär. 2009 (CET)Beantworten
Martina, wo hast du dies gesehen? In gedruckten Büchern oder im (gedrucktne) PDF? In gedruckten Büchern, sollte das auf keinen Fall vorkommen (im PDF künftig auch nicht mehr). Es wäre nett, wenn du mir helfen könntest das Problem nachzuvollziehen. Ggf. den Besitzer des Buches bitten sich bei mir zu melden. Danke! --he!ko 20:11, 11. Mär. 2009 (CET)Beantworten
Das waren PDFs, die ich für den Hannover-CeBIT-Stammtisch vorbereitet hatte. Grüße, -- Ukko 00:08, 12. Mär. 2009 (CET)Beantworten

Zunächst mal Gratulation zu den zahlreichen Verbesserungen, weshalb es sich bei meinen Vorschlägen lediglich um ästhetische Kleinigkeiten handelt. Jedenfalls möchte ich die Buchfunktion mittlerweile nicht mehr missen. Beim Ausdruck des Epiktet-Artikels ist mir aufgefallen, dass Links auf Commons oder Wikisource, sofern sie mit Aufzählungszeichen kombiniert sind, fehlerhaft dargestellt werden. Zudem kommt es im unteren Teil zu einem Bruch, sodass die folgenden Punkte weiter nach innen versetzt aufgelistet sind. Schließlich stellt die PDF-Version bei einem Link die Internetadresse dar, ohne diese, wie sonst üblich, in die Anmerkungen zu verschieben. Schöne Grüße, -- Anamnesis 18:21, 11. Mär. 2009 (CET)Beantworten

Danke für den Hinweis. Die Probleme sind bekannt und hoffentlich bald behoben. --he!ko 20:39, 11. Mär. 2009 (CET)Beantworten

Neue Seite für die Lizenzproblematik

Hilfe:Buchfunktion/Lizenzprobleme -- Rosentod 20:29, 11. Mär. 2009 (CET)Beantworten

Buchvariante ohne Quellen und Autoren?

Hallo, vielen Dank für die Buchbestellfunktion - wunderschöne Möglichkeit, sich einen persönlichen Reiseführer für den nächsten Urlaub zusammenzubasteln. Was mich noch zögern macht, ist aber, dass rund ein Viertel des Buchs aus den ziemlich überflüssigen Quellenangaben ("References") und Autorennennungen bestehen würde - das ist dann doch arg viel unnötiger Ballast im Rucksack (die en-Wikipedia ist ja deutlich quellenlastiger als .de). Gibt es eine Möglichkeit, diese Elemente bei der Buchbestellung abzuwählen? -- Rudolph Buch 20:55, 17. Mär. 2009 (CET)Beantworten

Bücher ohne Quellen sind momentan leider nicht möglich. Allerdings haben wir vor kurzem die Schriftgröße bei den Quellenangaben verkleinert - das sollte das Problem etwas abschwächen. Falls du mir einen Link zu einer gespeicherten Kollektion gibst, kann ich mir mal anschauen wie viele Seiten die Quellenangaben im Vergleich zum Rest des Buches ausmachen würden. Das sollte aber vermutlich deutlich unter 1/4 liegen - ein derartiges mieses Artikel/Quellenverhältnis habe ich nämlich noch nie beobachtet. -- Volker.haas 10:36, 18. Mär. 2009 (CET)Beantworten
Für den "Link zur Kollektion" bin ich technisch noch nicht fit genug - aber ich hab nachgezählt: Bei der englischsprachigen Version von New York City sind es 26 Textseiten plus 20 Seiten Anhang, bei Washington D.C. 20 Textseiten plus 15 Seiten Anhang, bei Philadelphia 20 Textseiten mit 5 Seiten Anhang. Mir ist schon klar, dass ich da mit NYC und D.C. zwei extreme Beispiele erwischt habe, aber gerade die "großen" (und inhaltlich ganz hervorragenden) Städte- und Regionenartikel wären natürlich perfekte Reisebegleiter, wenn man die Doktorarbeits-Anhänge nicht mitschleppen müsste :-) -- Rudolph Buch 11:53, 18. Mär. 2009 (CET)Beantworten
(Hab´s jetzt aber - um hier nicht nur rumzujammern - einfach mal bestellt: Ist für mich also kein dringendes Problem mehr) -- Rudolph Buch 13:51, 18. Mär. 2009 (CET)Beantworten
Ist aber ein interessantes Problem welches weiter verfolgt werden sollte Inge 19:14, 18. Mär. 2009 (CET)Beantworten
Könnte man die per <references/> erzeugten Belege nicht stattdessen als Fußnoten auf die einzelnen Seiten setzen? Weil Quelle und Textstelle im Buch nicht verlinkt sind, ist es etwas mühselig, immer die Seite mit dem jeweiligen Beleg suchen zu müssen. --Morten 21:38, 18. Mär. 2009 (CET)Beantworten
Es wäre auch eine Möglichkeit den Benutzer vorher zu fragen ob er die Quellen mit abgedruckt haben möchte oder nicht--Inge 23:33, 18. Mär. 2009 (CET)Beantworten

bestelltes Buch bei PediaPress, Erfahrungsbericht

Ich habe mir ein A5 Buch mit etwa 600 Seiten zum Thema Schlesien zusammengestellt und bin sehr begeistert. Es hat einen glänzenden Einband. Ich habe einzelne Artikel gewählt, Einleitung eingebunden und Kategorien mit teilweise doppelten Artikelvorkommen hinzugefügt. Das Softcoverbuch macht einen soliden Eindruck, hat nochmal explizit ein Erstellungsdatum, Bilder in Grautönen werden schön angeordnet und mit Beschriftung versehen sowie durchnummeriert.

Das Buch wird in der UK gedruckt. Das durchnummerierte Bilderverzeichnis enthält wie auch das Autorenverzeichnis einen Permanentlink der verwendeten Version, die verwendete Lizenz (GFDL bei Texten wird ohne Versionsnummer genannt) sowie eine Autorenliste. Beide befinden sich im Anhang. Es gibt ein generiertes Stichwortverzeichnis, welches einen guten Eindruck machte, die Anwendbarkeit konnte ich leider noch nicht testen.

Die Lieferzeit von 3 Wochen passt, der Preis ist super. Über Verarbeitungsqualität in punkto Benutzung kann ich dato nichts sagen. Imposant, wie sich in dem Falle etwa 150 Artikel auf 600 Seiten verteilen und wie die Wirkung des Werkts ist, wenn man immer nur A4 gedruckt hat.

Folgende Fragen und Verbesserungsgedanken für Extension/Buchproduktion habe ich:

  • Wo kann ich transparent sehen, dass die 10% Spende bei der WMF eingegangen ist?
  • Bilder sollten auf Wunsch nur einmalig einbindbar sein und bei erneuten Vorkommen auf die jeweilige eine Seite verwiesen werden können.
  • Ein Aufpreis für farbige Bilder sollte angeboten werden (ich weiß, wird teuer :) ).
  • Wikilinks auf im Buch nicht eingebundene Artikel (die im Netz vorhanden sind) sollten bei Bedarf markiert werden können (sich aber von den vorhandenen abheben).
  • Eine Liste der fehlenden Artikel (als Wikilink da, nicht aber in Druck eingeschlossen) sollte generierbar sein (mit Mengenangabe), um den Inhalt vom Folgebuch entscheidbar zu machen.
  • Könnte man eine Funktion anbieten (vielleicht auch PediaPress fremd), welche Artikel auflistet, die in einem Einführungsartikel vorhanden sind, nicht aber in angegebenen Kategorien auftauchen. Beispiel: Artikel Schlesien ist Einleitungsartikel, dann wird Kategorie Schlesien hinzugefügt. Jetzt will ich sehen, welche Artikel in Artikel Schlesien verwiesen werden und in der Kategorie fehlen.

Vielen Dank, begeistert, Conny 11:32, 24. Mär. 2009 (CET).Beantworten

Schoen, dass das Buch gefallen hat :) Zu den Fragen:
  • Statistiken sind geplant, siehe unten. Die 10% an die Foundation sind keine Spende, sondern fester Vertragsbestandteil, der entsprechend auch fuer die Foundation ueberpruefbar ist.
  • Die einmalige Einbindung von Bildern, wird kuenftig evtl. konfigurierbar sein.
  • Um Farbdruck bemuehen wir uns. Die Buecher wuerden aber tatsaechlich etwa das doppelte kosten.
  • Zu den letzten drei Punkte: groessere Artikel enthalten gerne mal ueber 1000 links. Ich bin mir daher nicht sicher, ob solch eine Funktion Sinn macht. Wir planen aber eine Dossier-Funktion zu implementieren, welche mit statistischen Verfahren Vorschlage generiert, welche Artikel eine Kollektion sinnvoll ergaenzen wuerden. Ich denke, das geht in die gleiche Richtung. --he!ko 00:29, 31. Mär. 2009 (CEST)Beantworten

PDF wird nicht erstellt

Ich habe ein Wiki Buch zusammengestellt mit 219 Seiten über Knorpelfische. Kann es als .odt jedoch nicht als PDF laden, der Server bleibt jedes Mal bei 77% oder 79 % hängen: Anzeige: Fortschritt: 77 % Status: Layout wird erstellt Dann Fehlermeldung: Auf dem Render-Server ist ein Fehler aufgetreten: Collection/article could not be rendered

Habe es mehrere Male an verschiedenen Tagen versucht, ohne Erfolg. Das Buch zu splitten hat ebenfalls nichts gebracht, derselbe Fehler an derselben Stelle ist wieder aufgetaucht. Mache ich da was falsch? Fortunaebooks 10:19, 25. Mär. 2009 (CET)

Das gleiche bei mir. Da sich der Renderer offensichtlich an einem bestimmten Artikel verschluckt: Wäre es möglich, standardmäßig ein Log-Protokoll auszugeben, um in einer Art Liste nachzuvollziehen, wo der Renderer ausgestiegen ist? --RainerWiese 11:54, 26. Mär. 2009 (CET)Beantworten

Könntet ihr bitte die Kollektionen die Probleme bereiten abspeichern und den Link hier posten. Dann schaue ich mir das Problem an. Log Ausgaben sind ein schwieriges Thema. Wir haben uns dagegen entschieden im Fehlerfall den Fehler auszugeben, da die Software dann so abgestürzt ist, dass wir keine "ordentliche" Fehlermeldung ausgeben könnten. Die Ausgaben die wir anzeigen könnten würden bei der Identifizierung des Problems kaum helfen. -- Volker.haas 12:05, 27. Mär. 2009 (CET)Beantworten
Meine Kollektion findest du unter [[5]]. OK, das mit dem Log war einfach eine Idee, weil er ja auch beim Erstellen immer seinen Status ausgibt. Bei mir scheint er wohl bei einem Artikel nach dem Artikel "Guaraná" abzustürzen; vielleicht hilft das beim Suchen... Und ansonsten: vielen Dank für die Buchfunktion, ist wirklich eine tolle Sache. Und automatisch Wikimedia zu unterstützen find ich auch richtig klasse! --RainerWiese 15:07, 27. Mär. 2009 (CET)Beantworten
Nach dem neuesten Update sollte deine Kollektion problemlos gerendert werden können. Das Update sollte in den nächsten paar Tagen in der Wikipedia live sein. -- Volker.haas 16:03, 27. Mär. 2009 (CET)Beantworten
Danke dir,Volker! Habe es jetzt auch noch einmal nachvollzugen und festgestellt, dass sich der Renderer offensichtlich an Artikeln aufhängt, deren Namen auf einen Buchstaben mit einem Akut [[6]] endet. Vielleicht hilft das dir (der es jedoch offensichtlich schon nachvollzogen hat) und anderen mit dem gleichen Problem wie ich weiter... --RainerWiese 19:37, 27. Mär. 2009 (CET)Beantworten

Ich bekam bei 3 von 5 Versuchen den folgenden Fehler (mehrfach, also vermutlich reproduzierbar):

Auf dem Render-Server ist ein Fehler aufgetreten: Collection/article could not be rendered 
Betrifft: 
Wikipedia:Bücher/Ostfriesische Inseln und Wattenmeer
Wikipedia:Bücher/Das Einmaleins der Drogen
Wikipedia:Bücher/Die deutschen Nordseeinseln

--WernerPopken 11:34, 6. Apr. 2009 (CEST)Beantworten

Ich habe dasselbe Problem mit Wikipedia:Bücher/Katholische Kirche in Sizilien. In der jetzigen Version geht es, aber sobald ich den Artikel Bistum Cefalù hinzufüge (siehe diese Version), gibt es den Absturz. Zur Abkürzung habe ich mal nur die Kirchenprovinz Palermo herauskopiert nach Benutzer:Bjs/Bücher/Katholische Kirche in Sizilien-2. Wieder der Akzent (diesmal gravis)? Ist aber merkwürdig, weil auch Kathedrale von Cefalù und Francesco Miccichè in der funktionierenden Version enthalten sind. --Bjs (Diskussion) 11:20, 9. Apr. 2009 (CEST)Beantworten
P.S. Hänger in Benutzer:Bjs/Bücher/Katholische Kirche in Sizilien-2 bei Fortschritt: 82 % Status: Layout wird erstellt(Wikiseite: Bistum Cefalù).
Funktioniert jetzt auch mit Bistum Cefalù --Bjs (Diskussion) 10:19, 11. Mai 2009 (CEST)Beantworten

Bei einem Buch, erstellt aus der Kategorie:Programmiersprache tritt der Fehler auch auf. --193.158.17.136 10:29, 13. Mai 2009 (CEST)Beantworten

Letzte Änderungen anzeigen

Besteht die Möglichkeit die Änderungen der in der Collection befindlichen Artikel bis zu einem bestimmten Termin bzw. bis zum letzten gesicherten Status (ähnlich einer Versionierung eines Berichts) zu dokumentieren? Martinshorn 22:00, 25. Mär. 2009 (CET)Beantworten

Nein, das ist zur Zeit nicht möglich. Jbeigel 13:30, 27. Mär. 2009 (CET)Beantworten
Die Seiten der gespeicherten Bücher enthalten ja die Links zu den Artikeln, dann kann man doch Spezial:Änderungen an verlinkten Seiten wunderbar dafür gebrauchen. Der Umherirrende 22:30, 19. Jun. 2009 (CEST)Beantworten

Statistikanfrage

Zu diesem Problem gibt es ein Ticket.

Hallo PediaPress Team,
bitte legt im Rahmen höchsmöglicher Transparenz eine Statistik vor (am besten Logfiledaten), welche PDFs wann, wie oft erstellt werden. Eine Zuordnung zu den Detailseiten der Buchzustellungen wäre günstig, ist aber sicherlich aufwendig.

Liebe Grüße, Conny 12:44, 26. Mär. 2009 (CET).Beantworten

Bitte die Anonymität der Leser wahren. Anonyme Statistiken wie http://stats.grok.se/de/200903/Hilfe:Buchfunktion/Feedback_zur_Buchfunktion sind aber in Ordnung. --Fomafix 23:37, 26. Mär. 2009 (CET)Beantworten

Mal was ganz abwegiges ...

Moin!

Ich fange gerade mit meiner Dissertation an und spiele allen Ernstes mit dem Gedanken, das Ding nicht mit Word (das auf keinen Fall) oder OpenOffice oder TeX oder sonstwas zu schreiben, sondern stattdessen direkt mit MediaWiki ins Netz zu stellen (und zu erstellen). Der Vorteil wäre für mich einfach der, dass ich dann von überall Zugriff darauf hätte, Vorlagen und Datenbanken einbinden könnte; dpl und sonstige spaßige Extensions nutzen könnte, etc. und einfach mehr Ahnung von HTML und CSS usw. habe als von Textverarbeitungs-Software. Natürlich müsste ich das aus rechtlichen Gründen so machen, dass nur Administartoren (erstmal nur mein Doktorvater und ich) Inhalte einsehen könnten - das wäre aber recht einfach machbar, denke ich. Hilfreich wäre nun eine Einschätzung, ob das Sinn macht - insbesondere im Hinblick auf die Buchfunktion. Bedenken habe ich ein wenig wegen

  • Silbentrennung
  • Spationierung/Autokerning
  • Seitenzahlen, Fußnoten, Register, usw.
  • Skalierbare Vektorgraphiken (die will ich in jedem Fall verwenden - und zwar nicht als PNG gerendert - kommt die Buchfunktion damit klar?)
  • Autoren- und Lizenz-Gedöhnse (das brauche ich nämlich nicht, da ich ja der einzige Autor wäre)
  • mir fällt bestimmt bald noch mehr ein ...

Was denkt ihr? Ist das totaler Schwachsinn, oder wäre das machbar? Würde mir einfach mehr Spaß machen in und mit einem Wiki zu arbeiten, und lehrreicher wäre es obendrein, schätze ich.

Grüße,

--MuWi 14:19, 28. Mär. 2009 (CET)Beantworten

Wie hier bereits öfter angesprochen wurde, bekommst Du mit LaTeX in vielerlei Hinsicht (insbesondere beim Textsatz) ein erheblich besseres Ergebnis. Ich habe meine Dissertation mit LaTeX geschrieben und bin sehr zufrieden. Bei Deinen Vorkenntnissen kannst Du Dich schnell und problemlos in LaTeX einarbeiten. -- Rosentod 15:32, 28. Mär. 2009 (CET)Beantworten
Danke für die schnelle Antwort ... dacht's mir schon fast. Hätte mehr Freude an PHP-Spielereien, aber was soll's --MuWi 15:51, 28. Mär. 2009 (CET)Beantworten
Hm ... was würde denn passieren, wenn man die Buchfunktion gemeinsam mit WikiTeX verwendet? --MuWi 12:58, 29. Mär. 2009 (CEST)Beantworten
Open Document hat ja einen recht guten PDF-Export und bietet den Vorteil, dass du dem Dokument am Ende noch einen Feinschliff geben kannst. Silbentrennung (bei richtiger Spracheinstellung), Spationierung, Seitenzahlen, Fussnoten, Register sollte OO auch koennen. Hoeheraufloesende Grafiken kannst du am Ende manuell einbindnen, wenn es nicht auf anhieb klappt. Autoren und Lizenzen koenntest du auch selbst editieren. Ich faende es interessant, diesen Ansatz mal auszuprobiert zu sehen. Insbesondere kannst du bei Zitaten aus der Wikipedia direkt das Markup nutzen ;-) --he!ko 16:46, 30. Mär. 2009 (CEST)Beantworten
Tatsächlich tendiere ich mehr und mehr in diese Richtung ... als Musikwissenschaftler hat man ja ständig das Problem mit Noten im Fließtext (Notensatzprogram -> als Bild exportieren -> Bildbearbeitungsprogram -> Exportieren -> Textverarbeitungsprogram -> als PDF exportieren ... suboptimal), da wäre LilyPond mit WikiTeX eine echte Erleichterung und per dpl könnte ich sogar nach bestimmten Noten-Kombinationen suchen und mir das Ergebnis dynamisch anzeigen lassen *boah* Auch braucht eine Doktoarbeit ja eine gewisse Zeit und ich habe die Hoffnung, dass bis dahin (hab' mir zwei Jahre vorgenommen) auch die ein oder andere Kinderkrankheit der Buchfunktion behoben sein wird ... --MuWi 17:34, 30. Mär. 2009 (CEST)Beantworten

"poem" wird nicht übernommen

Zu diesem Problem gibt es ein Ticket.

Text, der von <poem> </poem> eingeschlossen ist, wird nicht ins PDF übernommen. Herausgefunden am Artikel Armin Müller (Offizier). --Allesmüller 17:05, 5. Apr. 2009 (CEST)Beantworten

PDF-Titel "anonymous"

Evince zeigt als PDF-Titel "anonymous" an. Das ist ziemlich hässlich und nutzlos und sollte besser durch den Artikelnamen oder irgend eine sinnvolle Information ersetzt werden. Beispiel: http://de.wikipedia.org/wiki/Spezial:Buch/rendering/?return_to=Mitten+im+Leben+(Dokusoap)&collection_id=dd4490d2dab399ce&writer=rl&is_cached=1

Zusatzfrage: könte man die Links zu den PDFs vielleicht etwas schöner gestalten? http://de.wikipedia.org/w/index.php?title=Spezial:Buch/download/&collection_id=dd4490d2dab399ce&writer=rl&return_to=Mitten+im+Leben+%28Dokusoap%29 könnte doch z. B. http://de.wikipedia.org/w/Spezial:Buch/Mitten_im_Leben_(Dokusoap)/Version=58742709 oder so heißen, bei Artikel sind die URLs doch auch sehr schön, warum nicht für die PDFs? --Spuerhund 16:29, 6. Apr. 2009 (CEST)Beantworten

Galerien werden nicht korrekt dargestellt

Zu diesem Problem gibt es ein Ticket.

Bei mit <gallery> erzeugten Galerien treten in PDFs zwei Probleme auf (z.B. Lepsius-I-Pyramide):

Die Lösung der Galerie-Darstellung bei Pediapress sieht da deutlich besser aus. --GDK Δ 11:30, 7. Apr. 2009 (CEST)Beantworten

Hurenkinder, Schusterjungen und andere PDF-Formatierungs-Hinweise

Werden Hurenkinder und Schusterjungen eigentlich irgendwie von der Buchfunktion ausgeschlossen??? Ich habe vom Artikel Hitler in dieser Version eine PDF-Version erstellen lassen. Dabei steht auf S. 3 oben nur ein Wort ("üblich."). Ansonsten tritt dieses Problem im Artikel nicht auf. Oder beruht das hier auf sonderbarem Quelltext?

Leider ist es nicht möglich Hurenkinder und Schusterjungen immer zu vermeiden. Das obige Beispiel ist nicht so schön, leider kann ich da aber nix machen. -- Volker.haas 13:59, 17. Apr. 2009 (CEST)Beantworten

In anderen Fällen wird m.E. zu früh umgebrochen, so dass am Seitenende noch unnötig freier Raum ist (hier auf S. 24). Muss das sein?

Der Umbruch ist in der Tat Absicht: Die nächste Seite beginnt mit einem Bild neben dem Text. Der Umbruch erfolgt, weil das Bild nicht mehr auf die Seite passen würde. -- Volker.haas 13:59, 17. Apr. 2009 (CEST)Beantworten

Noch 2 Hinweise anhand des genannten PDFs: Die Liste der Bearbeiter ist in diesem Fall ja ziemlich extrem. Aber ich finde, dass dort (auf S. 39) statt "Source" "Quelle" stehen müsste, und sowohl das Wort "Quelle" als auch "Bearbeiter" irgendwie hervorgehoben sein sollten. Zumindest fett.

Inzwischen werden die Quellen und Bearbeiter am Ende des PDFs (vor die Lizenz) ausgegeben und nicht mehr nach jedem Artikel. Die Lokalisierung wurde repariert. -- Volker.haas 13:59, 17. Apr. 2009 (CEST)Beantworten

Auf S. 41 beginnt dann die Lizenz. Der Abschnitt sollte mit "Lizenz" überschrieben sein, statt mit "License". Und die Formatierung der Lizenz sollte man sich auch nochmal genau angucken. Da gibt es schlechte Abstände, Zeilenumbrüche, Hervorhebungen ("GNU Free Documentation License" sollte größer sein als ihre Unterabschnitte). Das Lizenz-Kapitel "4." verbraucht viel zuviel Platz. Nach der Überschrift "5. COMBINING DOCUMENTS" (wobei das Leerzeichen nach 5. nicht dargestellt wird) ist ein falscher Seitenumbruch.

Und der letzte Abschnitt "ADDENDUM: How to use this License for your documents", ist der wirklich nötig?

Schöne Grüße --Emkaer 13:28, 16. Apr. 2009 (CEST)Beantworten

Sehr gute Lösung! Aber das war doch bestimmt schon vor meinen Hinweisen in Arbeit, oder?
Ich habe nochmal ein PDF von dieser Version erstellen lassen und mir das am Ende angeschaut. Der Lizenztext ab "License" (immer noch engl.) ist genau 2 Seiten und 2 Zeilen lang. Eine Kürzung der Textgestaltung um weitere 2 Zeilen wäre sehr(!) wünschenswert. Und soviel Leerraum ist da auch noch (gerade bei den eingerückten Stellen). Dann ist es nämlich optimal, wenn man diesen Lizenztext immer auf den 2 letzten Seiten angibt (keine Seitenumbrüche, fixe Seitengestaltung).
Als "Fehler" in der Lizenzdarstellung besteht weiterhin, dass nach den großen Aufzählungspunkten (1., 2., 3., ...) kein Leerzeichen vor den Abschnittsüberschriften dargestellt wird.
Die Seite "Quellen und Autoren der Artikel" ist m.E. eine gute Erfindung! Allerdings ist die Schrift dieser Überschriftszeile vielleicht etwas zu groß? Das sollte sich an Kapitelüberschriften in den Büchern orientieren. Ich habe das gerade nicht überprüft. Jedenfalls wäre es sehr wünschenswert, wenn dieser Teil "Quellen und Autoren der Artikel" im PDF auch als "Lesezeichen" in der Dokumentstruktur auftauchen würde. Dann könnte man direkt dahin springen. Es sollte aber wahrscheinlich ein Lesezeichen einer höheren "Ordnung" sein (eben wie eine Kapitelüberschrift, nicht ein Artikelname). Zu solch einer höheren "Ordnung" gehört m.E. auch der als Lesezeichen bereits verfügbare Abschnitt "License" (am besten lokalisiert ;-) ).
Vielen Dank nochmal für die aufwendige Abarbeitung der Anmerkungen hier! Schöne Grüße --Emkaer 14:45, 17. Apr. 2009 (CEST)Beantworten

Ich weise mal auf (für mich) neue Probleme in einem neuen PDF hin: Aufrüstung der Wehrmacht (PDF).

  • Die Tabelle auf S. 23 (Übersicht über die unterschiedlich ermittelten Rüstungsausgaben des Deutschen Reiches (in Mrd. RM)) sieht übel aus, keine Ahnung warum. Dahinter ist der Abschnitt "Anmerkungen zur Übersicht über die unterschiedlich ermittelten Rüstungsausgaben des Deutschen Reiches", in dem im Artikel speziell ausgezeichnete Anmerkungen extra zu dieser Tabelle stehen, leer.
  • Ebenso verhält es sich mit den anderen von den Einzelnachweisen getrennten "Anmerkungen".
  • Nun sind untereinander die Überschriften "Einzelnachweise", "Anmerkungen" und "Referenzen" zu lesen, wobei unter den ersten beiden gar nicht steht, und "Referenzen auch noch in anderer Schriftart formatiert ist. Also falls das an einer Neuerung liegt (tut es, glaub ich), war es früher besser. (Sinnvoll ist es sicherlich, den Text der Referenzen etwas kleiner zu drucken als den Rest, so wie nun eingeführt.)
  • Die Einzelnachweise sollten, wie es z.B. im Abschnitt "Literatur" auch ist, so formatiert sein, dass der erste Buchstabe eines Einzelnachweises so weit eingerückt ist, wie der erste Buchstabe der folgenden Zeile desselben Einzelnachweises (in Word würde ich das mit Tabulator und hängendem Einzug lösen).
  • Die Umstellung auf das engl. "Article Sources and Contributors" und auf derselben Seite auch "Source" und "Contributors" ist m.E. kein Gewinn. Warum überhaupt "Sources" im Plural? Ist doch nur eine Quelle angegeben.
  • Wünschenswert wäre, wenn z.B. diese Quellenangabe mit einem Link zum Artikel (bzw. zur spez. Version) hinterlegt werden könnte (zum Draufklicken). Dann könnte man auch noch irgendwo einen Link zum aktuellen Artikel anbringen.

Schönen Gruß --Emkaer 15:58, 22. Apr. 2009 (CEST)Beantworten

Schlagwörter

Zunächstmal gefällt mir die Buchfunktion sehr gut, und ich habe schon einige Bücher damit zusammengestellt. Die Schlagwortfunktion finde ich jedoch nicht so ausgereift. Derzeit werden Schlagwörter für die Bücher automatisch vom Bot vergeben. Das führt zu qualitativ sehr unterschiedlichen Ergebnissen.

Das Buch „Politische Gliederung Siziliens“ ist beispielsweise unter Ort in Sizilien, Italienische Provinz, Provinz in Sizilien eingeordnet. Das passt soweit ganz gut. Ebenso passt beispielsweise die Einordnung von „Welterbe Siziliens“ unter Welterbe Siziliens, Ort in Sizilien, Archäologischer Fundplatz in Sizilien.

Das Buch „Normannisches Palermo“ dagegen ist unter Normannisches Bauwerk in Palermo, Kirchengebäude in Palermo und Schloss in Sizilien eingeordnet, aber nicht unter dem ebenfalls existierenden Schlagwort Palermo. Dort findet man dann nur das Buch „Museen in Sizilien“, was aber mit Palermo nur am Rande zu tun hat.

Wäre es nicht möglich, eine benutzerdefinierte Schlagwortvergabe vorzusehen, die beispielsweise in Form einer Vorlage {{Schlagwoerter|Schlagwort1|Schlagwort2|...}} im Header des Buchs eingebunden werden kann und falls vorhanden die automatische Vergabe per Bot überschreibt? Grüße --Bjs (Diskussion) 20:43, 21. Apr. 2009 (CEST)Beantworten

Lange Worte

Worte wie Donaudampfschiffahrtselektrizitätenhauptbetriebswerkbauunterbeamtengesellschaft werden im PDF einfach abgeschnitten. Sie sehr unschön aus, besonders in Titeln. Lässt sich da was machen? -- Zone42 14:16, 23. Apr. 2009 (CEST)Beantworten

Kommentieren und markieren

Hallo, warum sind die erstellten Dokumente so eingestellt, dass man sie nicht kommentieren oder markieren kann? --89.60.207.59 18:51, 30. Apr. 2009 (CEST)Beantworten

Das kann ich nicht nachvollziehen. Mit Okular unter Linux und Preview-App und OS X ging das wunderbar. Welchen PDF Viewer benutzt du? Abgesehen davon, kann ich wohl sowieso nichts machen. Das von uns verwendete PDF Toolkit unterstützt keinerlei Konfiguration von Kommentaren oder Markierung. -- Volker.haas 16:33, 7. Mai 2009 (CEST)Beantworten
Laut Adobe Reader ist Kommentieren nicht zulässig. Mit dem PDF-XChange Viewer geht es zwar, aber dem sind jegliche Beschränkungen egal.--89.60.216.55 18:33, 14. Mai 2009 (CEST)Beantworten

Abschnittswechsel

Zu diesem Problem gibt es ein Ticket.
ausserdem Ticket 604

Zuerst einmal: Danke für die Klasse Arbeit! Das läßt sich schon sehr gut nutzen. Ich hätte allerdings noch zwei Vorschläge:

  • Die Abschnitte werden im Moment ja einfach durch eine kleine Leerzeile erstellt. Ich denke, ein Erstzeileneinschub ohne Leerzeile wäre besser. Das würde auch etwas „hochqualitativer“ aussehen.
  • Im Moment wird ja anscheinend DejaVu Serif benutzt. Es gibt allerdings noch andere freie Schriftarten, z.B. Linux Libertine. Ich fände es gut, wenn man bei der Erstellung eventuell aus einigen Schriftarten, die benutzt werden sollen, auswählen könnte.

Ansonsten: Klasse und weiter so! -- Hellstorm 00:00, 8. Mai 2009 (CEST)Beantworten

Verfügbarkeit PDF Erstellung

Hallo Leute,
ganz ehrlich, wenn wir eine Funktion in der Mediawiki Oberfläche integriert anbieten, dann sollte diese eine hohe Zuverlässigkeit haben.

Die POST-Anfrage an http://pdf1.wikimedia.org:8080/mw-serve/ ist fehlgeschlagen (Empty reply from server). Zurück zur Seite Wikipedia:Hauptseite.

Es sollte sichergestellt sein, das zumindest ein PDF Export zuverlässig klappt, ansonsten kann die Erstellung auf den Toolserver verlagert werden und die prominente Verlinkung ist nicht gerechtfertigt. Das ist aus meiner Sicht absolutes Alphastadium, wenn die grundlegenste Funktionalität nicht dauerhaft verfügbar ist. Ich bitte dabei zu bedenken, dass die Probleme seit 4 Monaten bekannt sind.

Liebe Grüße, Conny 08:55, 8. Mai 2009 (CEST).Beantworten

Auf dem Render-Server ist ein Fehler aufgetreten: traceback Traceback (most recent call last): File "/home/mwlib/py25/lib/python2.5/site-packages/mwlib-0.11.3.dev-py2.5-linux-x86_64.egg/mwlib/apps/render.py", line 182, in __call__ env = self.get_environment() File "/home/mwlib/py25/lib/python2.5/site-packages/mwlib-0.11.3.dev-py2.5-linux-x86_64.egg/mwlib/apps/render.py", line 93, in get_environment env = self.parser.makewiki() File "/home/mwlib/py25/lib/python2.5/site-packages/mwlib-0.11.3.dev-py2.5-linux-x86_64.egg/mwlib/options.py", line 150, in makewiki script_extension=script_extension, File "/home/mwlib/py25/lib/python2.5/site-packages/mwlib-0.11.3.dev-py2.5-linux-x86_64.egg/mwlib/wiki.py", line 268, in makewiki script_extension=script_extension, File "/home/mwlib/py25/lib/python2.5/site-packages/mwlib-0.11.3.dev-py2.5-linux-x86_64.egg/mwlib/wiki.py", line 185, in _makewiki script_extension=script_extension, File "/home/mwlib/py25/lib/python2.5/site-packages/mwlib-0.11.3.dev-py2.5-linux-x86_64.egg/mwlib/wiki.py", line 84, in image_mwapi script_extension=script_extension, File "/home/mwlib/py25/lib/python2.5/site-packages/mwlib-0.11.3.dev-py2.5-linux-x86_64.egg/mwlib/mwapidb.py", line 381, in __init__ self.tmpdir = tempfile.mkdtemp() File "/usr/lib/python2.5/tempfile.py", line 328, in mkdtemp _os.mkdir(file, 0700) OSError: [Errno 31] Too many links: '/tmp/tmpofaZRu'

Andere Fehlermeldung. Conny 12:02, 9. Mai 2009 (CEST).Beantworten


Auf dem Render-Server ist ein Fehler aufgetreten: traceback Traceback (most recent call last): File "/home/mwlib/py25/lib/python2.5/site-packages/mwlib-0.11.3.dev-py2.5-linux-x86_64.egg/mwlib/apps/render.py", line 182, in __call__ env = self.get_environment() File "/home/mwlib/py25/lib/python2.5/site-packages/mwlib-0.11.3.dev-py2.5-linux-x86_64.egg/mwlib/apps/render.py", line 93, in get_environment env = self.parser.makewiki() File "/home/mwlib/py25/lib/python2.5/site-packages/mwlib-0.11.3.dev-py2.5-linux-x86_64.egg/mwlib/options.py", line 150, in makewiki script_extension=script_extension, File "/home/mwlib/py25/lib/python2.5/site-packages/mwlib-0.11.3.dev-py2.5-linux-x86_64.egg/mwlib/wiki.py", line 268, in makewiki script_extension=script_extension, File "/home/mwlib/py25/lib/python2.5/site-packages/mwlib-0.11.3.dev-py2.5-linux-x86_64.egg/mwlib/wiki.py", line 185, in _makewiki script_extension=script_extension, File "/home/mwlib/py25/lib/python2.5/site-packages/mwlib-0.11.3.dev-py2.5-linux-x86_64.egg/mwlib/wiki.py", line 84, in image_mwapi script_extension=script_extension, File "/home/mwlib/py25/lib/python2.5/site-packages/mwlib-0.11.3.dev-py2.5-linux-x86_64.egg/mwlib/mwapidb.py", line 381, in __init__ self.tmpdir = tempfile.mkdtemp() File "/usr/lib/python2.5/tempfile.py", line 328, in mkdtemp _os.mkdir(file, 0700) OSError: [Errno 31] Too many links: '/tmp/tmpSeiHHq'


Mindestens zwei gleichlautenden Fehlermeldungen sind auch per E-Mail beim Support-Team aufgeschlagen. — Raymond Disk. Bew. 10:58, 11. Mai 2009 (CEST)Beantworten

Sorry. :-( Der Fehler wurde am Sonntag korrigiert. Wir werden uns bemuehen, das Monitoring und die Wikimedia-Integration in den naechsten Tagen wesentlich zu verbessern, um solche (in der Ursache relativ trivialen) Fehler ganz zu verhindern oder zumindest fruehzeitig zu erkennen.--Eloquence 20:49, 11. Mai 2009 (CEST)Beantworten

hier noch eine fehlermeldung. Gruß--ot 14:22, 16. Mai 2009 (CEST)Beantworten

große Tabellen

Ich wollte eine größere Tabelle mit Bildern als PDF erstellen und bekam folgende Fehlermeldung. Danke für Hilfe, Conny 15:04, 14. Mai 2009 (CEST).Beantworten

Auf dem Render-Server ist ein Fehler aufgetreten: Collection/article could not be rendered
Scheint mit der Layouterstellung zu tun zu haben. Conny 17:48, 14. Mai 2009 (CEST).Beantworten

Habe heute noch mal mit genannter Seite probiert, ebenfalls die Meldung, das die Collection nicht gerendert werden kann. Danke für Hilfe, Conny 20:01, 27. Mai 2009 (CEST).Beantworten

Ich schaue mir das Problem an und melde mich wenn es behoben ist. -- Volker.haas 11:13, 28. Mai 2009 (CEST)Beantworten

Heut hat es das erste Mal geklappt. Dankend, Conny 17:28, 13. Jun. 2009 (CEST).Beantworten

Mache ich einen Fehler oder ist die Bucherstellung noch sehr buggy?

Seit einigen Tagen versuche ich, ein Buch aus verschiedenen Vorlagen zu erstellen. Der PDF-Output und die PediaPress-Funktion führen jedoch regelmäßig zu Fehlermeldungen wie zuletzt "Auf dem Render-Server ist ein Fehler aufgetreten: Collection/article could not be rendered". Kann ja sein, dass ich was falsch mache, aber was? Mein letzter Test lief hiermit [[7]] nicht ab. Vorab besten Dank für Tipps -- losch 23:15, 22. Mai 2009 (CEST)Beantworten

Ich habe genau das gleiche Problem (Auf dem Render-Server ist ein Fehler aufgetreten: Collection/article could not be rendered). Gestern wollte ich dieses Buch erstellen, blieb aber ca. 2,5 h bei 77%, bis dann dieser Fehler auftrat. Heute hab ich es auch schon nur mit den ersten 29 Seiten probiert, kommt aber genau der gleiche Fehler. Besten Dank im Voraus -- SK Rapid Wien 13:51, 23. Mai 2009 (CEST)Beantworten
Die Buchbestellung klappte gestern zwar, aber eine pdf-Produktion lief eben wieder auf diesen Fehler: "Auf dem Render-Server ist ein Fehler aufgetreten: Collection/article could not be rendered". -- losch 08:26, 25. Mai 2009 (CEST)Beantworten
Beide oben verlinkten Bücher können momentan leider nicht als PDF exportiert werden - das wird aber schnellstmöglich behoben. Beide Bücher sind relativ groß, daher braucht die Software, die die PDFs generiert viel Hauptspeicher. Da es ein Speicherlimit gibt, welches bei der PDF generierung nicht überschritten werden darf (um den Server vor Überlastung zu schützen), wird der Prozess abgebrochen. Ich bin gerade dabei ein paar Dinge umzustellen um die Speicherbelastung zu verringern - dann wird man die oben verlinkten Bücher als PDF exportieren können. Sorry für die Umstände -- Volker.haas 16:39, 27. Mai 2009 (CEST)Beantworten
Besten Dank für die Erläuterungen. Das ist plausibel. Es wäre allerdings gut, wenn man ein Tool vorschalten könnte, das einem eine Abschätzung der Buchgröße zurückgibt. Wenn dann noch grobe Grenzwerte bekannt wären (sind sie?) würden Überschreitungen sicher meist vermieden. Ich muss zugeben, die Buchfunktion verführt ein wenig. ;) Toll!!! Viele Grüße -- losch 21:18, 27. Mai 2009 (CEST)Beantworten
Leider ist es sehr schwierig abzuschätzen welche Kollektion wieviel Speicher beim Rendern verbraucht. Das hängt von vielen Faktoren ab - daher wäre das vermutlich hochgradig nicht-trivial zu implementieren. Außerdem braucht so ein Tool auch wieder Zeit um die Abschätzung durchzuführen. Aufgrund des Aufwands der Entwicklung und dem Nachteil mit der zusätzlichen Laufzeit würde ich mich erstmal dagegen aussprechen. Die Zeit würde ich lieber dafür nutzen dafür zu sorgen, dass Kollektionen die jetzt Probleme bereiten in Zukunft als PDF exportiert werden können. Ich hoffe, dass ist verständlich ;) -- Volker.haas 10:32, 28. Mai 2009 (CEST)Beantworten
So, das Buch wurde heute geliefert und ist noch deutlich besser als erwartet! So etwas eignet sich durch individuelle Zusammenstellung auch hervorragend als sehr persönlich gestaltetes Geschenk. -- losch 14:45, 10. Jun. 2009 (CEST)Beantworten

Durch diverse Umstellungen in der Software, sowie auf dem Render-Server kann die obige Collection jetzt auch als PDF gerendert werden. Jbeigel 09:47, 17. Jul. 2009 (CEST)Beantworten

Verarbeitung von doppelten Datumsangaben (julianisch/ gregorianisch) im PDF-Export fehlerhaft

Dieses Problem sollte nach der nächsten Aktualisierung der Software behoben sein.

Beim PDF-Export von Artikeln, in denen für doppelte Datumsangaben (julianisch/ gregorianisch) die Vorlage:JULGREGDATUM verwendet wird, werden die betreffenden Datumsangaben nicht in der PDF-Version angezeigt. Siehe als Beispiel den Artikel Friedrich Fromhold Martens (bei den Lebensdaten in der Einleitung) und die daraus generierte PDF-Version. -- Uwe 16:22, 27. Mai 2009 (CEST)Beantworten

Dieser Abschnitt kann archiviert werden. Volker.haas 14:34, 17. Jul. 2009 (CEST)

Vorlage:Coordinate

Die WP-Buchfunktion wird gestört, falls bereits Geodaten im Artikel hinterlegt sind. Zumeist wird lediglich "{{Coordinate|XYZ}} (http://stable.toolserver.org/geohack/geohack.php?pagename=XXX&language=de&params=0_N_0_E_region:DE-BW_type:landmark" angezeigt, gelegentlich überlagert die Vorlage aber auch ganze Abschnitte. Einfachste Lösung: "Kategorie:Vom Druck ausschließen" hinzufügen - aber es ist ja wohl nicht gewünscht, dass solche Probleme schnell und "unbürokratisch" gelöst werden ;-) -- Mark Wolf 18:00, 28. Mai 2009 (CEST)Beantworten

weitere Diskussion siehe: Wikipedia_Diskussion:WikiProjekt_Georeferenzierung#Probleme_bei_PDF-Erstellung -- Mark Wolf 18:17, 28. Mai 2009 (CEST)Beantworten

Seitennummerierung (2.)

  • Vorschlag: Die Seitennummer zentriert, würde bei linken/rechten Seiten ein einheitliches und schöneres Bild ergeben.


und

  • Titelseite: Erstelldatum sollte unter Titel/Untertitel auch gut lesbar aufscheinen.

-- Moschitz 21:24, 17. Jun. 2009 (CEST)Beantworten

Vorlage:Infobox Fußballklub

Übertrag Vorlagenwerkstatt

Bei dem Versuch, die neue Funktion "Buch erstellen" zu nutzen, ist mir aufgefallen, das in dem Artikel Eckernförder SV die Vorlage:Infobox Fußballklub nicht richtig angezeigt und ausgedruckt wird. Ein Versuch, die Kategorie:Vom Druck ausschließen anzuwenden, schlug fehl. Es wäre schön, wenn als kurzfristige Lösung der Druck unterbunden werden könnte (vielleicht kann jemand die Kategorie an der richtigen Stelle einsetzen?) oder wenn der fehlerfreie Druck ermöglicht werden könnte. Schönen Dank schon mal! -- Sciurus 23:26, 12. Jun. 2009 (CEST)Beantworten

Hallo Sciurus, Infoboxen sollen meines Wissens nicht vom Druck ausgeschlossen werden! Andernfalls müsste der Kategoreeintrag in Vorlage:Infobox Fußballklub/Meta eingefügt werden. Allerdings sollte meiner Meinung nach die Ursache des Druckproblems mit der Vorlage behoben werden, anstatt die Symptome zu bekämpfen und die Vorlage vom Drucken auszuschließen. Gruß --WIKImaniac 00:19, 13. Jun. 2009 (CEST)Beantworten
Ich schaffe es leider nicht, eine PDF-Version zu erzeugen. Es gibt immer einen Fehler. Hast du noch einen Link auf eine PDF-Version, so dass wir uns das anschauen können? Danke. Der Umherirrende 10:09, 13. Jun. 2009 (CEST)Beantworten
Leider nicht. In der von mir bereits heruntergeladenen Datei fehlt der Artikel komplett. Bei einem neuen Versuch erhalte ich auch Fehlermeldungen, wie erst neulich. Auf jeden Fall schon mal vielen Dank, daß Ihr Euch der Sache annehmt! -- Sciurus 13:06, 13. Jun. 2009 (CEST)Beantworten
Kein Wunder fehlte der Artikel komplett. Dein von mir zurückgesetzter Edit führte ja auch dazu, dass alle Artikel mit der Infobox in die Kategorie:Vom Druck ausschließen einsortiert waren. --Leyo 13:22, 13. Jun. 2009 (CEST)Beantworten
Oha, DAS wollte ich gar nicht! Ich bitte um Entschuldigung. Bei meinen Versuchen nach dem Einfügen der Kategorie schien mir nur die Infobox nicht mit ausgedruckt zu werden. Mein PDF wurde nach dem Entfernen der Kategorie erstellt. Von anderen Seiten kann ich übrigens PDFs erstellen lassen; nur beim Artikel Eckernförder SV geht es auch nach mehreren Versuchen nicht. -- Sciurus 13:49, 13. Jun. 2009 (CEST)Beantworten
Nach stichpunktartigem Testen wird von keinem Artikel, der die Infobox enthält, eine PDF-Version erstellt. Ich denke, dass das System die Entfernung der Kategorie noch nicht ganz mitbekommen hat. Ich würde noch etwas abwarten und wenn es dann nicht geht, einen Bugreport schreiben. Gruß -- Steef 389 14:16, 13. Jun. 2009 (CEST)Beantworten
Hallo, die Seiten mit der Vorlage produzieren immer noch einen Fehler und verhindern eine PDF- und Buch-Erstellung. Mit Bugzilla komme ich trotz eines Versuches nicht klar. Könnte bitte jemand anderes einen Bugreport verfassen? Das wäre klasse! Vielen Dank vorab. Gruß, -- Sciurus 22:11, 16. Jun. 2009 (CEST)Beantworten
Das wird wohl an der Vorlagenkonstruktion für die Trikots liegen. Diese war ein gewaltiger "Hack" um SVG-Grafiken zusammen mit alten bestehenden PNG/GIF Grafiken zu kombinieren. Vermutlich ist die Software bei diesem Konstrukt einfach überfordert. (Da liegen mehrere Grafiken übereinander) --Niabot議論+/− 22:38, 16. Jun. 2009 (CEST)Beantworten

Übertrag Vorlagenwerkstatt - Ende

Inzwischen funktioniert die PDF-Erstellung (siehe hier). Allerdings ist die Grafik dann ziemlich kaputt. -- Sciurus 10:20, 21. Jun. 2009 (CEST)Beantworten

Zeitstempel der Version

Beim Support-Team ist eine E-Mail eingegangen (Ticket#: 2009062510041499), die sich lobend über die Funktion äußert, aber gleichzeitig auch das Fehlen von Uhrzeit und Datum bemängelt, wann das PDF erstellt wurde. Im Abschnitt „Quellen und Bearbeiter des Artikels“ wird der Permalink angegeben, dort (oder vielleicht auch woanders im Text und damit prominenter) könnte der Zeitstempel der Version und das Druckdatum untergebracht werden. — Raymond Disk. Bew. 13:14, 26. Jun. 2009 (CEST)Beantworten

Ein Zeitstempel wird momentan nur ausgegeben wenn ein Buch erstellt wird (also nicht direkt über PDF-Version in der Werkzeugekiste - und dann auch nur falls ein Titel angegeben wird. In diesem Fall wird der Zeitstempel auf der Titelseite angegeben. Weitere Möglichkeiten für einen Zeitstempel:
  • in der Fußzeile auf jeder Seite
  • am Ende des PDFs nach der Lizenz
Gibt es weitere Vorschläge, bzw. welcher der obigen würde präferiert werden? -- Volker.haas 16:00, 2. Jul. 2009 (CEST)Beantworten

Positionsmarkierung in Deutschlandkarte

Zu diesem Problem gibt es ein Ticket.

Die in der {{Infobox Gemeinde in Deutschland...}} in der Deutschlandkarte rot markierte Position der Stadt verrutscht im Druck stark nach oben, z.B. bei Bad Münder und Lüneburg oder in diesem Buch gleich auf Seite 2. Hm, da dieser Schönheitsfehler alle Ortsartikel betreffen dürfte, kann das ja eigentlich kein unbekanntes Problem sein. -- Ukko 10:49, 27. Jun. 2009 (CEST)Beantworten

Das ist in der Tat kein unbekanntes Problem, leider ein äußerst schwierig zu lösendes. Leider kann ich keine Prognose abgeben, wann das Problem behoben sein wird. -- Volker.haas 16:03, 2. Jul. 2009 (CEST)Beantworten

Kleinere Problemchen (Refs, Lizenzen)

Ich habe es mit Alter Garten (Schwerin) ausprobiert. Folgende Kleinigkeiten fallen in's Auge:

  • Die gruppierten werden einfach mit normalen Refs zusammengefasst. Dies ist insbesondere ungünstig, da die Überschrift der gruppierten Einzelnachweisen nun einfach unmotiviert unter den Einzelnachweisen steht.
  • Einige Dateilizenzen werden nicht erkannt und als "unbekannt" angegeben.
    • An der Lösung wird gearbeitet - dazu gibt es ein Ticket in unserem internen Issue-tracker.
  • Das Problem mit den Links auf die Bilder wurde oben schon erwähnt. Es betrifft auch den Link auf den Artikel.
    • Das Problem wurde behoben
  • Als Lizenz für den Text wird immer noch die GFDL angegeben. Es empfiehlt sich, hier die Lizenzumstellung auf CC nachzuvollziehen. Der Lizenztext müsste dann nur abgedruckt werden, wenn Bilder unter GFDL eingebunden sind. -- Rosentod 20:43, 27. Jun. 2009 (CEST)Beantworten

Drucken mit Acrobat Plugin gibt komisches Ergebnis

Gerade zum 1. mal versucht, ein Buch zu machen. Sieht sehr gut aus. Wenn ich jedoch den PDF in Firefox öffne mit adobe plugin und drucke, dann kommt es nicht gut heraus: jede Leerstelle und Zahl ist durch ein Kästchen ersetzt: ⎕, wodurch das ganze unlesbar wird. H. Disk. 15:26, 28. Jun. 2009 (CEST)Beantworten

Könntest du bitte einen Beispielartikel nennen - auch wenn ich befürchte, dass ich dadurch der Lösung des Problems nicht viel näher komme. Solange das Problem besteht, empfehle ich einen anderen PDF Betrachter zu benutzen. -- Volker.haas 16:06, 2. Jul. 2009 (CEST)Beantworten
Ich habe es schon mit 2 verschiedene Artikel gehabt, gerade eben mit Johann Gottlieb Fichte. Tatsächlich funktioniert es aus anderen PDF-viewern gut (jedenfalls mit Evince). H. Disk. 12:57, 5. Jul. 2009 (CEST)Beantworten
Leider habe ich noch keine Idee, was die Ursache für das Problem ist (und kann das auch nicht reproduzieren). Ich habe auf unserem Testwiki eine Test-Seite angelegt. Könntest du versuchen das Problem einzugrenzen: PDF erstellen, kontrollieren ob das Druckproblem weiterhin besteht und dann solange Teile des Texts löschen bis das Druckproblem verschwindet. -- Volker.haas 11:15, 7. Jul. 2009 (CEST)Beantworten
Sogar mit minimaler Inhalt ist das Problem da. Ich habe mal Fotos von dem Ergebnis gemacht: [8] und [9]. H. Disk. 22:24, 10. Jul. 2009 (CEST)Beantworten
Ich habe mal die problematische Datei hochgeladen. Du kannst sie gerne löschen, wenn das Problem behoben ist. H. Disk. 22:30, 10. Jul. 2009 (CEST)Beantworten
Ich gehe davon aus, das Problem behoben zu haben. Ich habe die PDF Datei neu generiert - nun kann man das hoffentlich problemlos drucken. Bitte sag Bescheid, ob das auch wirklich der Fall ist. In Kürze wird die Software dann auch in der Wikipedia aktualisiert sein. Volker.haas 13:41, 14. Jul. 2009 (CEST)Beantworten

Ein einziger Artikel als Buch

Guten Tag! Ist es möglich einen Artikel eins zu eins zu drucken? D.h. ich würde gerne die Kapitelangaben des Artikels als Inhaltsverzeichnis des Buches sehen. Wenn ich jetzt einen Artikel als Buch drucken möchte, dann wird im Inhaltsverzeichnis nur der Name des Artikels gelistet. Bei einem Artikel pro Buch ist das nicht wirklich sinnvoll. Besten Dank im Voraus für die Hilfe - Matthias Buettner 18:41, 9. Jul. 2009 (CEST)Beantworten

Hallo, ist zwar keine Stellungnahme zum Anliegen Matthias', aber: Ich denke, dass Buchfunktion und pdf-Generierung eines einzelnen Artikels die gleiche software-Grundlage haben, das Ergebnis letzterer Funktion gefällt mir ..
@Matthias: Ich weiß nicht, wie du ausgestattet bist, aber von Hand müsstest du (mit Open Office beispielsweise) ein pdf-Dokument mit den gewünschten Angaben selbst anfertigen und beides mit einem geeigneten pdf-Maker verknüpfen können. Ich verwende dafür Adobe Acrobat, ist aber keine freeware. Grüße
@Matthias: Deinen Wunsch umzusetzen halte ich momentan für problematisch. Nicht jeder Nutzer möchte eine ausführliche Version des Inhaltsverzeichnis. Sobald die Möglichkeit besteht PDFs und Bücher individuell anzupassen kann man das gerne einbauen. Ich habe das entsprechende Ticket angepasst. Volker.haas 11:30, 14. Jul. 2009 (CEST)Beantworten