Wikipedia Diskussion:Technik/MediaWiki/Collection

Automatische Archivierung

Auf dieser Seite werden Abschnitte automatisch archiviert, wenn sie mit {{Erledigt|1=--~~~~}} markiert sind und ihr jüngster signierter Beitrag mehr als 2 Tage zurückliegt. Die Archivübersicht befindet sich unter Archiv.

Die Entwickler der Bucherweiterung sind im IRC #pediapress erreichbar. 
Nicks: hejko, jojob, schmir, v0lk3r

Principal Authors

Hallo He!ko, diese Auswertung scheint nicht korrekt zu arbeiten. So bin ich z.B. im Artikel 65537-Eck erwähnt, obwohl ich nicht zur aktuellen Version beigetragen habe. Vielleicht schaust Du Dir mal Benutzer:APPER/WikiHistory an; den dort verwendeten Algorithmus zur Zuordnung von Textbeiträgen zu einzelnen Autoren halte ich für den besten, den ich bisher gesehen habe. Gruß --Jodoform 01:51, 27. Jan. 2009 (CET)

Benutzer:Vlado hatte sowas mal für die WikiPress Buchreihe programmiert (siehe auch den Mailinglistenbeitrag von Achim). --Frank Schulenburg 02:02, 27. Jan. 2009 (CET)

Ja, den Diskussionsfaden kenne ich und er war Grundlage für die jetzige Implementierung. Es gibt hier zwei Probleme. Zum einen existiert kein Konsens darüber, was die "Hauptautoren" eines Artikels sind. Zum anderen laufen alle potentiell konsensfähigen Vorschläge auf eine technische Implementierung hinaus, die die vollständige Datenbank mit allen Versionen benötigt. Soetwas kann nur im Kern der MediaWiki-Software implementiert werden. Zitat aus dem Beitrag vom Achim: "Im Ergebnis: Es wird echt Zeit, dass es eine brauchbare Implementierung in der Wikipedia gibt, nach der auf Knopfdruck brauchbare Haupautorenlisten erscheinen" - dem kann ich mich nur anschließen. he!ko 11:47, 27. Jan. 2009 (CET)

Da schließe ich mich an, ich gehe aber davon aus, dass die Entfernung von Bots, IPs und "kleinen" Änderungen nicht okay ist. Bei Bots ist sie sicher am ehesten zu vertreten, ich habe noch keine Bot-Änderung gesehen, die urheberrechtlichen Schutz genießt. Bei IPs und "kleinen" Änderungen sieht das anders aus. Vor allem die "kleinen" Änderungen. Ich habe mich schon manchmal verklickt (ist ja direkt über "Seite speichern"). Ich will jetzt keine Stelle suchen, an der jemand unter den fünf Hauptautoren ist und wirklichen urheberrechtlich relevanten Beitrag geleistet hat, aber davon gehe ich aus. Und niemand sagt mit dem Haken an "Nur Kleinigkeiten wurden verändert", dass er nichts urheberrechtlich relevantes getan hat oder auf seine Rechte verzichtet.

Gleiches gilt für IPs. Nur weil man seine Beiträge unter einer Zahlenkolonne tätigt, heißt das nicht, dass man auf sein Urheberrecht verzichtet. Ich habe z.B. zwei feste IPs über das ich anonyme urheberrechtlich relevante Beiträge vor jedem Gericht beweisen könnte. Nun will ich weder klagen noch arbeite ich anonym, aber ich bin ja sicher kein Einzelfall.

Gleich noch eine Ergänzung: In der "mwapidb.py" (mwlib) steht in der Funktion getAuthors() ein API-Aufruf. Dort steht "'redirets': 1,", es heißt aber "redirects". Das könnte dazu führen, dass falsche Autoren genannt werden. Derzeit verhindert es aber lustigerweise sogar, dass falsche Autoren genannt werden. Added man eine Kategorie, in der sich eine Weiterleitung befindet, wird leider nur der Text "#REDIRECT [[Irgendwas]]" ausgegeben und korrekt die Autoren des Redirects. Sobald "redirets" in "redirects" geändert ist, würden aber wohl die Autoren des dortigen Textes genannt (denke ich). Also erst das mit den Weiterleitungen in Kategorien fixen, dann das "redirets" ;). Grüße --APPER\^☺☹ 01:54, 28. Jan. 2009 (CET)

Wenn Artikel A auf B weiterleitet und jemand Artikel/Kategorie A in sein Buch aufnimmt, wird dieser automatisch nach B aufgelöst. Also sollten auch die Autoren zu B bestimmt werden. Der Fehler ist behoben. Vielen Dank für den Hinweis! he!ko 19:17, 30. Jan. 2009 (CET)

Noch ein Problem zur Nichtnennung von anonymen Benutzern: Eine IP legt einen Artikel an (sagen wir holocaustleugnerisch), ich stelle einen Schnelllöschantrag, jemand erstellt ein Buch: was steht dort: "Hauptautoren: APPER". Na toll! Das ist ziemlich kritisch. Wenigstens "und 3 anonyme Autoren" (wie bei Directmedia damals gehandhabt) halte ich für nötig, damit ich nicht als einziger Autor angegeben werde. --APPER\^☺☹ 02:06, 28. Jan. 2009 (CET)

Gute Idee. "... und N anonyme Autoren" könnte man noch hinschreiben. he!ko 19:17, 30. Jan. 2009 (CET)

Noch ne Ergänzung: das mit den "kleinen" Änderungen ausblenden funktioniert ja derzeit nicht, ich finde das sollte auch beibehalten werden ;). --APPER\^☺☹ 02:42, 28. Jan. 2009 (CET)

Wieso funktioniert das nicht? Derzeit werden (als solche markierte) minor-edits nicht berücksichtigt. Allerdings bin ich mir nicht sicher ob die Interpretation gültig ist, dass der Benutzer mit dem Häkchen bestätigt auf seine Attributierung verzichten zu wollen. he!ko 19:17, 30. Jan. 2009 (CET)

Weil es nicht funktioniert... Beispiel: Franz Jöst. --APPER\^☺☹ 20:23, 3. Feb. 2009 (CET)

Kleine Änderungen weglassen - Meinung wie APPER. Conny 18:29, 30. Jan. 2009 (CET).

Ich habs gestern mal mit Ulrich von Wilamowitz-Moellendorff probiert, und da standen unter "Hauptautoren" erstmal ein paar Namen, die mir gar nichts sagten und die vielleicht einmal einen Tippfehler oder so verbessert haben. Ich habe an dem Artikel monatelang gearbeitet und tauche irgendwo an Platz 35 oder so unter "ferner liefen" auf. Irgendwie nicht so das Gelbe vom Ei, die Haupautorenangabe bei der Buchfunktion. Könnte das nicht verbessert werden? [ˈjoːnatan] (ad fontes) 08:33, 28. Jan. 2009 (CET)

Ähnliches fiel mir auch auf. Nach welchem Kriterium werden denn nun die Benutzernamen geordnet? Ich sah mich einer Liste mal irgendwo in der Mitte, wobei ich mit Abstand die zweitgrößte Anzahl an Bearbeitungen am Artikel habe. Es geht mir nicht um mein Ego, mich interessiert nur, wie es funktioniert. -- MonsieurRoi 19:56, 28. Jan. 2009 (CET)

Ich habe das gerade geprüft, es gibt keinerlei verbindliche Sortierung. Ich habe hierzu ein Ticket angelegt. he!ko 20:16, 28. Jan. 2009 (CET)

Das Ticket wird als (closed defect: fixed) geführt. Das Problem der sinnbefreiten Sortierung besteht aber weiterhin, oder sehe ich da was falsch?! --Tafkas ^{hmm?! +/-} 17:12, 30. Jan. 2009 (CET)

Die Software wurde entsprechend geändert; aktiv wird die Änderung erst nach dem nächsten Update der Software auf den Servern.he!ko 18:25, 30. Jan. 2009 (CET)

Der Algorithmus wurde nochmals geändert. Es werden wie gehabt alle anonymen, bot und minor-edits ignoriert. Reverts werden jetzt erkannt und samt der zwischenzeitlichen Änderungen nicht berücksichtigt. Die Länge (Buchstabenanzahl) der restlichen Text-Unterschiede werden dem jeweiligen Autor zugeordnet. Die Liste der Autoren wird nach der Summe der jeweiligen Text-Beiträge sortiert. Der Quelltext wird sich wohl noch häufig ändern und ist Open Source. Also falls jemand Lust hat eine konsensfähige Lösung zu implementieren ... :) he!ko 18:25, 30. Jan. 2009 (CET)

Die jetzige Implementierung wird nicht funktionieren, da die Länge des Artikels für jede Version scheinbar erst seit Anfang 2007 gespeichert wird. he!ko 18:25, 30. Jan. 2009 (CET)

Mögliche Lösungen: 1) Jemand pflegt auf Basis des Full-History-Dump die fehlende Information in der Datenbank nach 2) Sortierung nach A-Z 3) Sortierung nach Edit-Count (könnte funktionieren wenn die minor-edit flags korrekt gesetzt wären). Ideen? he!ko 18:49, 30. Jan. 2009 (CET)

Wie wäre chronologisch? Und die IPs (inklusive Uhrzeit) sollten aus Urheberrechtsgründen mit rein. -- Rosentod 19:47, 30. Jan. 2009 (CET)

Chronologisch ist auch machbar. Ist das mit den IPs dein Ernst? Was wären deines Erachtens die moralischen und konkreten rechtlichen Konsequenzen wenn man dies unterlässt? he!ko 20:53, 30. Jan. 2009 (CET)

IPs sind auch Urheber. Sie haben diesbezüglich die selben Rechte wie angemeldete Autoren. -- Rosentod 21:05, 30. Jan. 2009 (CET)

wählen aber die anonymität. mal ganz nüchtern betrachtet; würde ein "IP-Autor" klagen; wie könnte er nachweisen, dass er es war, der sich hinter der IP versteckte? und selbst wenn er nachweisen könnte dass es sein anschluss war (schon das dürfte sehr spannend werden); war er es oder seine Frau/Tochter/Bruder/Bekannter? Das risiko scheint mir hier doch höchstens im promille-bereich, eher noch darunter zu liegen ...Sicherlich ^Post 14:08, 31. Jan. 2009 (CET)

Dann betrachten wir es doch mal von der anderen Seite. Hypothetisches, überspitztes Beispiel: 2 Autoren haben einen Artikel geschrieben. Einer angemeldet, einer unter IP. Es gab Kontroversen, Streit, Edit-Wars, Vermittlungsausschüsse, ... Der angemeldete Benutzer will nun auf keinem Fall, dass die Beiträge der IP ihm zugeschrieben werden. Im Buch geschieht derzeit aber genau das, d.h. er wird plötzlich als alleiniger Autor dargestellt. Ich sehe auch keinen Grund, warum keine IPs mit in die Autorenliste aufgenommen werden sollten. Großartigen Mehraufwand kann das doch nicht bedeuten. Aber wenn man die IPs auf keinen Fall mit aufführen will, dann sollte man zumindest aufführen, wie viele IPs mitgewirkt haben. -- Rosentod 15:11, 31. Jan. 2009 (CET)

Ja, siehe gleiches Argument weiter oben. Ticket he!ko 15:19, 31. Jan. 2009 (CET)

Eben. Es gibt genug Argumente zur Nennung der IPs. Ich denke, dass man aus Nutzerfreundlichkeit nicht die eigentliche IP nennen muss sondern die Floskel "und 3 anonyme Autoren" etc. die Probleme bzgl. IPs lösen kann. --APPER\^☺☹ 20:14, 3. Feb. 2009 (CET)

Bei der ganzen "politisch korrekten" Diskussion solltet ihr die Benutzerfreundlichkeit nicht aus dem Auge verlieren und eine Seitenlange Autorenliste für jeden Artikel ist nicht benutzerfreundlich. Es steht zu befürchten das ihr nur erreicht das diese vielversprechende Funktion von vielen nicht angenommen wird, weil die primär Information kürzer wie die sekundär Information (Autoren, Links, Referenzen, GDFL usw.) ist. -- 91.55.14.112 19:16, 31. Jan. 2009 (CET) Prinzipiell ist auch ein Author der nur durch löschen in Erscheinung getreten ist ein Hauptautor, nämlich genau dann, wenn er wesentlich zum jetztigen Artikelumfang beigetragen hat (regelmässiges Entfernen von POV, Werbung und Lemmafremdem). Definiert bitte erst mal Hauptauthor bevor ihr hier versucht Lösungen zu verkaufen (pushen). -- visi-on 14:36, 3. Feb. 2009 (CET)

Wieviele Hauptautoren gibt es überhaupt pro Artikel

Ich bin gerade dabei, mit Hilfe des Tools WikiHistory von APPER eine Datenbasis zu erheben, um die Diskussion zur Hauptautoren-Attributierung voranzutreiben. Hier entsteht der Entwurf. Über Feedback zu Thesen und Daten (kommen bald auf die Seite) würde ich mich freuen. Zusammenfassung: Unter Verwendung der Hauptautorendefinition Zu den Hauptautoren (principal authors) eines WP-Artikels einer bestimmten Version gehört, wer Text zu diesem Artikel beigetragen hat, der in der gewählten Version noch enthalten ist, und Schöpfungshöhe besitzt. habe ich bisher selbst für die längsten Artikel nicht mehr als fünf Hauptautoren gefunden. Diese sollten in absteigender Folge ihrer Beiträge in % des Textes angegeben werden. --Minderbinder 13:38, 3. Feb. 2009 (CET)

vermutlich ist es serverbelastend bzw. zeitraubend? Gut fände ich es aber wenn es wirklich danach geht und nicht so ein "koschelmoschel" bei dem ich mit jeder Tippfehlerkorrektur schon zum Hauptautoren gestempelt werde ;) ...Sicherlich ^Post 13:52, 3. Feb. 2009 (CET)

Wie wird eigentlich derzeit sortiert. Es ist weder chronologisch, noch nach Menge noch nach Alphabet der Benutzernamen. Die User mit dem größten Anteil am Artikel sollten auch tatsächlich zuerst genannt werden. Wenn jemand 10k an Text erstellt und ein anderer drei Typos korrigiert sollte man das zwingend unter den Hauptbenutzern erkennen können. --Batke 22:52, 3. Feb. 2009 (CET)

Die Auswahl und Sortierung der sogenannten „Hauptautoren“ ist im Moment nicht nachvollzeihbar und schlecht. Ein Benutzer mit angemeldetem Account, der dreimal Unsinn in einen exzellenten Artikel schreibt, dreimal revertiert wird, landet nun unter Hauptautoren, evtl. vor den eigentlichen Autoren, die den Text verfasst und anderen Benutzern, die ihn redigiert haben. Woher die Reihenfolge kommt, ist unklar. Dann schon lieber alphabetisch. --Minderbinder 14:14, 4. Feb. 2009 (CET)

Aktueller Algorithmus (nach dem nächsten Update)

Die Methode zum Ermitteln der (Haupt-)Autoren wurde nochmals geändert. Es kann einige Tage dauern, bis das auf den Servern live ist und ich würde dann nochmals Bescheid geben.

• Bots und Reverts werden gefiltert
• Ergebnis ist die Liste aller angemeldeten Nutzer, die den Artikel bearbeitet haben (inklusive Änderungen die freiwillig als klein bezeichnet wurden) alphabetisch sortiert
• Die Anzahl der Anonymen Änderungen wird genannt

Hintergrund dieser Implementierung ist, dass die Software das MediaWiki nur über das API ansprechen kann. Die dort verfügbaren Informationen lassen 'intelligentere' Algorithmen derzeit nicht zu. Wie schon geschrieben, wünsche ich mir, dass ein ordentliches Lizenz- und Attributionsmanagement irgendwann in den MediaWiki-Kern integriert werden. Bis dahin müssen wir mit dieser Lösung leben. he!ko 19:53, 4. Feb. 2009 (CET)

Zum Begriff „Hauptautor“

Hallo allerseits,

ich habe das Gefühl, dass wir alle sehr davon profitieren würden, wenn wir uns auf klare Begrifflichkeiten einigen könnten. Mein persönlicher Vorschlag zur Begrifflichkeit (als Wikipediaautor) sieht wie folgt aus:

• Bearbeiter: alle Personen, die durch einen Edit zum Artikel beigetragen haben
  • Autor: Person, die schöpferisch zum Artikeltext in der gewählten Version beigetragen hat
  • Korrektor: Person, die den Artikel hinsichtlich Rechtschreibung, Grammatik, Typografie oder Stil überprüft hat und die dabei gefundenen formalen Fehler korrigiert hat
  • Lektor: Person, die den Artikel in seiner Entstehung inhaltlich (etwa durch Beiträge zum Review oder die Koordination von Reviewprozessen) begleitet und/oder inhaltliche Fehler korrigiert hat.

Demnach wäre ein „Hauptautor“:

• • Hauptautor(en): Person(en), die schöpferisch signifikant zum Artikel in der gewählten Version beigetragen hat/haben.

Und ich finde, mithilfe von Minderbinders Definition – hier auf den obigen Begriff „Autor“ bezogen – wird das ganze dann auch prima handhabbar:

„[…] wer Textteile zu diesem Artikel beigetragen hat, die a) in der gewählten Version noch enthalten sind, und b) Schöpfungshöhe besitzen.“ (Hervorhebung von mir)

Was die nähere Definition von „signifikant“ angeht, so würde ich persönlich gefühlsmäßig davon ausgehen, dass jemand dann als „Hauptautor“ bezeichnet werden kann, wenn er mindestens 20% des aktuell im Artikel enthaltenen Textes beigesteuert hat. Aber das ist nur ein auf meinen eigenen Erfahrungen und Vorstellungen basierender Vorschlag und genauso offen zur Diskussion gestellt wie die obige Begriffsdefinition. Herzliche Grüße --Frank Schulenburg 20:22, 4. Feb. 2009 (CET)

Ich finde diese Definition gelungen. Gerade weil wir im Moment (deiner Definition folgend) bei den Büchern "Hauptautor" schreiben und eigentlich "Bearbeiter" meinen. --Batke 21:15, 4. Feb. 2009 (CET)

Wenn kein Widerspruch kommt, würde ich dememtsprechend bitten, in den durch die Extension erzeugten Dokumenten den Begriff „Hauptautor“ durch „Bearbeiter“ zu ersetzen. Das schließt ja die Hauptautoren mit ein und nicht alle Bearbeiter sind eben auch Autoren eines Textes. Das ist bei gedruckten Büchern so und das ist hier nicht anders. --Frank Schulenburg 22:17, 4. Feb. 2009 (CET)

Doch ein wenn auch vorsichtiger Widerspruch. In der Angabe sollten die Hauptautoren (und vielleicht noch Revisoren und Lektoren) genannt werden. Jeden Bearbeiter für jeden Artikel zu benennen hieße ja fast die Historie darzustellen. Und man müsste alle nennen wenn es die Bearbeiter sind. Also auch diejenigen, die einen Begriff verlinken, einen Tippfehler korrigieren usw.

Wichtiger ist aber noch das OMA Prinzip. Wir hier verstehen sicherlich den Unterschied zwischen Bearbeiter und Hauptautor. In einem Artikel in einem Buch oder einem Aufsatz erwartet man (oder meine Schwiegermutter) das jeder der als "Autor" genannt wird erheblich am Text gearbeitet hat und auch inhaltlich voll hinter dem Artikel steht. Das trifft aber nur für die Hauptautoren zu, nicht für die Bearbeiter. Hier diese feinen Unterschiede zu erklären dürfte sehr kompliziert werden, wenn nicht sogar unmöglich sein.

Wir müssen uns hier mit anderen gedruckten Werken auf eine Stufe stellen. Niemand wird auf die Idee kommen, unter den Verfassern/Autoren o.ä. eines Textes diejenigen mit aufzunehmen, die einen Tippfehler korrigiert haben. Genau das aber machen wir wenn wir alle Bearbeiter nennen. Aus meiner Sicht müsste es also heißen "Hauptautoren" (auch wenn es nur einer ist) und ggf. zusätzlich die weiteren Bearbeiter... --Batke 23:03, 6. Feb. 2009 (CET)

ich mag mich irren; niemand hat etwas dagegen; nur scheitert dein wunsch im moment an der technik den wahren hauptautor auch herauszufinden. ....Sicherlich ^Post 23:11, 6. Feb. 2009 (CET)

Okay, damit werden wir dann wohl erstmal leben müssen. Ich hab mir mal das Tool von APPER (s.o.) geladen und damit einige Artikel ausgelesen, für einen einzelnen Artikel klappt das gut, aber für fast 900.000 Artikel ist das doch etwas viel. --Batke 10:29, 7. Feb. 2009 (CET)

Ja, wir werden damit leben müssen, dass eine technische Lösung für die Ermittlung der Hauptautoren fehlt. Dann sollte aber zumindest der Begriff „Hauptautoren“ durch „Bearbeiter“ ersetzt werden. Die jetzige Lösung ist für mich persönlich als Autor nicht akzeptabel. --Frank Schulenburg 01:12, 9. Feb. 2009 (CET)

sehr einfache lösung!

lasst die autoren einfach weg, deren aufzählung ist a) falsch, b) störend und c) einfach nur sinnlos!--84.185.115.190 18:22, 7. Feb. 2009 (CET)

siehe odt-format (mein erstes posting bezog sich auf das herunterladbare pdf-format), da geht es auch ohne!--84.185.115.190 19:47, 7. Feb. 2009 (CET)

genau, um im Straßenverkehr lassen wie die Verkehrsregeln auch gleich weg, dann ist man schneller am Ziel! Die Nennung der Autoren ist Bestandteil der Lizenz und somit zwingend erforderlich. Somit ist das leider keine brauchbare Lösung. --Batke 15:39, 8. Feb. 2009 (CET)

Bindestriche

Hallo, Bis-Striche und Gedankenstriche (d. h. Halbgeviertstriche) werden in den PDFs als Bindestriche wiedergegeben. Denke mal nicht, dass das so beabsichtigt ist. Gruß, --Tolanor 02:15, 27. Jan. 2009 (CET)

Könntest du bitte ein Beispiel-Artikel oder Mediawiki Code Schnipsel angeben. Ich konnte das Problem nicht nachvollziehen. Siehe zum Beispiel: Benutzer:Volker.haas - Volker.haas 10:28, 27. Jan. 2009 (CET)

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)

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)

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)

Müsste dann im MediaWiki gefixt werden. Jbeigel 14:17, 2. Feb. 2009 (CET)

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

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)

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)

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)

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)

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)

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)

Ich habe den Warnhinweis von der Hilfe in die FAQ verschoben. he!ko 17:52, 8. Feb. 2009 (CET)

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)

Buch laden

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)

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)

Inhaltsverzeichnis

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

+1--ot 08:57, 27. Jan. 2009 (CET)

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)

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)

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)

Antrag auf wiki-übergreifende Bücher/Sammlungen

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)

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)

Bilder in Infoboxen und Hieroglyphen

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)

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)

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)

noinclude und Qualität der Formeln

siehe: Wikipedia_Diskussion:Projektneuheiten#Buch_und_noinclude -- Rosentod 12:41, 27. Jan. 2009 (CET)

gleiches gilt für onlyinclude (siehe auch dort) --Der Umherirrende 21:48, 28. Jan. 2009 (CET)

Ich habe dafür ein Ticket angelegt. -- Volker.haas 16:45, 29. Jan. 2009 (CET)

Umfang

Gibts eine Beschränkung beim Umfang des zu erstellenden Buches? Nehmen wir an, ich möchte ein "Biographisches Lexikon der Schachspieler" erstellen - die entsprechende Kategorie umfasst >1200 Artikel... Gruß, Stefan64 17:00, 27. Jan. 2009 (CET)

Bei den PDFs zum Herunterladen gibt es keine Einschränkung (auch wenn das Erstellen natürlich entsprechend lange dauern kann). Bei den Büchern von PediaPress gibt es z.Zt. eine Einschränkung von max. ca. 800 Seiten, die sich aber noch ändern kann bzw. die wir abschaffen, sobald wir eingebaut haben, dass der Inhalt auf mehrere Bücher aufgeteilt werden kann. Jbeigel 10:29, 28. Jan. 2009 (CET)

Kategorien

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)

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)

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)

Fehler im Acrobat Reader

Ich wollte mir das Buch zur Computergrafik mal anschauen, das ging aber nicht. Irgendwann meinte der Acrobat Reader dann, dass die Pdf beschädigt sei. --Kolossos 12:59, 27. Jan. 2009 (CET)

Bei mir funktioniert es in der OSX Preview.app und hat 322 Seiten. Es wäre gut, wenn es noch jemand testen mag hier liegt das PDF (27MB). he!ko 18:31, 27. Jan. 2009 (CET)

Der "Foxit Reader" kommt auch sauber damit klar (Acrobat Reader hab ich nicht mehr - zu langsam). Guandalug 19:40, 27. Jan. 2009 (CET)

Bekomme mit Acrobat auch eine Fehlermeldung. -- Louisana 16:04, 28. Jan. 2009 (CET)

Nur mit speziell diesem PDF oder auch bei anderen Büchern? he!ko 20:04, 28. Jan. 2009 (CET)

Habe heute mal ein PDF-Dokument mit rund 300 Seiten (~28 MB) erzeugt. Wenn ich auf den Link mit dem fertiggestellten PDF anklicke, dauert es einige Zeit und dann kommt auch die Fehlermeldung. Wenn ich hingegen das Dokument erst per rechte Maustaste runterlade und dann öffne, klappt es problemlos. Es scheint also ein Problem des Acrobat-Readers zu sein; Dieser kappt wohl die Verbindung nach n Sekunden und hat dann nur ein halbes PDF-Files im Zugriff.
Gruß Ingo --Istiller 19:03, 1. Feb. 2009 (CET)

Lizenzen

Im Buch werden die Autoren des Artikels aufgezählt – sehr schön! Die GFDL wird abgedruckt – auch sehr schön. Allerdings habe ich für die Bilder weder Autoren noch Lizenzhinweise gesehen. Die müssten doch auch rein, oder irre ich mich? -- Spischot 13:26, 27. Jan. 2009 (CET)

Vermutlich das gleiche Problem wie oben in #Antrag auf wiki-übergreifende Bücher/Sammlungen: wenn Bilder auf Commons liegen, funktioniert noch nicht. -jkb- 18:16, 27. Jan. 2009 (CET)

Die Bilder im PDF sind zu ihrer Seite auf Commons verlinkt. Siehe auch Fragen und Antworten. he!ko 18:36, 27. Jan. 2009 (CET)

Hmmm... ich sehe, man hat sich darüber schon Gedanken gemacht und diese auch umgesetzt. Meine Zweifel sind damit aber noch nicht ganz verflogen. Der Bild-Lizenz ist durch den Web-Link im Pdf erfüllt. Wenn ich das Pdf ausdrucke (was keine unübliche Vorgehensweise für ein Pdf ist) geht diese Information verloren. Das bedeutet nach meiner Ansicht, dass man die Pdfs nicht drucken darf, weil man damit gegen die Lizenzbestimmungen verstößt (Lizenz und Urheber-Hinweis wurde entfernt). Wenn ich das Pdf nun online betrachte ist es juristisch besser, bleibt aber wenig offensichtlich. So wie ich Pdf-Dateien kenne und benutze vermute ich (im Unterschied zu einer Web-Seite) keine Hyperlinks hinter Elementen. Das ist auch der Grund, warum es mir zunächst nicht aufgefallen war. <spitzfindig>Ist ein Rechtshinweis juristisch gültig, wenn er verborgen angebracht ist, zum Beispiel nur über eine URL hinter einem bestimmten, nicht näher erkennbaren einzelnen Wort hinterlegt ist?</spitzfindig>. Mit einer Ausgabe der vollständigen Bild-URL (wie in der gedruckten Version) wären beide Askepte sauber vom Tisch. -- Spischot 18:57, 27. Jan. 2009 (CET)

Der Lizenzverstoß liegt dann aber auch gleichermaßen bei der ausgedruckten HTML-Druckversion vor - oder? he!ko 19:51, 27. Jan. 2009 (CET)

(BK) Hm ja stimmt, die Verlinkung im PDF war mir auch noch nicht aufgefallen. Drei Anmerkungen dazu:

1. Ich halte die fehlende direkte Autoren- und Lizenznennung bei der Bildern für suboptimal. Wer sich das PDF ausdruckt und dann vielleicht noch in der Klasse verteilt, hat ein Problem …
2. Bilder, die per [[Datei:Wiki.png|100px|Wiki per fester Bildbreite ohne Rahmen]] eingebunden werden, werden nicht vollflächig verlinkt, nur das unterste Fünftel (oder so) ist als Link vorhanden: Benutzer:Raymond/pdf

1. Das Problem tritt bei Bildern auf die mitten im Text stehen (bzw. Bildern die keine "Abbildungen" sind und keinen Rahmen haben). Die Verlinkung der Bilder erstreckt sich in der Höhe über die natürlich Zeilenhöhe - und das ist bei großen Bildern zu wenig. Leider habe ich noch keine Lösung für das Problem gefunden. Ticket -- Volker.haas 16:44, 30. Jan. 2009 (CET)

1. Schwarzer Hintergrund in der PDF-Ausgabe von Benutzer:Raymond/pdf — Raymond ^{Disk. Bew.} 19:08, 27. Jan. 2009 (CET)

1. Das Problem tritt wohl nur bei Graustufen Bildern mit Alphakanal auf. Ich habe einen Workaround implementiert, der aber leider kein perfektes Ergebnis erzielt - aber wohl wenigstens besser als bisher ist. Ticket -- Volker.haas 16:44, 30. Jan. 2009 (CET)

Bei der Lizenz viel mir auf:

• 2malige Nennung der Überschirft "Lizenz". Einmal wäre völlig ausreichend.
  • Könntest du bitte präzisieren wie und wo das auftritt. Das kann ich nicht nachvollziehen. -- Volker.haas 16:12, 29. Jan. 2009 (CET)
    • zB. hier auf Seite 2 die ersten beiden Zeilen: http://de.wikipedia.org/w/index.php?title=Spezial:Buch/download/&collection_id=ed320004ea89754d&writer=rl&return_to=Wikipedia%3AHauptseite
      • Ok, jetzt verstehe ich, was du meinst. Einmal steht "Lizenz" in der Kopfzeile und einmal als Überschrift. Das wird im ganzen PDF so gemacht - daher würde ich das ungern ändern und für die Lizenz eine Spezialbehandlung machen. Ich gebe zu, dass das etwas lustig aussieht aber nicht so störend ist das es unbedingt geändert werden müsste. -- Volker.haas 11:01, 6. Feb. 2009 (CET)
• Und die Alpha-Nummerierung bei "MODIFICATIONS" ist falsch bzw falsch interpretiert. Es wird auch für \n eine neue Nummierung vorgenommen.
  • Dafür habe ich ein Ticket angelegt - wird gefixt. -- Volker.haas 16:12, 29. Jan. 2009 (CET)
    • Das Problem ist inzwischen behoben, sollte in den nächsten Tagen auch online sein. -- Volker.haas 12:12, 3. Feb. 2009 (CET)

--MoLa 18:08, 28. Jan. 2009 (CET)

Im IRC wurde angemerkt, dass die Lizenzinformationen im PDF nicht vollständig sind, da Bildern lediglich verlinkt sind. Nutzer könnten annehmen, dass die in den Artikeln verwendeten Bilder Bestandteil das Artikels sind und ebenfalls unter die GFDL fallen. Lösungsansätze:

1. jegliche Lizenzinformation aus dem PDF entfernen (vergl. HTML-Druckversion)
2. vollständige Lizenzinformationen auch zu den Bildern (technisch derzeit nur schwer realisierbar)
3. ein Hinweis am Anfang/Ende des PDF, wie der Nutzer die Lizenzinformationen zu den Bildern erhalten kann

he!ko 15:42, 30. Jan. 2009 (CET)

ohne rechtsverdreher zu sein. aber bilder müssen ja "mindestens" der GNUFDL genügen gelle? wenn nun in dem Bild nur den autor erwähnen ist es rechtlich zwar Sicherlich noch nicht 100%ig aber doch schon nahe dran? :oD - und den autor müsste man ja über die vorlagen "leicht" auslesen können? ...Sicherlich ^Post 15:46, 30. Jan. 2009 (CET)

Für GFDL-Bilder stimmt das. Meinst du man sollte die Autoren der Bilder mit in die Liste der Autoren am Ende das Artikels aufnehmen? Bei CC wäre ein Link auf das Bild wichtiger denke ich. he!ko 16:01, 30. Jan. 2009 (CET)

Es wird eine Liste für die Bilder benötigt, in der a) die Autoren und b) die Lizenzen (PD, GFDL, CC) den Bildern eindeutig zugeordnet werden. Es darf keinesfalls der Eindruck entstehen, die Bilder stünden unter einer anderen Lizenz als vom Urheber erteilt. Bei den Bildern muss dazu einerseits der License-Tag, als auch das Author/Urheber-Feld ausgelesen werden. Dabei ist zu beachten, dass zumindest bei CC-Lizenz der Autor festlegen kann, wie die Attributierung zu erfolgen hat. Bsp: File:Soldier_fly_larva.jpg -- Rosentod 16:15, 30. Jan. 2009 (CET)

Wieso wird es in den PDFs überhaupt anders gemacht als in der gedruckten Version von PediaPress? In letzterer scheint man auch mit Bildern korrekt umzugehen, laut Hilfe:Buchfunktion/Fragen_und_Antworten#Wie wird den Anforderungen der GFDL entsprochen? wird es in den gedruckten Büchern so gemacht: Im Anhang:

• Voller Link zur verwendeten Version eines jeden Artikels
• Nennung aller Bearbeiter für jeden Artikel
• Voller Link zur verwendeten Version eines jeden Bildes
• Nennung aller Bearbeiter für jedes Bild
• Nennung der Lizenz für jedes Bild
• Abdruck der englischsprachigen GFDL

Gestumblindi 22:05, 30. Jan. 2009 (CET)

Eines der Probleme bei Bildern dürfte sein, daß man die Autoren-Angaben oft wahrscheinlich gar nicht zuverlässig per Software herausfiltern kann. Allein hier auf .de gibt es noch eine Unzahl von Bildern ohne die {{Information}}-Vorlage. Und auf Commons wird ist das wahrscheinlich noch schwieriger (Uploader oft != Urheber), nicht zuletzt auch durch die oft unvollständige Übertragung der Angaben nach Commons. Dazu noch eine große Anzahl von Bildern, bei denen es Extra-Wünsche bei der Autoren-Nennung gibt. Was uns Wikimedia-weit total fehlt, sind zuverlässige und einfach auslesbare standardmässige (Meta-)Angaben zu Autor, Lizenz und jeweils gewünschter Namensnennung, aus der man dann einfach z. B. Autor- und Lizenzangaben für Bildunterschriften generieren kann. --Kam Solusar 02:09, 31. Jan. 2009 (CET)

+1! MediaWiki wurde vorrangig hinsichtlich der Erstellung und Verbreitung freier Inhalte entwickelt. Eine technische Unterstützung der Verwaltung von Lizenzen fehlt jedoch völlig. Evtl. interessant hierzu auch der Faden auf Wikitech-I. he!ko 14:59, 31. Jan. 2009 (CET)

Das mag ja alles sein. Aber das rechtfertigt keine mangelhaften Angaben. Und wenn man eine Risikoabschätzung machen will, sind Bilder viel kritischer als Texte. Es ist aus meiner Sicht viel wahrscheinlicher, dass ein Photograph sein Recht einklagt, als ein Textautor. Weiterhin ist es wahrscheinlicher, dass er einfach keine Bilder mehr zur Verfügung stellt, wenn seine Rechte nicht beachtet werden. -- Rosentod 15:21, 31. Jan. 2009 (CET)

Vorschlag PDFs

Mein Vorschlag wäre, die PDFs nicht anders zu behandeln als die in der Wikipedia etablierte Druckversion. An deren Ende steht neben der URL das Artikels noch:

Der Text steht unter der GNU-Lizenz für freie Dokumentation. Bildlizenzen können abweichen.

Damit konnten bisher scheinbar alle gut leben und ich wüsste nicht, warum ein anderes Format eine andere Behandlung erfordern würde. Die Vorteile dieser Lösung wären: Höherer praktischer Nutzwert des PDFs (kürzer, übersichtlicher), kein Streit darüber was Hauptautoren sind, einfache Implementierung und Rechtssicherheit (mehrjährige Erfahrung mit einem Ansatz der nicht vorgibt, dass das Dokument ohne weitere detaillierte Prüfung weiterverbreitet werden darf).

In den gedruckten Büchern (Beispiel) sind die Anforderungen andere. Dort versuchen wir 100% kompatibel zu den Anforderungen der Lizenzen zu sein. Das hat die Einschränkung, dass wir Bilder deren Vorlage wir nicht eindeutig auf eine Lizenz und deren Anforderungen abbilden können im Buch aussparen müssen. In Ermangelung einer konsensfähigen Definition (geschweige Implementierung) von 'Hauptautor' werden alle Autoren zu Hauptautoren. Weiterhin wird ein nicht unbeträchtlicher Anteil der Seiten am Ende mit Lizenzen und Attributionen gefüllt. Falls es zu den Lizenzen und den Attributionen in Büchern noch Anmerkungen gibt, würde ich vorschlagen dies unabhängig von den PDFs zu besprechen. he!ko 20:56, 4. Feb. 2009 (CET)

Die Druckversion der Wikipedia ist streng genommen auch nicht lizenzkonform. Aber meines Wissens war es da schon immer (oder zumindest seit langer Zeit) so. Die Bücher sind dagegen eine Neuerung. Man sollte den Nutzern dann schon die Möglichkeit geben, sich an die Lizenz zu halten. Aber, wenn man Autorenlisten und Lizenzen ans Ende des PDFs packt, könnte jeder Nutzer, wenn er es ausdruckt, selbst entscheiden, ob er sich an die Lizenz hält oder ob es für seinen privaten Gebrauch nicht notwendig ist und er die Lizenzinformationen einfach nicht ausdruckt (Speicherplatz dagegen ist heute doch schon billig und kein Problem). Noch besser fände ich es, wenn man die Lizenzinformationen und Autorenlisten in die Metadaten des PDFs schreiben könnte und dann im eigentlichen Dateiinhalt nur noch darauf hinweist. Die Frage ist halt, ob der Speicherplatz dazu ausreicht und das überhaupt machbar ist. -- Rosentod 21:22, 4. Feb. 2009 (CET)

Wurde schon Kontakt zu Vlado von Directmedia gesucht? Bei Wikipress wurden Text- und Bildautoren automatisch generiert. --Marcela 21:15, 5. Feb. 2009 (CET)

Fatal finde ich, wenn die Einhaltung der GDFL für die Texte in den PDF-Büchern unbedarfte Nutzer glauben lässt, sie könnten so eine Datei lizenzkonform z.B. auf ihrem Webserver veröffentlichen. Dabei gehen Sie, so interpretiere ich diese Diskussion (und diese) ein nicht unerhebliches Risiko ein, von einem Bildautoren zur Kasse gebeten zu werden. Hier sollte die PDF schnellstmöglich den Standard der gedruckten Version erreichen, die ja offenbar auch die Bildautoren und -lizenzen ausweist. --Superbass 22:46, 5. Feb. 2009 (CET)

100% einverstanden (siehe oben), außer mit der Schlussfolgerung. Den Standard-Anwendungsfall der PDFs sehe ich nicht in einer Weiterverbreitung sondern in der persönlichen Nutzung. Hier wird der Nutzwert reduziert, wenn das PDF mit Lizenzinformationen überladen ist. Die Idee (mittelfristig) den Nutzer entscheiden zu lassen, ob er diese Informationen im PDF benötigt finde ich gut. Als kurzfristige Lösung würde ich aber meinen Vorschlag PDFs wie Druckversionen zu behandeln präferieren. he!ko 17:54, 6. Feb. 2009 (CET)

Ich halte Deine These, dass die PDFs vorwiegend privat genutzt werden, für gewagt. Die PDFs sind für Offline-Nutzung der Inhalte interessant. Wesentliche Anwendungsmöglichkeiten bietet dabei der Bildungsbereich. Damit beispielsweise ein Lehrer legal die PDFs (zusammengestellt nach den Bedürfnissen seines Unterrichts) an Schüler verteilen kann, müssen diese die Lizenzinformationen enthalten. Ob sich die Leute an die Lizenzen halten, ist letzlich deren Entscheidung. Aber man muss es ihnen doch mit vertretbarem Aufwand ermöglichen. -- Rosentod 18:09, 6. Feb. 2009 (CET)

Ja, es wäre wünschenswert (s.o.) - aber ich sehe nicht, dass man das muss. he!ko 19:12, 6. Feb. 2009 (CET)

Ich verstehe Dich irgendwie nicht ganz. Natürlich muss man. Die Lizenzen sind für die Weiternutzung doch eindeutig. Lizenzinformationen dürfen nicht entfernt werden. Punkt. -- Rosentod 19:58, 6. Feb. 2009 (CET)

Ich meinte ob man es "ihnen [doch] mit vertretbarem Aufwand ermöglichen" muss (die einfache Weiternutzung), wie du schriebst. Meine Frage ist, warum man das jetzt muss - bei der bisherigen Druckfunktion musste man es ja auch nicht. -- he!ko 21:45, 6. Feb. 2009 (CET)

Ich sehe die Vergleichbarkeit eigentlich nicht. Die Druckversion ist nur eine andere Ansicht. Sie ist immer noch HTML, die Lizenzinformationen sind immer noch nur einen Klick entfernt (und können mit ausgedruckt werden) und sie ist nicht besonders für Offlinenutzung in digitaler Form geeignet. Beim PDF ist das anders. Es ist primär für Offlinenutzung gedacht und die Inhalte sind leicht digital weiterverwendbar. Aus meiner Sicht ist es zumindest wahrscheinlich, dass so etwas wie Störerhaftung greift, wenn man PDFs zum Download anbietet, die die Lizenzinformation nicht enthalten. Davon abgesehen: Wenn die Druckversion lizenztechnische Schwächen hat, würde ich nicht den Schluss daraus ziehen, dass man das für die PDFs übernehmen sollte. -- Rosentod 11:55, 7. Feb. 2009 (CET)

Im Village Pump der Commons gibt es einen Antrag für eine Erweiterung mit dem Ziel, Metadaten (insbesondere Lizenzen und Autoren) besser zu unterstützen. Von einer solchen Erweiterung würde auch die Buchfunktion stark profitieren. Ich hab' mein Kreutzchen gemacht :) --he!ko 18:27, 8. Feb. 2009 (CET)

Bitte den Hinweis zu Rechtsthemen beachten!

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)

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)

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)

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)

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)

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)

noinclude

Damit das hier auch noch mal steht: Sobald ein </noinclude>-Tag auftaucht, wird danach nichts mehr ins Buch übernommen. Sollen wir also alle diese Tags aus den Artikeln entfernen? Oder kann man nicht die Erweiterung entsprechend anpassen, damit sie diese Tags ignoriert? -- Rosentod 18:46, 27. Jan. 2009 (CET)

Der Fehler ist nach dem nächsten Update behoben. he!ko 19:00, 2. Feb. 2009 (CET)

Heißt das, die Tags werden ignoriert? Oder machen sie dann genau das, was sie eigentlich sollen und wir müssten sie trotzdem aus den Artikeln entfernen? -- Rosentod 19:23, 2. Feb. 2009 (CET)

Sie sollten sich nicht anders als im MediaWiki verhalten he!ko

Einzelnachweise

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)

Stimmt. Und eventuell vorhandene Geokoordinaten werden da mit reingeschoben. --Felix ^fragen! 18:43, 27. Jan. 2009 (CET)

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)

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)

Ticket angelegt. he!ko 21:27, 30. Jan. 2009 (CET)

Japanisch/Chinesisch

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)

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)

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)

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)

Sind diese Unterschiede im Mediawiki Markup zu erkennen? -- Volker.haas 16:38, 28. Jan. 2009 (CET)

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)

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)

Rechts-nach-links-Schriften á la Arabisch

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)

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)

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)

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)

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)

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)

koordinaten-Punkt

habe gerade Łódź als PDF erstellt. Der Koordinaten-Punkt aus der Infobx landet an einer etwas schrägen stelle. In der Infobox stehen bei "Geographische Lage" Fußnoten die es im Original-Artikel nicht gibt und die Koordinaten werden in zwei Varianten dargestellt. ...Sicherlich ^Post 22:41, 27. Jan. 2009 (CET) insgesamt aber ein sehr nettes feature

Die Positionierung des "Koordinaten-Punkts" im PDF ist leider ein schwieriges Thema. In der Wikipedia wird der Punkt über ein Template mit CSS styles absolut positioniert. Das ist im PDF nicht möglich. -- Volker.haas 12:59, 28. Jan. 2009 (CET)

ICD-Box

Eine hervorragende Funktion, vieles ist sehr durchdacht. Die Vorlage:Infobox ICD, die normalerweise ein kleiner Kasten ist (vgl. z. B. Röteln), wird im PDF als Kasten quer über das Bild formatiert (Buch als PDF), kann man das korrigieren? Grüße, --Andante ¿! ^WP:RM 10:27, 28. Jan. 2009 (CET)

Das ist leider etwas unschön, aber nicht einfach zu ändern. Siehe auch meinen ersten Kommentar hier: Bemerkung zu den Infoboxen -- Volker.haas 13:26, 28. Jan. 2009 (CET)

Dies betrifft eigentlich alle Infoboxen. Bei den einen Artikeln ist es nicht so schlimm. Andere sehen nicht mehr vorzeigbar aus. Liesel 10:40, 28. Jan. 2009 (CET)

Jedes Buch heißt "collection.pdf"

Man sollte vor allem den Namen ändern, komischerweise heißt jedes „Buch“ collection.pdf --87.78.35.109 17:13, 28. Jan. 2009 (CET)

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)

Auf der generierten Titelseite unten das Generierungsdatum/zeit in UTC angeben

Die Titelseite enthält den Titel und womit das PDF generiert wurde

Dieses PDF wurde mit dem Open-Source-Toolkit „mwlib“ erstellt.

Siehe http://code.pediapress.com/ für weitere Informationen.

Ich möchte vorschlagen, dass an dieser Stelle auch das Erzeugungsdatum und -zeit in UTC auch gedruckt wird. --Wikinaut 17:52, 28. Jan. 2009 (CET)

Das halte ich für eine gute Idee. Ich habe dafür ein Ticket angelegt. -- Volker.haas 14:19, 2. Feb. 2009 (CET)

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

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)

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)

Positionskarten

Mir ist aufgefallen, dass {{Positionskarte+}} weder unterstützt noch unterdrückt wird. Ein Beispiel dafür ist hier zu finden, gleich nach der Einleitung. --AFBorchert 00:38, 29. Jan. 2009 (CET)

<poem>...</poem>

... wird ebenfalls noch nicht unterstützt. Hier ist ein Beispiel dafür. --AFBorchert 00:41, 29. Jan. 2009 (CET)

Ticket he!ko 00:03, 3. Feb. 2009 (CET)

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)

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

Tabelle Hintergrundfarbe

Hallo, bin ich hier richtig um die Info loszuwerden? Ich habe versucht den Artikel Großstadtrevier als "PDF-Version" anzuzeigen. Dabei kam diese Datei raus: [1]. In der Tabelle "Zeitleiste der Charaktere" sieht es seltsam aus. Ist der Bug (?) bekannt? -- Steffen2 19:15, 29. Jan. 2009 (CET)

Die entsprechende Tabelle hat in der Tat ein paar Darstellungsprobleme. Die fehlende zentrierung des Textes in den Zellen habe ich behoben. Allerdings bleibt das gravierendere Problem mit den kaputten Hintergrundfarben der Zellen bestehen. Dazu habe ich ein Ticket angelegt. -- Volker.haas 10:32, 30. Jan. 2009 (CET)

Problem ist behoben. Eine Unschönheit bleibt bestehen - und ich habe momentan leider keinen vernünftigen Lösungsansatz: Die Tabelle ist recht breit, die Spalten jeweils ziemlich schmal, das führt dazu, dass in zwei Zellen Text über die Zellenränder geschrieben wird... -- Volker.haas 14:16, 30. Jan. 2009 (CET)

Danke schon mal dafür. Wobei die Namen sind bei mir in der PDF nicht zentriert, nur die Überschriften. Was mir jetzt noch auffällt ist die Spalte 1986, 1990 und 2000 ca. doppelt so breit als die anderen dargestellt wird, obwohl dort nur wenig Inhalt drin ist. Ein weiteres ähnliches Beispiel ist Gute Zeiten, schlechte Zeiten, auch dort ist die Spalte 1992 und 2000 breiter (ich habe natürlich über "Neurendern erzwingen" die PDF neu generieren lassen damit ich auf jeden Fall die aktuelle Version sehe) -- Steffen2 15:07, 30. Jan. 2009 (CET)

Anmerkung: Wenn ich sage, ein Problem ist behoben, dann kann es im Zweifelsfall ein paar Tage dauern, bis die Software auf der Wikipedia aktualisiert ist (darauf habe ich keinen Einfluss). Bzgl. der unterschiedlichen Spaltenbreiten: ich habe ehrlich gesagt keine Ahnung. Das Ausrechnen der einzelnen Spaltenbreiten ist eine Wissenschaft für sich, ich müsste mir das im Detail anschauen um das zu erklären. -- Volker.haas 17:08, 30. Jan. 2009 (CET)

letzte gesichtete Version verwenden

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).

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)

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).

Ticket angelegt. he!ko 21:08, 30. Jan. 2009 (CET)

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)

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).

Blocksatz?

Bin ich der einzige, der hier gerne Blocksatz hätte? Die Funktion nennt sich schließlich "Buchfunktion" und zu einem Buch gehört nach meinem Empfinden Blocksatz, nicht nur aus ästhetischen Gründen. Daher die Frage: Sind es technische Probleme die das bei der Buchfunktion verhindern, oder ist es nicht erwünscht? --Tafkas ^{hmm?! +/-} 11:04, 30. Jan. 2009 (CET)

Ich denke auch, dass Blocksatz die Bücher professioneller aussehen lassen würde. --Kolossos 12:31, 30. Jan. 2009 (CET)

Blocksatz ohne Silbentrennung kann aber auch in die Hose geh'n. -jkb- 12:35, 30. Jan. 2009 (CET)

Ob die Software Silbentrennung unterstützt weiß ich nicht, dieser technische Aspekt wäre natürlich abzuklären. --Tafkas ^{hmm?! +/-} 12:47, 30. Jan. 2009 (CET)

Blocksatz auf jeden Fall, Silbentrennung sprachenbedingt. Evt. wäre es nötig, sowas wie Sprachtags einzuführen, falls in einer Fremdsprache zitiert wird, etwa Englisch. Dort wird anders getrennt. --Michael 16:50, 30. Jan. 2009 (CET)

Ich denke ebenfalls, dass dies professioneller aussehen würde. --Gruß Herrenberger D / B 12:58, 30. Jan. 2009 (CET)

Blocksatz ist prinzipiell kein Problem - es ist lediglich eine Konfigurationsoption. Ich stimme auch allen Vorrednern zu, dass Blocksatz das Aussehen verbessern würde. Da keine Silbentrennung unterstützt wird, kann das - wie oben gesagt - manchmal auch in die Hose gehen. Ich werde noch ein paar interne Tests machen, aber dann aller Vorraussicht die Konfiguration zu Blocksatz ändern. -- Volker.haas 13:07, 30. Jan. 2009 (CET)

Gute Idee! Das wollte ich auch schon posten, denn ich bin auch für Blocksatz, auch für die Möglichkeit, eine andere (kleinere) Schriftgröße wählen zu können - beides als Option; der Schriftgrößenwunsch ist schon gemeldet und die Entwickler kümmern sich wohl darum. --Wikinaut 19:07, 30. Jan. 2009 (CET)

Warum verwendet man hier eigentlich nicht gleich LaTeX als Setzsystem? Dann bräuchte man sich um viele der jetzigen Probleme nicht zu kümmern, sondern müsste nur die Wikisyntax in LaTeX-Syntax umwandeln und könnte dann wunderbare PDF-Dateien erstellen. -- ▪Niabot▪議論▪+/− 11:11, 6. Feb. 2009 (CET)

Die PDF Erzeugung wäre dann nochmal um den Faktor 4-8 langsamer. he!ko 17:59, 6. Feb. 2009 (CET)

Wiki2LaTeX scheint ein Projekt zu sein, was genau macht, was Niabot vorschlägt: [2] Hat jemand Erfahrung damit? --GluonBall 20:09, 6. Feb. 2009 (CET)

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)

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)

Bei WikiReader wurde es doch auch ohne Probleme ans Ende gesetzt? --Gruß Herrenberger D / B 18:21, 30. Jan. 2009 (CET)

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)

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)

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)

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 [3] 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)

Vorlage Zitat wird nicht gedruckt

Beispiel: Hahnenkampf_(Album) he!ko 14:15, 30. Jan. 2009 (CET)

siehe: http://code.pediapress.com/wiki/ticket/366 (innerhalb eines ref tags steht ein Gleichheitszeichen, was normalerweise benutzt wird, um benannte Argumente in Templates zu uebergeben. mediawiki ersetzt die ref tags allerdings vor dem expandieren...)

Knopf um bestehende Bücher nach Bearbeitung unter ihrem existierenden Namen speichern zu können

Wunsch: wenn ich ein buch lade und etwas daran rumändere wäre es schön, wenn ich anschließend einen button hätte "änderung unter gleichem namen speichern", also quasi die alte version zu überschreiben he!ko 14:18, 30. Jan. 2009 (CET)

Ich glaube irgendwann gestern habe ich da sowas gesehen, dann war's weg. -jkb- 16:12, 30. Jan. 2009 (CET)

Wäre für viele Anwendugnsfälle mit der Implementation von diesem Feature behoben. Ich habe den hier genannten Anwendungsfall noch als Kommentar aufgenommen. Jbeigel 18:33, 2. Feb. 2009 (CET)

Bilder im Text

Die Bilder im Text sind seltsam gebrochen, mal nehmen sie die gesamte Seite ein, mal stehen sie mitten im Text, mal sind sie mit dem Fuß am Anfang des Absatzes, mal ist an ihrem Kopf eine Zeile und dann bis zum Fuß nichts. Ist ein Lösung absehbar? --Michael 16:54, 30. Jan. 2009 (CET)

Könntest du bitte einen Beispielartikel nennen. -- Volker.haas 14:21, 2. Feb. 2009 (CET)

Alle Angaben beziehen sich auf die PDF-Vorschau bei Wikipedia. Der Fehler mit den fliegenden Bildern scheint behoben (oder nur kurz aufgetreten zu sein), dafür bleibt der Fehler mit den seitenfressenden Bildern bestehen, etwa bei Goethe. Bei Kant klafft nach einem Absatz über die Jahre bis 1753 eine Lücke von der Größe einer halben Seite. Bei Einstein wird sogar nur der erste Absatz ausgegeben! Dieser Fehler tritt auch bei der Buchvorschau auf. Frage von mir: Warum werden eigentlich gesonderte Dateien erstellt für die Buchdruckvorschau (Druck selbst kann ich keine Aussage treffen) und für die PDF-Ausgabe? Der Unterschied ist schon alleine wegen Blocksatz und Nichtblocksatz gewaltig. --Michael 16:40, 3. Feb. 2009 (CET)

Bildergrößen: Die von dir gesehenen Probleme sollten weitestgehend behoben sein. Gallerien werden nun besser layoutet - die waren die "Hauptschuldigen" in deinen Beispielen. Anmerkung zum Seitenumbruch im Artikel Kant, Abschnitt "1753": Dieser Seitenumbruch kann nicht verhindert werden. Grund ist die Art und Weise, wie Text um die Bilder fliesst. Das nächste Bild (Erinnerungstafel Kant) ist zu hoch um noch auf der vorherigen Seite abgedruckt zu werden. Potentiell könnte man stattdessen die nächsten Textabschnitte auf der jetzt halbleeren Seite abdrucken und das Bild erst danach. Dass hat aber den Nachteil, dass ein Bild eventuell weit vom zugehörigen Textabschnitt "weggeschoben" wird. Dies ist insbesondere problematisch, wenn viele Bilder verwendet werden. --> Eine Änderung der beschriebenen Strategie wäre sehr aufwändig, und ich hab momentan auch keine Idee wie man das Problem zuverlässig besser lösen könnte. --Volker.haas 14:23, 4. Feb. 2009 (CET)

Das der Einstein Artikel nicht komplett ausgegeben wird ist ein bekannter Fehler der behoben wird. -- Volker.haas 14:23, 4. Feb. 2009 (CET)

Warum unterschiedliche PDFs? Ein Grund ist, dass die verschiedenen PDFs auf die jeweiligen Anwendungen (einmal Druck, einmal eher Bildschirmausgabe) und Formate optimiert sind. Außerdem ist die für den Druck verwendete Rendering-Engine um den Faktor 3-7 langsamer als die auf Wikipedia verfügbare Version. -- Volker.haas 14:23, 4. Feb. 2009 (CET)

danke für die schnelle Lösung, leider ist mir beim Betrachten der Druckvorschau des Artikels Goethe bei Pediapress eine Kleinigkeit aufgefallen (Das Buch besteht nur aus dem Goetheartikel): Nach "Weitere Bilder" erscheint erst ein Querbalken am unteren Ende der Seite und die Bilder als Gallerie auf der nächsten. --Michael 19:42, 9. Feb. 2009 (CET)

Bildattribute ohne Bildbeschreibung

Hallo, wenn ein Artikel ein Bild enthält, dem ein formatierendes Attribut wie "upright" zugeordnet ist ohne eine Bildbeschreibung anzugeben, (bsp: [[Datei:Beispiel.jpg|thumb|upright]]) taucht im PDF das Attribut "upright" als Bildbeschreibung auf. Ist dies in der Buchdruck-variante ebenso? Gruß -- blunt. 21:41, 30. Jan. 2009 (CET)

Das wäre ein Fehler. Kannst du bitte einen Beispielartikel nennen? he!ko 21:59, 30. Jan. 2009 (CET)

Die habe ich grade schon mit einer Bildbeschreibung ausgestattet ;-) In Catherine Mégret habe ich meine Bildbeschreibung wieder revertiert. Da ist der Fehler im PDF aufgetreten. Ebenso bei Debi Mazar (mittlerweile ist das Bild beschrieben). -- blunt. 22:23, 30. Jan. 2009 (CET)

Du brauchst nicht reverdieren. Man kan auch von alten Versionen PDFs erstellen, also musst du nur die Version schreiben und fertig: PDF-Version von dieser HTML-Version. Bitte auch dran denken, das dieses Wort lokalisiert ist (hochkant). Der Umherirrende 22:31, 30. Jan. 2009 (CET)

kk. -- blunt. 22:34, 30. Jan. 2009 (CET)

Hilfe:Variablen#Generelle, konstante Variablen

Es scheint das diese Variablen alle nach "en.wikipedia" aufgelöst werden, siehe Externe Links der Seite oder meiner Benutzerseite. Zusätzlich ist der Seitenname nach den Namensraum komplett kleingeschrieben und die bei fullurl angebenden Parameter wurden nicht übernommen. Einige Variablen geben auch keinen (SITENAME, SCRIPTPATH, CONTENTLANGUAGE) oder einen falschen Wert (CURRENTVERSION) zurück. Der Umherirrende 22:55, 30. Jan. 2009 (CET)

Ich häng mal das Fehlverhalten von #iferror hier an. -- visi-on 01:56, 31. Jan. 2009 (CET)

Ticket he!ko 15:56, 31. Jan. 2009 (CET)

Buch erstellen (Toolbox) -> Infoangabe verwirrend: "Buch zeigen (4 Seiten)" --> "Buch zeigen (ca. 27 Seiten mit 4 Artikeln)"

Hallo, mir fällt gerade eine Sache auf, nämlich dass in meiner Toolbar angezeigt wird, dass mein Buch Buch zeigen (4 Seiten) hat. Das ist totaaal verwirrend. Es hat 4 Wikipedia-Artikel, ist aber 27 Seiten groß (inkl. Titelblatt und WP:GFDL). Diese echte Größe sollte angezeigt werden, oder zumindest zusätzlich.

Dazu schlage ich jetzt hier vor, den Text zu ändern (Beispiel) in

"Buch zeigen (27 Seiten mit 4 Artikeln)" --Wikinaut 20:42, 31. Jan. 2009 (CET)

Seiten nach Artikel ändern geht und sollte man machen. Die Seitenanzahl des PDF kennt man zu diesem Zeitpunkt jedoch noch nicht und kann sie deshalb nicht darstellen.he!ko 21:50, 31. Jan. 2009 (CET)

Verstehe und dachte mir das auch. Aber: man könnte (wenn bereits eine Generierung gemacht wurde, die Seitenzahl merken), die Seitenzahl des letzen "runs" als Schätzung verwenden:
"Buch zeigen (ca. 27 Seiten mit 4 Artikeln)" --Wikinaut 23:14, 31. Jan. 2009 (CET)

Für einzelne Artikel würde das noch gehen aber für alle möglichen Permutationen von Artikeln in Büchern nicht mehr. Weiterhin müsste diese Information in der Datenbank gespeichert werden, das wäre aus technischer Sicht ein großer Schritt. Ich denke mit der Umbenennung von "Seiten" zu "Artikel" wären 90% der Lösung. Hierzu müsste lediglich jemand MediaWiki:Coll-n_pages ändern. he!ko 16:08, 1. Feb. 2009 (CET)

Naja, es geht hier ja nicht nur um die deutsche Version. Im Englischen steht da "pages". Das müsste man prinzipiell in der Collection-Extension ändern und dann die Übersetzungen anpassen. Ich habe ein Ticket aufgemacht. Jbeigel 18:27, 2. Feb. 2009 (CET)

Die Änderung müsste auch bei "Seite hinzufügen" gemacht werden, was eigentlich "Artikel hinzufügen" lauten müsste. Das benötigt natürlich leider mehr Platz auf dem Bildschirm

Ja, prima, aber wer macht die Textänderung genau ? Ich habe keine entsprechenden Rechte. --Wikinaut 18:42, 1. Feb. 2009 (CET)

Ich habe im Translatewiki in den Systemnachrichten Translatewiki:MediaWiki:Coll-n pages/de, Translatewiki:MediaWiki:Coll-add page/de, Translatewiki:MediaWiki:Coll-remove page/de, Translatewiki:MediaWiki:Coll-rendering article/de den Begriff „Seite“ bzw. das projektspezifische „Artikel“ durch „Wikiseite“ ersetzt. Dies wird mit der nächsten Softwaresynchronisation live gehen. — Raymond ^{Disk. Bew.} 20:10, 3. Feb. 2009 (CET)

Einzelnachweis in Tabelle

... ist leer (^{[ ]}) Beispiel: Atlantische Hurrikansaison 2008 bei den Prognosen --Steef ³⁸⁹ 00:49, 1. Feb. 2009 (CET)

Dafür habe ich ein Ticket angelegt. Der Grund für den Fehler ist, dass eine "benamte" Referenz verwendet wird bevor sie definiert wird. Aus Programmierer-Sicht ist das etwas hässlich - aber wenn es im MediaWiki erlaubt ist, werd ich das wohl Problem wohl beheben müssen ;) -- Volker.haas 13:57, 1. Feb. 2009 (CET)

Sowas sollte eher im Artikel behoben werden. Das Wikipedia:WikiProject_Check_Wikipedia fährt auf solche Fehler ab. Vielleicht sollte man das dort mal ansprechen? -- Rosentod 14:42, 1. Feb. 2009 (CET)

? wo ist der Fehler? Es kann durchaus sinnvoll sein zuerst den namen zu verwenden und später zu definieren. sowas bitte nicht "korrigieren" da es nicht falsch ist ...Sicherlich ^Post 14:45, 1. Feb. 2009 (CET)

Wo ist das sinnvoll? Wenn ich im Quelltext ewig suchen muss, wo die ref definiert ist, weil es erst nach der erstmaligen Verwendung geschieht (ich wusste bisher gar nicht, dass das geht), dann ist das unschön. Das macht es viel aufwändiger, wenn man refs korrigieren will. -- Rosentod 14:49, 1. Feb. 2009 (CET)

etwa wie hier genannt in tabellen um deren lesbarkeit nicht völlig zu zerstören so dass sich nachher gar keiner mehr rausfindet :o) ... ich mache es auch bei einwohnerzahlen in infoboxen teiweise so. in der infobox am anfang nur die "kurzform" und die defintion im abatz einwohner. hat die schöne eigenschaft, dass ich später die infobox aktualisieren kann ohne im absatz einwohnerentwicklung rumspielen zu müssen. denn dort soll die info ja länger bleiben. ... gibt Sicherlich noch andere gründe ...Sicherlich ^Post 19:23, 1. Feb. 2009 (CET)

Wie schon genannt ist das bei Einwohnerzahlen sinnvoll, außerdem kann man (wenn dies sinnvoll erscheint) ganze Absätze vertauschen, ohne dass <ref name="tada">tüdelü</ref> und <ref name="tada" /> gegeneinander ausgetauscht werden müssen. --32X 19:11, 11. Feb. 2009 (CET)

Balkendiagramm / Timeline

wenn es schon irgendwo diskutiert wird dann sorry! Balkendiagramme wie etwa das erste unter Benutzer:Sicherlich/Diverse Vorlagen mag er nicht? Zumindest haben die PDFs die ich probiert habe das diagramm nicht dabei ...Sicherlich ^Post 01:48, 1. Feb. 2009 (CET)

Da scheint es noch ein Problem mit Timelines zu geben. Ticket he!ko 12:04, 1. Feb. 2009 (CET)

Formatvorlage Bahnstrecke wird nicht korrekt wiedergegeben

Vielleicht interessant: Die auf vielen hundert Bahnstrecken-Artikeln verwendete Formatvorlage Bahnstrecke wird nicht korrekt wiedergegeben. Siehe dazu Wikipedia Diskussion:Formatvorlage Bahnstrecke#Tabelle wird in der Buch-Funktion nicht korrekt wiedergegeben. --bigbug21 18:09, 1. Feb. 2009 (CET)

Da helfen nur spezielle Vorlagen für den Druck. Ich habe auf der Seite geantwortet. he!ko 20:14, 1. Feb. 2009 (CET)

Danke! --bigbug21 21:14, 1. Feb. 2009 (CET)

Funktion "Buch zeigen" ergänzen um Button oder Menüpunkt "Dieses Buch unter seinem Titel als persönliches Buch speichern"

Ich bevorzuge zur Zeit, mein Buch als persönl. Buch unter dem Buchtitel zu speichern. Wenn ich später Seiten(=Artikel) hinzufüge, muss ich diese Änderungen ja jedesmal (Menüpunkt "Speichere und teile dein Buch") wieder neu speichern (existierenden Buchartikel mit der vorherigen Zusammenstellung überschreiben) und den Wikipedia-Buch-Seitennamen in der ursprünglichen Form eintippen.

Es wäre sehr praktisch, dafür neben dem Titel oder im Buch-Speichern-Menu einen Button zu haben "Dieses Buch als persönliches unter seinem Titel zu speichern - oder dass dieser Seitenname automatisch (per AJAX) eingefüllt wird. Gleiches gilt auch für gemeinschaftliche Bücher. --Wikinaut 08:38, 2. Feb. 2009 (CET)

Gute Idee! Ich habe ein Ticket angelegt. Jbeigel 18:29, 2. Feb. 2009 (CET)

Bilder und Links deaktivieren

Kann man irgendwo einstellen, das man bei der Ausgabe keine Bilder und keine Links (also keine blaue Schriftfarbe mit Unterstrichen) haben möchte? Wenn nicht, dann wäre das eine gute Zusatzoption. Oft möchte ich nur den Text haben ohne Bilder und ohne unterstrichene Wörter! MfG --15:14, 2. Feb. 2009 (CET) (falsch signierter Beitrag von 87.79.221.248 (Diskussion) 15:14, 2. Feb. 2009)

Die Links sind in den PDFs weder unterstrichen noch blau. --Mps 20:09, 2. Feb. 2009 (CET)

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

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)

Ist im nächsten Update behoben. he!ko 23:59, 2. Feb. 2009 (CET)

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)

Interne Verweise (zu anderen Artikeln in einem Buch) sind mit "→ xyz" sehr hübsch markiert

Möchte etwas melden, das keine Mehrarbeit macht, weil es schon implementiert wurde, und ich es beim Lesen(!) meines Buches auch bemerkt habe: dass Verweise innerhalb eines Buches sehr schön → markiert sind. Klasse ! --Wikinaut 00:37, 3. Feb. 2009 (CET)

An sich stimme ich zu - nur bei Bindestrich-Wörtern mit zwei Links (z.B. Köln-Nippes) sieht es nicht gut aus, wenn hinter dem Bindestrich noch ein Pfeil folgt. -- DrTom 23:07, 7. Feb. 2009 (CET)

Bei Neugenerierung und Speichern sollten schon bestehende Kategorien nicht gelöscht werden

Beispiel: ich erarbeite gerade Materialien zur Geschichte des Transistors und hatte die [[Kategorie:Transistor|Geschichte: Materialien zur Geschichte des Transistors]] vergeben. Durch Hinzufügen neuer Artikel und Kapitel musste ich diese Seite mehrfach neu speichern, wodurch "natürlich" auch die bisherigen Kategorien verloren gingen, mit Ausnahme der automatischen Kategorie [[Kategorie:Wikipedia:Bücher]].

Vielleicht gibt es eine Lösung für das Problem der (bei Neugenerierung) verlorenen Kategorien. --Wikinaut 00:51, 3. Feb. 2009 (CET)

Ich halte es für problematisch Bücher (insb. persönliche) den Kategorien hinzuzufügen. Mittelfristig soll es ein von einem Benutzer:BücherBot generiertes Bücherregal geben. Dieses nutzt u.a. Schlagworte (erzeugt aus im Buch häufigen Kategorien-Namen) als Ordnungssystematik. he!ko 10:34, 3. Feb. 2009 (CET)

Wäre es nicht eventuell besser innerhalb eines eigenen Namensraumes (Bücher:) alle Bücher abzulegen und auch Bücherregale, so wie weitere, noch nicht vorhandene, aber denkbare nur mit diesen Büchern zusammenhängende Webseiten? --Michael 17:04, 3. Feb. 2009 (CET)

Siehe hierzu Abschnitt #Wie ware es mit Namespace Buch: ? Jbeigel 17:27, 6. Feb. 2009 (CET)

Einzelne Abschnitte

Ist es möglich, aus längeren Artikeln auch nur einzelne Abschnitte ins Buch einzufügen, z.B. über [[U-Boot#Technik|U-Boot-Technik]]?-- КГФ, Обсудить! 13:24, 3. Feb. 2009 (CET)

Das ist leider nicht möglich. -- Volker.haas 14:24, 4. Feb. 2009 (CET)

Gedichtdarstellung

Wäre es schwierig, die Funktion <poem> zu integrieren? Gruß --Summ 13:37, 4. Feb. 2009 (CET)

Das ist ein bekanntes Problem und wird behoben. -- Volker.haas 14:25, 4. Feb. 2009 (CET)

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)

Grundsatzfrage: Parsen von Wiki-Markup oder HTML

Wenn man sich einen Teil der obigen Vorschläge und Fehler ansieht, gelangt man zur Überlegung, ob es nicht besser ist, anstelle des Wiki-Markups das XML-Dokument (z.B. Mononbook) zu parsen. Einige Fehlerbilder:

• Vorlagen werden nicht eingefügt, siehe Hauptseite
• Variablen werden häufig nicht eingefügt, z.B. {{CURRENTDAY}} im Titel, siehe oben
• Parser-Tags müssen offensichtlich einzeln angepasst werden, siehe <poem>, siehe oben
• Parser-Funktionen werden völlig ignoriert, {{#...: }}
• Einschlüsse aus anderen Seiten wie OSM sind völlig undenkbar

Eigentlich müsste die Bibliothek (Render-Engine) mwlib genau so parsen, wie es die MediaWiki-Software realisiert. Die ist aber u.U. auf verschiedene Erweiterungen angewiesen, die ebenfalls in die mwlib eingepflegt werden müssen. Oder mit anderen Worten, bei jeder Änderung des Parsers einschließlich der MediaWiki-Erweiterungen muss mwlib angepasst werden.

Da XHTML, in der die Seitenausgabe erfolgt, alle Informationen enthält und zudem mit einem festen, wohl definiertem Satz an Tags auskommt, sollte das Parsen von XHTML eigentlich sinnvoller erscheinen. Ausschlüsse (display: none) und Anpassungen an den Druck wären über CSS oder XML stylesheets realisierbar, die sich auf dem Wiki notieren ließen.

Siehe auch zugehöriges Ticket auf pediapress.

Mir ist sehr wohl klar, dass dies einigen Programmieraufwand bedeutet. Den aber lieber heute als in ferner Zukunft. --RolandUnger 08:36, 5. Feb. 2009 (CET)

Nein es ist umgekehrt. Die Entwicklung eines eigenen Parsers war viel Programmieraufwand, den wir nicht ohne guten Grund betrieben haben. Nur zu gerne hätten wir gerne direkt die HTML Ausgabe des MW genutzt. Das Problem ist, dass im MW kein wirklicher Parser existiert, sondern das Markup über reguläre Ausdrücke in ein nicht wohl geformtes HTML gewandelt wird, welches wiederum mit Tidy zu XHTML repariert wird. Das resultierende HTML enthält nicht mehr genug semantische Informationen über die Dokumentstruktur, als dass man dieses sinnvoll in andere Formate wandeln könnte. Siehe hierzu auch HTML to PDF, why so hard? vom Brion Vibber. Nicht zuletzt gibt es deswegen auch über 30 (großteils gescheiterte) Projekte die versuchen MW Markup zu parsen. Die oben genannten Probleme (includeonly, Variablen, Parser-Funktionen, was ist OSM?) sind abgesehen von Parser-Tags (aus Extensions und derer gibt es hunderte) behoben, bzw. haben nie bestanden. Erweiterungen (genauer, deren Parser-Tags) sind aber sicherlich ein Thema, wie auch die Notwendigkeit den Parser parallel zum MW zu pflegen. Es ist deshalb geplant das Übel an der Wurzel zu packen und mittelfristig einen ordentlichen Parser ins MW zu integrieren. he!ko 23:23, 12. Feb. 2009 (CET)

Ort für Weblinks

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)

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)

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)

Die Fußnoten wären auch eine nützliche Idee für die Zukunft. --RolandUnger 14:44, 6. Feb. 2009 (CET)

Buchfunktion langsam / defekt

Der Server zur PDF-Erstellung ist momentan überlastet. Hintergrund ist wohl ein Heise-Artikel über die Buchfunktion. Am besten später nochmals probieren. he!ko 16:39, 5. Feb. 2009 (CET)

Das war ja schon mal. Da es sich aber um ein Effekt der public relations handelt, kann man sich damit ohne weiteres abfinden. -jkb- 17:21, 5. Feb. 2009 (CET)

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.?)--Harry_Disk^+/-_Bau 19:14, 5. Feb. 2009 (CET)

bzgl. "buch löschen" - das problem hatte ich auch :) ...Sicherlich ^Post 19:17, 5. Feb. 2009 (CET)

Wie wäre es mit "Buch vergessen"?--Eloquence 19:26, 5. Feb. 2009 (CET)

Buch-Charge leeren?--Harry_Disk^+/-_Bau 21:28, 5. Feb. 2009 (CET)

Nee, „Buch vergessen“ erinnert an das weitverbreitete „Passwort vergessen“. Würde also genau das Gegenteil meinen. --Mps 11:34, 6. Feb. 2009 (CET)

"Buch verwerfen"? --GluonBall 14:51, 6. Feb. 2009 (CET)

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)

Währe dann "(Buch-)Session beenden" ne möglichkeit?--Harry_Disk^+/-_Bau 16:55, 9. Feb. 2009 (CET)

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)

Vorschläge

Zunächst mal herzliche Gratulation zu dieser wirklich vielversprechenden Funktion. Zwei Verbesserungsvorschläge könnte man u.U. einarbeiten:

• Die Bilder sind in der pdf-Version ausgesprochen großzügig dimensioniert. Könnte man vielleicht diese standardmäßig etwas kleiner darstellen oder individuell deren Größe vor dem Erstellen festlegen?
  • In den nächsten Tagen sollte die neueste Version online sein, in der sich die Skalierung der Bild besser am Original orientiert. Folgender Ansatz wird in der neuen Version gewählt: Bilder die als "thumb" oder miniatur Ansicht eingebunden werden, sind dann ca. 1/3 der seitenbreite groß (falls keine explizite breitenangabe gemacht wurde. falls bei thumbs eine breite größer als der standardwert von 180 pixeln angegeben wird, wird das bild bis auf 2/3 der seitenbreite vergrößert. --> Im Normalfall sind Bilder kleiner als bisher, können aber in der maximalen Größe etwas breiter als bisher werden. Ich hoffe ich habe mich verständlich ausgedrückt ;) -- Volker.haas 15:49, 6. Feb. 2009 (CET)

Klingt interessant, dann werde ich mal gespannt auf die neue Version warten. Danke für die schnelle Antwort. --Anamnesis 16:06, 6. Feb. 2009 (CET)

• Mir persönlich würde Blocksatz wesentlich besser gefallen und das Lesen deutlich erleichtern. Möglicherweise könnte man auch diese Einstellung optional anbieten. Wurde bereits weiter oben angesprochen.

Schöne Grüße, --Anamnesis 12:57, 6. Feb. 2009 (CET)

Eigenes Vorwort

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)

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)

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)

Danke. Ich auch :-)

Tabellen sind sehr bearbeitungsbedürftig...

Tabellen werden zur Zeit sehr mangelhaft dargestellt.

• Bilder werden nicht zentriert ("center") dargestellt; Beispiel: Briefmarken-Jahrgang 1949 der Deutschen Bundespost Berlin

ist behoben --he!ko

• Grausame Darstellung von Briefmarkenblocks der Deutschen Bundespost Berlin, Bilder überschneiden andere Zeilen

Ticket --he!ko

• WARNING: Table could not be rendered - ouputting plain text. Potential causes of the problem are: (a) table contains bei Briefmarken-Jahrgang 1961 der Deutschen Bundespost Berlin

Ticket --he!ko

• Hmm... Ist wirklich eine Dateigrösse von 35.411.572 Byte notwendig für einen Ausdruck von Briefmarken-Jahrgang 1969 der Deutschen Post der DDR?

Ich hätte gern ein Buch zusammengestellt aus allen Berliner Briefmarkenjahrgängen, aber irgendwie zögere ich noch... Momentan sehe ich dies als netten Versuch an, der noch etwas unterfüttert werden muss... Gruss --Nightflyer 23:59, 6. Feb. 2009 (CET)

Danke für die Hinweise! --he!ko

Fehlende Seiten

Mir ist in verschiedenen von mir erstellten Büchern aufgefallen, dass manchmal einzelne Seiten, die im Buch klar enthalten sind, dann im PDF fehlen. Zum Beispiel "Iraklio" in meinem Buch "kretakompendium". Ich habe testweise ein neues Buch mit "Iraklio" und einer anderen Seite erstellt - in diesem Fall enthält das PDF alles. Dieser Fehler wäre natürlich sehr ärgerlich, wenn er sich auch im Druck bei Pediapress zeigen würde. Ist schon etwas über diesen Bug bekannt?

Du meinst dieses Buch (übrigens sehr schön gemacht!) oder? Ich kann das Problem reproduzieren, leider aber noch nicht nachvollziehen. Ist an diesem Artikel irgendetwas beonderes? In der Vorschau des gedruckten Buches fehlt es auch im Inhaltsverzeichnis. Ticket --- he!ko 12:44, 7. Feb. 2009 (CET)

Vermutlich fehlt ihm eine Schriftart. Bei mir haben auch immer Seiten gefehlt, ab genau der Stelle wo japanische Schrift vorkam. Erst als ich die dafür notwendige Schriftart installiert habe wurde alles angezeigt. --Mps 21:15, 7. Feb. 2009 (CET)

Also ich muss mal sagen, das die Einbettung von Schriftarten irgendwie schlecht gelöst ist. Sonst habe ich keine Probleme mit PDF-Dateien und japanischer Schrift. Jedoch bei den PDFs die Wikipedia erzeugt fehlt schlicht jedes japanische Zeichen. Irgendeine besondere Schriftart die es nur von Adobe gibt und keinen "Fallback" bereitgestellt? -- ▪Niabot▪議論▪+/− 22:06, 7. Feb. 2009 (CET)

An dem Artikel über Iraklio ist eigentlich nichts besonderes - auch auf vielen anderen Seiten des Buches gibt es griechische Schriftzeichen, ohne dass es Probleme gibt. Ich habe testweise ein kleines Buch erstellt [[[Benutzer:Wpoerner/Bücher/kretatestbuch|Buch]] mit den beiden Seiten "Chania" und "Iraklio" - dort werden beide Seiten im PDF einwandfrei dargestellt. Ich habe "kretakompendium" mehrfach erstellt und es scheint, dass erst ab einer gewissen Zahl von Seiten etwas verschwindet. Warum das aber immer "Iraklio" ist, bleibt mir ein Rätsel... Wpoerner 22:55, 7. Feb. 2009 (CET)

Ich habe das oben genannte Buch und auch das Oberallgäu Buch lokal mit der neuesten Version der Software getestet -> die fehlenden Artikel sind jetzt enthalten. Ehrlich gesagt, weiß ich nicht warum sie in der momentan aktiven Version fehlen und jetzt (lokal) gehen. In jedem Fall sollte das Problem aber nach dem nächsten Update behoben sein. -- Volker.haas 15:46, 9. Feb. 2009 (CET)

Prima - wann wird denn die neueste Version eingesetzt bzw. wo kann ich sehen welche Version aktuell benutzt wird? Wpoerner 20:12, 9. Feb. 2009 (CET)

Hi, ich habe dasselbe Problem mit meinem Buch Oberallgäu. Die Artikel "Landkreis Oberallgäu" und "Sonthofen" werden konsequent ignoriert. Ich habe das Buch auch gelöscht und neu angelegt und sowohl als PDF als auch als ODT ausgegeben. Immer das gleiche Ergebnis. Weiß jemand Abhilfe? --- gm 15:12, 8. Feb. 2009 (CET)

Layoutfragen

Guten Abend,

zunächst ein großes Lob für diese Buchfunktion. Meine Fragen: Welche Schriftart wird verwendet? Vermutlich Times? Wie groß ist die Schrift und wie groß der Zeilenabstand? Und kann man das selber einstellen?

Vielen Dank-

Schriftart ist DejaVu Serif (CJK Glyphen in Adobe Standardfonts), Schriftgröße 10 pkt, Zeilenabstand 15 pkt. Momentan ist das für den Nutzer noch nicht veränderbar. -- Volker.haas 15:48, 9. Feb. 2009 (CET)

Verschwundene Bilder?

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)

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)

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)

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)

Bilder mit "upright"

Bilder mit "upright" haben im PDF dieselbe Breite wie andere Bilder (in beiden Fällen mit "thumb"); meist führt dies zu wirklich riesigen Bildern. Sie sollten aber stattdessen eine Höhe haben, die der Breite anderer Bilder (ohne "upright") entspricht. Ist der Fehler schon bekannt? -- DrTom 22:58, 7. Feb. 2009 (CET)

Hinweis an die pediapress-Entwickler: „upright“ ohne weitere Angabe greift auf die Variable $wgThumbUpright = 0.75 zurück, skaliert also auf 75 % Breite. „upright“ mit Angabe einer Zahl, also z.B. upright=0.5 skaliert um diesen Faktor, hier also auf 50 %. Oder upright=1.2 skaliert auf 120 %. — Raymond ^{Disk. Bew.} 01:06, 8. Feb. 2009 (CET)

Danke für die Info. Ich habe ein Ticket angelegt und wir werden das beheben. -- Volker.haas 17:07, 9. Feb. 2009 (CET)

Wie kann ich die Seitenanzahl abschätzen?

Hab jetzt grade mein erstes Buch auf pediapress.com hochgeladen, dann war das Buch aber viel zu groß(3353 seiten!) weil ich das mit den seiten irgendwie falsch verstanden habe. Bei mir stand in den tools "Buch zeigen(100 Seiten)" obwohl da ja eigentlich Artikel gemeint waren. Jetzt dachte ich mit der Oberbegrenzung pro Buch "828 Seiten" wären auch solche "Seiten" (also Artikel) gemeintund hab daher das Limit etwas überzogen. Jz muss ich wohl einiges löschen und weiß aber nicht wie viel weil mir die "wahre" Seitenanzahlerst immer nach dem Hochladen angezeigt wird wenn das Buch zu groß ist.

Navigationslisten

Navigationslisten innerhalb des Artikels werden nicht angezeigt. --217.224.72.197 19:06, 8. Feb. 2009 (CET)

Könntest du bitte ein Beispielartikel nennen. -- Volker.haas 17:09, 9. Feb. 2009 (CET)

Navigationslisten machen im PDF keinen Sinn und werden deshalb über die Zuordnung zur Kategorie:Vom Druck ausschließen im Druck ausgeschlossen. --he!ko 20:08, 9. Feb. 2009 (CET)

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)

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)

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)

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)

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

externe Links - nicht unbedingt hübsch

Was vielleicht noch mal überarbeitet werden sollte, ist die Darstellung externer Verweise. Ich habe das gerade mal mit The Tangent ausprobiert:

Screenshot vom Ergebnis

Abgesehen davon, dass der zweite Weblink seltsam eingerückt ist (Bug?):
Das mit den eckigen Klammern mag mir nicht so recht gefallen.

Vorschlag: Statt [http://wikipedia.de Deutsche Wikipedia] zum Beispiel Deutsche Wikipedia (http://wikipedia.de) ausgeben.

Hoffe, der Vorschlag findet Zustimmung.

Liebe Grüße, Tuxman

Ist vermutlich alles auf das referenzierte Ticket zurückzuführen. -- Volker.haas 17:40, 9. Feb. 2009 (CET)

Vorlagen nicht drucken/Sonstiges nicht drucken

Hi!

Der Abschnitt Hilfe:Buchfunktion/für Experten#Die Darstellung verbessern ist für mich nicht hinreichend verständlich. Unterpunkt b) klingt für mich so, als ob man einen Artikel, den man nur teilweise in "sein" Buch aufnehmen will, bearbeiten könnte und sollte, indem man alles, was nicht ins Buch soll, mit {{ImDruckVerbergen| ...}} markiert. So könnte man z.B. die Literaturliste vom Druck ausschließen, oder die Weblinks. Aber irgendwie zweifele ich, dass das der Sinn der Vorlage "ImDruckVerbergen" ist.

Bei Unterpunkt c) ist mir nicht klar, ob man in zu druckende Artikel die neuen Vorlagen „DruckenNAMEDERVORLAGE“ einfügen muss, oder ob man einfach darauf achten muss, dass alle verwendeten Vorlagen entweder von selbst funktionieren, oder einen korrekt programmierten Vorlagenzwilling mit "Drucken" vor dem Namen besitzen. Wenn nämlich eine Druckversion dann einfach ganz anders aussehen kann, weil zur Erstellung abweichende Drucken-Vorlagen verwendet wurden (die u. U. nicht mehr mit den Original-Vorlagen aktualisiert wurden und daher Unsinn produzieren), dann muss man ja das Buch nochmal ganz durchlesen, bevor man es zum Druck gibt. Und in der Zeit, in der man es dann wieder liest, könnten sich die Vorlagen erneut ändern... argh!

Kann es mir bitte nochmal jemand erklären, bzw. die Erläuterungen im verlinkten Abschnitt präzisieren? --Emkaer 11:53, 9. Feb. 2009 (CET)

zu b) Nein, das ist nicht der Sinn. Es geht eher darum in Vorlagen (und ggf. vereinzelt auch in Artikeln) Inhalte auszuschließen, die das Erscheinungsbild stark beeinträchtigen oder in gedruckten Versionen nutzlos sind. Solche Änderungen sollten für alle von Nutzen sein und nicht für da persönliche Buch genutzt werden (obwohl man das könnte).

zu c) gemeint ist ein korrekt programmierter Vorlagenzwilling. Klar ist, dass diese auch gepflegt werden müssen. Die Problematik, dass sich Vorlagen (und auch Artikel) ändern können existiert generell. --he!ko 20:43, 9. Feb. 2009 (CET)

Zusatz-Text für's Buch?

Und noch ein Feedback/Wunsch:

Es sollte möglich sein, ergänzende Texte zu der Zusammenstellung von WP-Artikeln hinzuzuschreiben. Z.B. als Einleitung. Oder wenn ein Artikel zu einem (für die Zusammenstellung) benötigten Thema nicht vorhanden ist, bzw. wenn nur ein kleiner Teil eines Artikels benötigt wird (z.B. nur der Teil einer BKL-Seite, dessen Artikel dann auch im Buch vorkommen sollen).

Wenn man einfach etwas in seine Buch-Seite hineinschreibt, dann wird das jedoch bei der Erstellung des PDFs übersprungen. Eine Notlösung wäre m.E., dass man in seinem Benutzer-Namensraum eine Seite anlegt, z.B. die Einleitung. Deren Inhalt könnte man wohl auch in das Buch einfügen, und indem man die Artikeltitel ändert (z.B. so:

:[[Benutzer:Emkaer/Vorlage:Test|Einleitung]]

) ist dann über dem Artikel noch nicht einmal angegeben, dass die Seite aus dem Benutzer-Namensraum stammt. Sehe ich das richtig?

Schöne Grüße --Emkaer 16:12, 9. Feb. 2009 (CET)

Letzteres ist 100% richtig! Diesen Trick sollte man evtl. in die FAQ aufnehmen. --he!ko 20:48, 9. Feb. 2009 (CET)

Probleme im OpenDocument Text-Format

Und noch'n Bericht:

Habe gerade erstmals ein Buch als "OpenDocument Text" bestellt und mit dem OpenOffice.org 2.2.1 Writer geöffnet. Die Datei unterscheidet sich stark vom Druckbild der PDFs; meiner Ansicht nach ist das bisher deutlich schlechter.

• - Es gibt keine Kapitelüberschriften.
• - Es gibt kein Titelblatt.
• - Es gibt keine Seitenzahlen, Kopf- oder Fußzeilen.
• - Es gibt teilweise keine Weblinks (jedenfalls nicht ausgeschrieben, so dass sie gedruckt etwas nützen würden).
• - Es gibt keine Ausgeschriebenen Links zu Wikipedia, zum abgedruckten Artikel, zur Versionsgeschichte.
• - Es gibt keine Autorenlisten.
• - Es gibt keinen Lizenztext am Ende.

Kosmetische Mängel sind in meinen Augen:

• - Zwischen den Artikeln (d.h. vor dem nächsten Artikeltitel) ist kaum Zwischenraum.
• - Die unterschiedlichen Überschriften-Ebenen unterscheiden sich nicht hinreichend.
• - Manchmal ist nach einer Überschrift1 ein Seitenumbruch, obwohl unmittelbar eine Überschrift 2 folgt. Manchmal sind auch Überschrift und Textabsatz durch Seitenwechsel getrennt.
• - Aufzählungen sind nicht eingerückt, zwischen Aufzählungspunkt und Text ist kein Abstand.
• - Bildunterschriften in Info-Boxen misslingen manchmal (und stehen dann nicht unter dem Bild).
• - Aus unerfindlichen Gründen gibt es manchmal zwei leere Seiten.
• - Grafiken sind immer (?) links ausgerichtet. Manchmal wird die Überschrift darüber bis zum rechten Rand der Grafik vorgeschoben.
• - Weblinks können grundlos immer weiter eingerückt werden.
• - Einzelnachweise sind als Fußnoten gestaltet (Abweichung vom WP-Standard mit Endnoten). Zwischen Fußnotenzeichen und Fußnote ist dabei keinerlei Zwischenraum; weitere Zeilen einer Fußnote sind entsprechend nicht eingerückt (hängend). Die Fußnoten sind über das ganze Buch fortlaufend nummeriert.
• - Manchmal werden Bilder oder sogar Texte nicht dargestellt (Bild in Unknown Armies und Text des Abschnitts Unknown Armies#Kritischer Erfolg).
• - Mit dem Parameter "framed" eingebundene Bilder sind nicht gerahmt und haben keine Bildunterschrift (Beispiel mit I. Asimov).
• - Die Symbole für "Commons", "Wikiquote", "Wikinews" u.ä. sitzen zu tief (wie "tiefgestellt").

Diese ganzen Kritikpunkte sollen natürlich nicht darüber hinweg täuschen, dass die Buchfunktion eine tolle Sache ist und ich weitere Verbesserungen daran sehr begrüßen würde. Auch in den bisherigen Modi PDF und ODT entstehen tolle Dokumente aus Wikipedia-Artikeln! Wenn ich ein "Buch" erstellen und kommerziell drucken lassen würde, z.B. 20 oder 30 Euro zahlen würde, dann würde ich mich aber über eine Reihe von Darstellungsmängeln sehr ärgern. Schöne Grüße --Emkaer 19:36, 9. Feb. 2009 (CET)

Erstmal vielen Dank für die umfassende Auflistung der Probleme. Das ODF-Format ist dafür gedacht, die Dokumente weiter zu bearbeiten. Alles kann (auch über Style-Vorlagen) den eigenen Wünschen angepasst werden. Das Dokument wird auch abhängig von dem Textbearbeitungsprogramm (OpenOffice, Wort, KOffice, ....) immer verschieden aussehen und die Programme haben teilweise Probleme mit der Komplexität des Dokuments - wer die Arbeit an längeren Texten in Word kennt und sich dann vorstellt ganze Bücher mit floatenden Bildern, Fußnoten, Formeln in Word zu schreiben, der versteht was ich meine. Klar ist aber auch, dass die ODF Software noch etwas Liebe braucht. Vieles kann man über bessere Styles erreichen und wenn jemand mithelfen möchte die Software zu verbessern sind wir dankbar.

Das Thema fehlender Lizenzhinweise ist ein wichtiges Problem und ich habe hierzu ein Ticket aufgemacht.

Die gedruckten Bücher werden wiederum mit einer anderen Software (TeX) gesetzt. In der Regel sieht das Druckbild sehr gut aus (siehe Beispiel PDF) - vereinzelt kann es aber zu Darstellungsfehlern kommen, die aber den Nutzwert des Buches kaum schmälern. --he!ko 21:19, 9. Feb. 2009 (CET)

Vielen Dank für Deine freundlichen Antworten zu diesem und den obigen Themen. (Auch allgemein "Respekt!" für das Engagement, mit dem hier die Feedbacks bearbeitet werden.)

Es stimmt: In ODF-Dateien kann man ja Kapitelüberschriften, Seitenzahlen und ein Titelblatt auch nachträglich noch selbst einfügen, ohne dass es allzu großen Aufwandes bedürfte. Außer dem Lizenz-Kram sind es ansonsten ja wirklich Kleinigkeiten, die zu verbessern aber einiges an Verständnis erfordern dürfte (das mir leider fehlt).

Das von Dir verlinkte Beispiel-PDF des geTeXten Buches überzeugt mich - viele Probleme der PDFs und ODTs sind darin gut gelöst. In so ein Buch kann man auch investieren. Das bringt mich auf eine Idee: Ich sagte oben: Wenn ich ein "Buch" erstellen und kommerziell drucken lassen würde, z.B. 20 oder 30 Euro zahlen würde, dann würde ich mich aber über eine Reihe von Darstellungsmängeln sehr ärgern. - Dagegen könnte man doch etwas tun, indem man die PDF-Funktion genau solche PDFs erstellen lässt, wie auch das professionelle Druckbild von PediaPress sein würde. Eben wie das Beispiel-PDF. Ich würde mir dann, bevor ich ein Buch in Auftrag gebe, das PDF (als Druckvorschauf quasi) nochmal anschauen und ggf. noch Veränderungen an den Artikeln vornehmen, wenn es zu Darstellungsfehlern käme. Vielleicht klingt das ungewöhnlich perfektionistisch, aber so bibliophil bin ich immerhin, dass mehr als einzelne Druckfehler in von mir zu verantwortenden Büchern (und wenn ich's "On-Demand" drucken lasse, dann muss ich es verantworten ;-) ) mich sehr stören würden. Die Frage also:

Kann man das PDF so erstellen, dass es dann aussieht wie das gedruckte Buch? Schöne Grüße --Emkaer 01:12, 10. Feb. 2009 (CET)

Wir denken da schon länger drüber nach, auf der Website neben der Vorschau auch die komplette Druckvorlage anzuzeigen. Leider dauert deren Generierung viel zu lange, als dass wir diese Funktion regulär anbieten könnten. Wir denken aber über eine evtl. etwas versteckte Lösung für Experten nach. he!ko 17:02, 12. Feb. 2009 (CET)

P.S.: Vielleicht solltest Du, He!ko, mal hier vorbeischauen? Ich verstehe, dass es da Interessenkonflikt-Bedenken geben könnte; aber m.E. sollte die WP irgendwie (wenn nicht im ANR, dann im WP-NR) über den Anbieter der Druckwerke informieren. --Emkaer 01:17, 10. Feb. 2009 (CET)

Da mag ich mich nicht einmischen. he!ko 17:02, 12. Feb. 2009 (CET)

Englische Textbausteine bei Pediapress

Etwas, was mir gerade erst aufgefallen ist: Die Bildunterschriften sind auf englisch, beispielsweise "Figure 1", genauso wie der Absatz unter "Referenzen" in der Druckvorschau auf Pediapress. Ob dies auch bei der PDF so ist, habe ich nicht geprüft. Dieser Fehler tritt bei allen Artikeln auf. --Michael 19:38, 9. Feb. 2009 (CET)

Danke für den Hinweis! he!ko 21:37, 9. Feb. 2009 (CET)

Zusätzliches Format gewünscht: LaTeX

Wäre es möglich, die Bücher auch als LaTeX-Quellcode anzubieten? -- Rosentod 07:59, 10. Feb. 2009 (CET)

Prinzipiell ja, da müsste aber erst jemand einen LaTeX-writer entwickeln. Es gibt jedoch einen experimentellen DocBook writer. he!ko 17:04, 12. Feb. 2009 (CET)

Also kann man das nicht so bald erwarten? LaTeX wäre halt für die Weiternutzung ein sehr geeignetes "Format". Du schriebst oben, dass der Weg über LateX bei der PDF-Generierung deutlich langsamer wäre. Wenn man den letzten Schritt den Endusern überließe und nur den LaTeX-Quellcode ausgeben würde, wäre sehr viel Rechenleistung eingespart und die Enduser könnten selbst Korrekturen und Modifikationen für die Ausgabe durchführen. Wenn dann das Endergebnis als PDF bei Pediapress hochgeladen werden könnte, würden sich auch hinsichtlich der gedruckten Bücher viel mehr Möglichkeiten ergeben. -- Rosentod 17:46, 12. Feb. 2009 (CET)

lange Lemmata

Etwas exotisch, aber lange Lemmata ohne Leerzeichen wie z.B.

• Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch
• Gorsafawddacha'idraigodanheddogleddollônpenrhynareurdraethceredigion oder
• Taumatawhakatangihangakoauauotamateaturipukakapikimaungahoronukupokaiwhenuakitanatahu

werden nicht umbrochen; das führt zu über den Rand gedruckten Artikelüberschriften. Grüße, -- Ukko 15:02, 10. Feb. 2009 (CET)

Vielleicht ist das ja gar nicht so schlimm. In der Wikipedia ragen sie schließlich auch über den Rand hinaus, z.B. in der , oder wenn man das Browserfenster verkleinert, oder die Schrift vergrößert.

Gut wäre aber, wenn sichergestellt wäre, dass dann das fettgedruckte Wort zu Beginn des Artikels vollständig lesbar ist. --Emkaer 15:55, 10. Feb. 2009 (CET)

Auf einem Blatt Papier kann man aber den Artikelinhalt nicht seitlich wegscrollen, um den Text neben dem Rand lesen zu können. --32X 19:13, 11. Feb. 2009 (CET)

JUHUU! ich denke dieses Problem steht symbolisch dafür, dass die meisten größeren Probleme inzwischen identifiziert wurden :) Wir bemühen uns diese sukzessive zu bearbeiten. Nochmal einen großen Dank an alle die auf dieser Seite mitgeholfen haben die Buchfunktion zu verbessern. he!ko 16:53, 12. Feb. 2009 (CET)

Vorlage

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