Benutzer Diskussion:Dirk Huenniger/wb2pdf/Requests – Wikibooks, Sammlung freier Lehr-, Sach- und Fachbücher

Benutzer Diskussion:Dirk Huenniger/wb2pdf/Requests – Wikibooks, Sammlung freier Lehr-, Sach- und Fachbücher
Zum Inhalt springen
Aus Wikibooks
Benutzer Diskussion:Dirk Huenniger
wb2pdf
Letzter Kommentar:
vor 3 Jahren
von 2A04:4540:6600:1300:B83C:4C21:1247:1760 in Abschnitt
Bilder werden teils ignoriert
Diese Seite enthält Gedanken für Erweiterungen:
Unter
Wünsche
stehen Ideen, die die Konvertierung verbessern können.
Unter
Vorschläge
stehen Überlegungen, wie etwas in die Praxis umgesetzt werden kann.
Vorlagen
sind ein schwieriges Thema und bekommen deshalb einen eigenen Abschnitt.
Mit
Ja
sind Punkte gekennzeichnet, die verwirklicht wurden.
Mit
Nein
sind Punkte gekennzeichnet, die doch nicht sinnvoll sind oder die nicht umgesetzt werden können.
An verschiedenen Stellen stehen
Fragen
, deren Beantwortung für das künftige Vorgehen hilfreich wäre.
Im
Archiv
stehen erledigte Punkte.
Wünsche
Bearbeiten
Letzter Kommentar:
vor 14 Jahren
4 Kommentare
2 Personen sind an der Diskussion beteiligt
Wikijunior Großkatzen
Bearbeiten
Bei Videos Video nicht herunterladen sonderen lediglich verlinken.
Blender Manual
Bearbeiten
There are images inside Headings in der Blender Manual. Don't know if you can do that with LaTeX.
Größe und Position von Bildern
Bearbeiten
Bild und Beschreibung nebeneinander
Das ist in einigen Fällen sinnvoll, vor allem bei längerer Beschreibung. Beispiel: in
Datei:Wikijunior Europa.pdf
die Schengen-Staaten auf Seite 20. Ohne diese Änderung blieb eine große Lücke. Diese Anpassung hat Löcher entfernt, dadurch einen schöneren Eindruck geschaffen und Seiten eingespart. --
Jürgen
14:28, 18. Nov. 2010 (CET)
Beantworten
Ich denke ich werde das sobald nicht einbauen. Als Work arbound bieten sich Tabellen an. Anderfalls gehen auch noch benutzerdefinierte Templates in Latex und Mediawiki.
Dirk Huenniger
14:14, 21. Mär. 2011 (CET)
Beantworten
Will sich
Jürgen
drum kümmern.
Dirk Huenniger
17:45, 9. Jan. 2012 (CET)
Beantworten
Parser Schreibweise Optimieren
Bearbeiten
do _ <- string "<"
bla
_ <- char '/'
_ <- char '>'
durch
between (char '<') (string "/>") bla
ersetzen. Oder Pfeilschreibweise von frisby verweden.
(->>) = (>>)
(<<-) = liftM2 const
Vor dieser Operation ist es sinnvoll automatisierte Tests zu erstellen.
Dirk Huenniger
12:49, 24. Feb. 2012 (CET)
Beantworten
Vorschläge
Bearbeiten
Letzter Kommentar:
vor 7 Jahren
2 Kommentare
1 Person ist an der Diskussion beteiligt
Kleinigkeiten
Bearbeiten
"articlepath" (
) implementieren die auf allen MediaWiki läuft.
Im HTML mode, Nummerierung von schon numerierten Artikeln rauswerfen, also falls
$wgDefaultUserOptions['numberheadings'] = 1;
gesetzt ist. Workarounds: (1) "-wiki" Option an Stelle, aber man muss dann Templates definieren. (2) $wgDefaultUserOptions = 0 setzen während der Artikelkollektion.
Ja du kannst aber z.B. auch die Option -m --mediawiki verwenden und brauchst dann keine Templates definieren. Das Implementieren der Templates betrifft nur die Optionen -i und -t
Dirk Hünniger
18:12, 11. Feb. 2019 (CET)
Beantworten
Im HTML mode, sollte man eine print/no print feature habe. Für Pediapress,
class="noprint"
erlaubt etwas nicht ins Print aufzunehmen und
class="onlyinprint"
nur für print. Wäre praktisch für gewisse mediawiki templates und geht mit PediaPress.
für span ist class noprint implementiert ferne gehen die noinclude tags von mediawiki.
Dirk Hünniger
18:12, 11. Feb. 2019 (CET)
Beantworten
Prioritäten
Bearbeiten
Letzter Kommentar:
vor 13 Jahren
5 Kommentare
2 Personen sind an der Diskussion beteiligt
Summary
Bearbeiten
Here we will sum up contributions by english speaking users. Please add a new section describing your ideas in detail somewhere on this page and add little summary, typically not much more than 3 sentences in this section. Whenever we want to work on wb2pdf we will look at this section for interesting tasks. The following section "Zusammenfassung" is the same for german speaking users.
Quite important
Not so imporant
footnotes inside headings, maybe better keep it as it is.
nice to have (quite unimportant)
rlm lrm html entities left to right mark, right to left mark. And lrm rlm unicode codes.
install font for >2^16 Unicode
dhunparseurl include is not nested. You can have the wrong pathname if you include something and write internal links after you included
color template does not work for second parameter
{{blau|Beispieltext|green}}. See also rot and grün
source tag with line numbering if requested
bdo tag
make definition of preformatted templates available to user
Zusammenfassung
Bearbeiten
Abgelehnte Wichtige Punkte
String und regex. Diese Sachen kann der User der das wirklich braucht leicht in load.py reinschreiben.
Dirk Huenniger
18:16, 8. Jan. 2012 (CET)
Beantworten
Bei LaTeX sind maximal 9 Parameter zulässig, bei Wiki kann es mehr Parameter geben. Diese Technische Beschränkung ist unlösbar. Jedoch gibt es nun einen algemeinen Template Mechanismus bei dem eine Manuelle Implementierung von Templates nicht mehr statfindet. Infsofern gibt es dieses Problem nicht mehr.
Dirk Huenniger
17:43, 9. Jan. 2012 (CET)
Beantworten
TemplateCode und TemplateCodeInside werden oft nicht wunschgemäß dargestellt. Ist ein Problem des Entwicklers (
Jürgen
) dieser Vorlagen. Mache ich also nix weiter dran. Hat er aber glaube ich auch mitlerweiler selbst gelöst.
Dirk Huenniger
17:43, 9. Jan. 2012 (CET)
Beantworten
Wichtig, aber weniger dringend
Die folgenden Punkte sollten nach und nach verwirklicht werden.
Beispielsweise wurde festgestellt, dass die Größe und Position von Bildern nicht immer optimal ist. So etwas kann in der tex-Datei umgesetzt werden, aber eine Automatik während der Konvertierung ist natürlich praktischer.
--
Jürgen
16:06, 30. Nov. 2010 (CET)
Beantworten
Bildbeschreibung neben ein Bild (macht Jürgen)
nice to have
parser Schreibweise optimieren. Hier ist bereits vielm passiert.
Dirk Huenniger
15:47, 7. Jun. 2012 (CEST)
Beantworten
Debian Packetierung
Bearbeiten
Deutsches Periodensystem hearusgenommen steht noch im reposity. Ist noch nicht im PDF über Anorganische Chemie für Schüler. Muss noch behoben werden.
Problem beim Englischen Wikibook calculus
Fonts
Bearbeiten
/usr/sharetexmf/web2c/updmap.cfg muss die Zeile "Map megafont.map" bekommen
Hier die megafont.map die das python skript generiert muss hier liegen.
./usr/share/texlive/texmf-dist/fonts/map/dvips/megafont/megafont.map
megafont.ttf liegt in /usr/share/texmf-texlive/fonts/truetype/megafont/
und /usr/share/texmf/fonts/truetype/megafont/
und ./home/dirk/.texmf-var/fonts/truetype/megafont/
generierte tfm liegen auch dort

UNKNOWN TEMPLATE
Sidenote

UNKNOWN TEMPLATE
YouTube link

{XZUSn7I-{}zNo}{Death of ACTA music video}
Es gibt ein problem mit hochgestellten schriften im homomorphism artikel ttf datein einhalten keine speziellen hochgestellten grlyphen als ersatz werden standartglypehn verwendet die dann jedoch nicht hochgestellt werden.
Flaggen
Bearbeiten
Definition in commands.tex
%Flaggen mit Rahmen
\newcommand{\fborderbox}[1]
{\setlength\fboxsep{0}\fbox{\includegraphics[width=1.0\linewidth,height=6.5in,keepaspectratio]{#1}}}
Ich bin mir nicht völlig sicher, ob die Änderung von \fboxsep sich tatsächlich nur innerhalb des Befehls \fborderbox auswirkt (Geltungsbereich der Änderung). Notfalls muss ein weiteres Klammerpaar um alles gesetzt werden.
Nutzung im Buch
\parbox[t]{1.0\linewidth}{
\begin{center}
\fborderbox{images/166.png}  % ersetzt hier den \includegraphics-Befehl
\end{center}
\raggedright{}Abb. 166: Die Flagge der Republik Irland.}
Eclipse Wiki
Bearbeiten
Letzter Kommentar:
vor 11 Jahren
1 Kommentar
1 Person ist an der Diskussion beteiligt
das geht nicht
aber das
grund
We could find the line that causes the problem.
Its:
let x = if (length l) > 1 then drop 1 l else l
in the definition of the function getLemma in the file UrlAnalyse.hs if you replace it buy
let x = l
Dirk Hünniger
10:37, 7. Mai 2014 (CEST)
Beantworten
Ich könnte auch Chinesisch reden
Bearbeiten
Letzter Kommentar:
vor 11 Jahren
1 Kommentar
1 Person ist an der Diskussion beteiligt
Dann aber bitte so
第4章 instead of 章4
第2页 instead of 页2
图8 instead of 图形8
and in Chinese you don't need to (and shouldn't) add spaces between words. I feel there're some extra ones added especially near links.
Dirk Hünniger
20:09, 25. Mai 2014 (CEST)
Beantworten
w:Internationale Mathematik-Olympiade
Bearbeiten
Letzter Kommentar:
vor 11 Jahren
6 Kommentare
2 Personen sind an der Diskussion beteiligt
Ich habe
mal mit
w:Internationale Mathematik-Olympiade
getestet, dabei sind mir folgende Punkte aufgefallen:
Teilweise gibt es noch englische Texte, die übersetzt werden sollten um die selbe Sprache zu haben wie das Wiki, aus dem der Text stammt. Das sind die Einleitung "On the 28th of April 2012 the contents ...", "Edits" und "User" in der Autorenliste, teilweise Erläuterungen zu den Lizenzkürzeln ("PD: This image is in the public domain.", etc.) und die Überschrift "Licenses" (wobei das diskutabel ist, da der Inhalt ja englisch ist, im Inhaltsverzeichnis sieht es trotzdem blöd aus).
Schöne Idee, für mich nur zu Aufwendig. Die Texte sollen verhindern das ich verklagt werde und diese in andere Sprachen zu übersetzen ist immer sehr problematisch. Deswegen sind ja auch die Lizenzen selbst alle Englisch.
Die Überschrift "Abbildungsverzeichnis" ist auf der gleichen Stufe wie die anderen Hauptüberschriften, hat aber keine Nummer. Falls das Absicht ist, verstehe ich diese nicht.
Das ist in Latex so üblich. Lässt sich bestimmt einstellen. Aber ich denke man sollte es nicht ändern
Im Abbildungsverzeichnis ist der Urheber von
Datei:Teodor von Burg with two Olympic gold medals.jpg
doppelt genannt, den Links nach einmal von Commons, einmal von de.wikipedia aus gesehen.
Diese Links sind zudem falsch, sie lauten nämlich
statt
Das werde ich bei gelegenheit
ändern
ist eingecheckt
Ursache ist wohl der Fall
nodeToLaTeX (Environment Tag (TagAttr "a" d) l)
in LaTeX Renderer.hs. Dieser ruft wikiUrlDataToString auf unlöst den Fall BaseURL aus woraus das Problem entsteht.
Dirk Hünniger
15:43, 6. Sep. 2014 (CEST)
Beantworten
Bei diesem Bild fehlt die Angabe der Lizenz.
Bei welchem?
URLs mit einem & sind falsch, es wird stattdessen immer ein & angezeigt. (Bsp: 66:
Das werde ich bei gelegenheit
ändern
. Änderung ist eingecheckt.
Ich habe das Interface mit einer https:-URL aufgerufen (also
), trotzdem zeigen alle internen Links auf die http:-Variante.
Das Programm arbeitet intern immer mit http und nie mit https. Es akzeptiert jedoch https urls die dann in http url umgewandelt werden als eingabe. So richtig wichtig finde ich das nicht und werde mich darum erst einmal nicht weiter kümmern.
Die Autorenliste sähe mehrspaltig vermutlich besser aus.
Das werde ich bei gelegenheit änderen Nee finde ich doch nicht gut. Ich denke es sieht so wie es ist besser aus.
Ich bin mir nicht sicher, in wie weit URLs für Links auf noch fehlende Seiten wirklich sinnvoll sind. In diesem Fall ist als Fußnote 18
angegeben. Gleiches gilt für URLs von ISBNs auf Spezial:ISBN-Suche und dem Link von der Überschrift Kategorien auf
. Sind an diesen Stellen die Angaben der URLs wirklich nützlich?
Naja ich weis nicht so recht. Eine unsinninge URL zuviel ist immernoch besser als eine fehlende sinnvolle.
Der Freiraum vor verlinkten (und im PDF damit mit Fußnote versehenen) Wörtern ist sichtbar größer als normal, am deutlichsten bei "IMO- Advisory-Boards
36
", wo eine Leerstelle entsteht, die nicht vorhanden sein sollte.
Das werde ich bei gelegenheit
ändern
Änderung ist eingecheckt
Es wäre praktisch, wenn man in
per Parameter das Feld für die URL vorbelegen könnte. Dann könnte man die Seite direkt verlinken, und der Benutzer müsste nur noch Papiergröße etc. wählen und auf "Start" klicken, um das PDF zu erzeugen.
Das lässt sich machen.
ändern
wurde eingecheckt
--
Schnark
10:55, 18. Jul. 2014 (CEST)
ergänzt 09:19, 19. Jul. 2014 (CEST)
Beantworten
Hallo,
vielen Dank für die Hinweise. Leider werde ich wohl erst Mitte August dazu kommen mir diese näher anzuschauen. Die eingerückten kommentare sind von mir
Viele Grüße
Dirk Hünniger
07:11, 28. Jul. 2014 (CEST)
Beantworten
Danke für die Änderungen. Damit es oben nicht so unübersichtlich wird, kommentiere ich die verbliebenen Punkte lieber noch mal hier drunter:
Das Bild mit der fehlenden Lizenzangabe ist
Datei:Teodor von Burg with two Olympic gold medals.jpg
, vermutlich wird einfach das
cc-by-sa-3.0-rs
nicht als Lizenz erkannt.
Was mir jetzt noch aufgefallen ist: Zumindest Acrobat Reader führt den Quelltext nicht unter den Attachments auf. Ich weiß nicht, ob das „nur“ ein Problem mit Acrobat Reader ist, oder ob anders als in der Einleitung behauptet es doch nicht so leicht ist, den gepackten Latex-Code aus dem PDF zu extrahieren.
--
Schnark
11:37, 20. Okt. 2014 (CEST)
Beantworten
Interessant das mal jemand die Einleitung gelesen hat. Die ist in der Tat falsch. Für (fast) alle PDFs von Wikibooks die ich hochgeladen habe gibt es das Attachment. In der Onlineversion wird derzeit kein Attachment angefügt. In der Onlineversion hat man jedoch die unter "Output Format" "Source ZIP" zu wählen und bekommt eine Quelltext der unter einem aktuellen Ubuntu kompiliert sofern z.b. durch die Installation des Packetes mediawiki2latex die notwendigen LaTeX Bibliotheken installiert wurden. Um an einen unter windows kompilierenden Quelltext zu kommen, muss man die Windows Version der Software herunterladen in das entsprechnden bin verzeichnis welchseln und dort in der Kommandozeilenversion das zip file bestellen. Das kompiliert dann ohne Probleme unter der aktuellen Version von Miktex. Der Grund warum ich derzeit keinen Quelltext anhänge ist hauptsächelich, dass ich die Bilder dann zweimal im PDF habe einmal im Quelltext zipfile und einem im eigentlichen PDF und somit mehr Bandbreite verschieße. Ich weis noch nicht genau ob und wie ich das ändern werden.
Dirk Hünniger
23:54, 20. Okt. 2014 (CEST)
Beantworten
Die Möglichkeit, den Quelltext statt des PDFs herunterzuladen ist meiner Ansicht nach vollkommen ausreichend, ihn nochmals einzubetten daher nicht nötig. Die Tatsache, dass der Quelltext überhaupt zur Verfügung steht, ist in meinen Augen ein wesentlicher Vorteil gegenüber allen anderen MediaWiki-zu-PDF-Umwandlern, da mir das die Möglichkeit bietet, irgendwelche Kleinigkeiten dann noch hinterher an meine Wünsche anzupassen. --
Schnark
10:18, 21. Okt. 2014 (CEST)
Beantworten
Zeichen ausserhalb der 16 Bit Unicode Range werden nicht verarbeitet.
Bearbeiten
Wikipedia Books (Book mode)
Bearbeiten
Letzter Kommentar:
vor 4 Jahren
8 Kommentare
3 Personen sind an der Diskussion beteiligt
May I offer some suggestions that would greatly improve the appearance and usefulness of book collections. Some will be easier than others, but any that you can do quickly and import into the wmf service will help to show that wb2pdf is actively supported!
Much of the Book collection page is currently not processed and important information which organises the book for the reader is lost. Two things in particular would help a lot:
Where the page gives a custom title for an article, as in
:[[Article title|Custom title]]
, the custom title should be used.
Some books group articles into chapters using a semicolon ; as in
;[[Chapter title]]
. These chapter headings should be included. (The PediaPress print service puts them in very big text at the head of the first page in the chapter.)
Category links in the Book collection page have the opposite problem. They are currently expanded as articles but should not usually be, as categories are not usually part of the book content. Links beginning
[[Category:...
should be dropped completely. However, unusual links beginning
[[:Category:...
(with an opening colon : ) would be part of the book content and should be expanded.
Different templates need different processing. Here are two things that would help:
At present small templated Infoboxes near the top of an article, as
{{Infobox whatever ... }}
, are expanded to fill several pages of print, with images in them rendered full size. Theyshould be kept no wider than one page (portrait) and any images in them reduced in size to match.
Navigation templates are currently expanded, but again they are not part of the page content and are best dropped altogether. They are hard to detect in the page but when you follow the link to the template itself you will often find it begins with
{{Navbox ...
. There are others, so eventually a "blacklist" of such template codes would be useful.
I hope this is useful to you. — Cheers, 18:52, 5. Sep. 2019 (CEST)
Hi,
thanks for the suggestions so far. I will take a closer look at them on Monday. But at a first glance things don't look really easy, and I since I got a full time job I will not invest a lot of time. If changes in mediawiki2latex are important enough for someone to pay for them I can point you to Henning Thielemann, as Haskell freelancer, who usually implements solutions quite quickly, who got a PhD in computer science and has worked on mediawiki2latex before, but who will charge a considerable fee.
Dirk Hünniger
19:22, 5. Sep. 2019 (CEST)
Beantworten
Hi,
so I updated the server
, but not the mediawiki2latex-large server.
I added the following two lines:
printPrepareNode (Environment Wikitable (TagAttr "table" m) _)
| maybe False (\x->or (map ($ x) (map isInfixOf ["navbox", "infobox"]))) (Map.lookup "class" m) = []
That means any table tag in html that contains a class attribute which value contains either navbox or infobox as substring will be deleted. If you need more templates removed, just add the to the list. This can be easily checked by compiling the example
en:w:BIRCH
the article on the Wikipedia contains the navbox, the output of the server does not. This way I have formally proven that I actively maintain mediawiki2latex qed.
Dirk Hünniger
23:03, 5. Sep. 2019 (CEST)
Beantworten
Thank you. Dropping the infoboxes completely is better than displaying them and their images so big, but obviously it will be better still when you can display them the right size. — Cheers,
Steelpillow
11:42, 6. Sep. 2019 (CEST)
Beantworten
Oh, and is the server at mediawiki2latex.wmflabs.org just a front end for the "large" server? Is there some information about this anywhere? — Cheers,
Steelpillow
11:45, 6. Sep. 2019 (CEST)
Beantworten
Hi, there is only some information here
Benutzer:Dirk_Hünniger/wb2pdf
in the section web version. The large server has only got one difference compared to the main server. It allow a runtime of serveral hours, the main server allows only one hour. I think is make most sense to link to the main server since the large server might get unavailable for many hours, if a request runs that long.
Dirk Hünniger
13:15, 6. Sep. 2019 (CEST)
Beantworten
So the navbox in the birch article in now rendered as a single page.
Dirk Hünniger
13:40, 6. Sep. 2019 (CEST)
Beantworten
Thank you so much for your work on the templates. The most important thing next I think is to drop the Category pages from processing. Is that an easy thing to do? — Cheers,
Steelpillow
16:01, 7. Sep. 2019 (CEST)
Beantworten
Brave and buetiful
Sergio Serhan
11:41, 31. Mai 2021 (CEST)
Beantworten
Web Interface
Bearbeiten
Letzter Kommentar:
vor 6 Jahren
3 Kommentare
2 Personen sind an der Diskussion beteiligt
Here are some suggestions for changes to the web interface. I am sorry there are so many. I also have one or two questions.
Web interface
"To compile MediaWiki pages via LaTeX to PDF choose any URL from Wikibooks or any other website running MediaWiki. If you intent to compile a wikibook make sure you use the link to the printable version of the book." to read, "To build a softcopy from MediaWiki content (such as Wikipedia or Wikibooks), enter the full web URL of the book page. For a Wikibook, ensure it is the link to the printable version of the book."
Either "Wikibooks" to link to
and not to
or, if this is wrong, then the legend should read "Wikipedia Books" and link to
"URL to the Wiki to be converted" to read, "Full web URL of the book page."
Move the Output Format selector below the template option and page size selectors. In the selector:
"Complied PDF" to read "PDF".
"Source Zip" to read, "LaTeX zip"
"EPUB File" to read "EPUB"
"ODT File (Word processor)" to read, "ODT (Word processor)"
"Template Expansion" to read, "Template options". In the selector:
"Print" to read "Standard book" or similar. But they how is this different from Book Mode?
"BookMode" to read "Wikipedia Book".
"MediaWiki" to read "Wikitext" (they are all MediaWiki input!).
"Normal" to read "Custom expansion" or similar (it is not at all normal for most users!).
"Paper" to read, "Page size". In the selector:
letter, legal and executive to be capitalised as Letter, Legal and Executive.
Immediately below the page size warning specific to the configuration, add a note that:
For the 200 page server, "If your book is up to 800 pages you can use the large book service." and link to that server.
For the 800 page server, "This server can be busy for long periods. For a book below 200 pages you can use the small book service." and link to that server.
"There is no limit in the downloadable versions shown on the right." to read, "There is no limit by default in the downloadable version of the software, see link on right."
Questions
For a page or book which is not in the Book: namespace, how is the Book Mode different from Print mode?
How does the default config of Normal mode behave (when there are no custom mapping files)? Is it the same as MediaWiki mode? If not, what is different?
Can you update both the main server and the large book server at wmflabs?
You see you are not busy enough. You can do all this with your right hand while your left hand is eating. ;o) — Cheers,
Steelpillow
21:26, 7. Sep. 2019 (CEST)
Beantworten
Hi,
first about you questions. In Book mode all links are followed but not recursively. So if you got a List of articles outside of the book namespace you have to choose this mode. If you use Print on such a list, the output will just be the list itself, but the articles the item of the list point to will not be included at all. If a the list if in book namespace and you choose print, mediawiki2latex will override your decision to use print and will use book mode instead.
I made a default mapping file, which is used in normal mode. The is a definition of several hundred lines of code that says how to expand each template individually. But if the is nothing defined for the particular template, and error message will be written into the text in the pdf (unknown template). In mediawiki mode, mediawiki will expand the templates to wiki source text. This will be processed by the mediawiki2latex parser, to the unknown template error can not occur at all, but not mapping will be used at all too.
I updated both servers.
I implemented most of your suggestions concerning the web interface. Some things I made a little different from the way you suggested them, trying to express some technical details that seem more clear in the this way. I am happy to hear about you comments, in particular as you are a native speaker. I usually need some iterations to get both the English language and the technical facts right. I did not add the links between the normal and the large document server, since I want to keep both of them as similar as possible, to avoid maintenance work.
Happy to hearing from you.
Dirk Hünniger
15:00, 9. Sep. 2019 (CEST)
Beantworten
OK, that is much better. I will take a break for now, and leave you to yours. — Cheers,
Steelpillow
22:03, 9. Sep. 2019 (CEST)
Beantworten
Arabische Sätze in Tabellen
Bearbeiten
Die arabischen Sätze als Tabellentext würden nicht richtig umgebrochen, z.B.
. Im Vergleich wird die Erweiterung
damit gut umgehen.
Gibt es eine Lösung dafür? Vielen Dank in Voraus.
Leider scheint es die Seite die du umwandeln wolltest nicht mehr zu geben. Schreib hier einfach noch mal was hin wenn es auf einer anderen Seite auch nicht klappt. Es wird versucht die Sprache am Hostnamen abzuleiten falls das nicht klappt wird englisch genommen, was dann bei logischerweise nicht klappt. Du kann aber den tex Quelltext runterladen und dort die Sprache von Hand einstellen. --
Dirk Hünniger
Verweise, noinclude und Bilder
Bearbeiten
Letzter Kommentar:
vor 5 Jahren
2 Kommentare
2 Personen sind an der Diskussion beteiligt
Bei meinen jüngsten Versuchen ist mir aufgefallen, daß Verweise (auch solche zu anderen Büchern, externe Verweise) nicht mehr im erzeugten EPUB vorkommen.
Bei externen Verweisen sollte das immerhin einfach sein, ist inhaltlich immer wichtig.
Bei Verweisen zu anderen Büchern erfordert die Auflösung aufgrund der wiki-Kürzel ein paar Sonderregeln, welche ja aber bekannt sind.
Ebenfalls mögliche Verweise innerhalb des Buches sind gleichfalls möglich sowie wichtig, insbesondere sollte wohl das Inhaltsverzeichnis funktionieren.
Trotz 'noinclude' werden die Navigationshilfen eingebunden. Wie ist dies zu vermeiden?
Bei Bildern wiederum werden diese häufig nicht in das EPUB integriert, vielmehr wird auf etwas wie
//upload.wikimedia.org/wikipedia/commons/thumb/1/1f/Go-previous.svg/24px-Go-previous.svg.png verwiesen.
Getestetes Buch:
HTML5
mit
, Einstellung: EPUB; Book Collection oder Book Contents Page; Keep Vector Form
Doktorchen
11:17, 5. Mai 2020 (CEST)
Beantworten
Hallo,
Ich konnte am Quelltext solche Dinge nachvollziehen im Moment fehlen mir jedoch die Kapazitäten um mich da drum zu kümmern.
Dirk Hünniger
14:01, 8. Mai 2020 (CEST)
Beantworten
Book generation fails when /wiki is not in the URL
Bearbeiten
Letzter Kommentar:
vor 4 Jahren
8 Kommentare
2 Personen sind an der Diskussion beteiligt
Hi! I work on appropedia.org where due to the nature of the content, offline access is quite a priority. We've been struggling to find a solution since the Collection extension died, so we were very happy and thankful to find out about MediaWiki2LaTeX! However, I did some tests and found that book generation fails for Appropedia pages! It seems like the cause is the lack of the /wiki path in our URL structure. When setting Book/Collection on the "template expansion" parameter, the following work fine
(a personal wiki of mine)
(another personal wiki of mine)
But the following fail:
(a random wiki I contribute to that also lacks /wiki on the URL structure)
To be precise, the PDFs do get generated, but the pages that make up the book are not found by the script (generate the PDFs to see what I mean exactly). Notice that while both wikis don't have /wiki on their URL path, Appropedia does have /w on the script path, while Musiki doesn't (in other words, their APIs are at
and
) so the issue seems related to the URL structure, not the script path. Also, when setting "template expansion" to Standard, the PDF gets generated fine, so the issue seems to affect only the Book/Collection "template expansion" feature.
Is there any chance of a bugfix? Alternatively, is there any chance that this bug won't happen or that it can be avoided with a local installation of the command-line tool? I guess the best way to know is to try it out but
installation on CentOS
seems quite tricky so I thought I'd rather ask first.
In any case, thanks for this awesome tool!
Sophivorus
15:35, 24. Aug. 2021 (CEST)
Beantworten
Hi
Sophivorus
I did some patching an got it to work.
download mediawiki2latex version 7.43 from sourceforge.
in file GetImages.hs on line 67 change function "getImagePage" to look like this
getImagePage ::
String ->
WikiUrl -> (Integer, String) -> IO (Maybe ([String], Integer, URL))
getImagePage dir u (i, ss)
= do l <- (mapM (geturl . kds.unify . exportURL . modpath2 ss)
(parses u))
:: IO [String]
let xx = (map (getImageUrl2) (zip l (parses u))) :: [Maybe String]
let gg = (zip (parses u) xx) :: [(URL, Maybe String)]
let yy = (map go gg) :: [[(URL, String)]]
let zz = (listToMaybe (concat yy)) :: Maybe (URL, String)
case zz of
Just (du, x) -> do img <- (geturl2 x) :: (IO BStr.ByteString)
BStr.writeFile (dir (show i)) img
return
(Just
(map (unify . exportURL . (modpath2 ss)) (parses u), i,
modpath2 ss du))
_ -> return Nothing
where go :: (URL, Maybe String) -> [(URL, String)]
go (uu, Just x) = [(uu, x)]
go _ = []
kds ('h':'t':'t':'p':'s':':':'/':'/':xs)=('h':'t':'t':'p':'s':':':'/':'/':(kds xs))
kds ('/':'/':xs)='/':(kds xs)
kds (x:xs) = x:( kds xs)
kds [] = []
Furthermore in file UrlAnalyse.hs on line 255 change function "getBookpage" to look like this
getBookpage :: String -> WikiUrl -> IO (Maybe String)
getBookpage ss u
= do l <- mapM ((geturl2) . unify) ((map ((++(""++ss)).exportURL)) (parses u))
lll <- return (seq l l)
return $
(listToMaybe $ concat (map maybeToList (map go lll))) >>=
(return)
where
go x =if (x==(UTF8Str.fromString [])) then Nothing else Just (UTF8Str.toString x)
Yours
Dirk Hünniger
16:57, 26. Aug. 2021 (CEST)
Beantworten
Dirk Hünniger
THANKS!!! Will you incorporate this patch to the web interface?
Sophivorus
18:05, 26. Aug. 2021 (CEST)
Beantworten
Hi
Sophivorus
the problem is that this patch will most likely break rendering of normal wikipedia articles. Some more thinking is required to take care of both cases. I don't feel like doing it right now. Still the patch should be a starting point one someone or perhaps even I myself will start to work on the issue.
Yours
Dirk Hünniger
18:16, 26. Aug. 2021 (CEST)
Beantworten
I understand. I'll try to do the local installation then, thanks again, cheers!!
Sophivorus
13:55, 27. Aug. 2021 (CEST)
Beantworten
Hi
Sophivorus
please download mediawiki2latex version 7.44 and apply the patch to that.
7.43 does not work with even with wikipedia anymore since wikipedia now requieres https user agent header to be present in most of the request, which is done the required way in 7.44 but not in 7.43. Happy to hear about the results of you attempts. Maybe consider using a virtual machine with debian or ubuntu instead of doing it on centos.
Yours
Dirk Hünniger
14:12, 27. Aug. 2021 (CEST)
Beantworten
Hi
Sophivorus
good news. I installed it on the webserver, now you don't need to install locally anymore.
Your wiki as well as german wikibooks both work. So should all others.
Yours
Dirk Hünniger
15:04, 27. Aug. 2021 (CEST)
Beantworten
OMG awesome!!! Thanks so much, I'll go ahead and experiment creating friendly links from Appropedia, thanks !!!!
Sophivorus
15:27, 27. Aug. 2021 (CEST)
Beantworten
URL parameters for the web interface
Bearbeiten
Letzter Kommentar:
vor 4 Jahren
7 Kommentare
2 Personen sind an der Diskussion beteiligt
Hi again! I think it'd be great if it were possible to preload values into the web interface via URL parameters, so as to be able to create better links to the tool. This would allow us, for example, to create a template for Wikibooks that could be inserted into any page and that would link to MediaWiki2LaTeX but would already preload the referring URL and appropriate template expansion method. Cheers!
Sophivorus
15:18, 25. Aug. 2021 (CEST)
Beantworten
Hi
Sophivorus
, regarding your proposal to preload the url field in mediawiki2latex. This feature is already there just look at
for an example. Feel free to contact me if you need further assistance. Yours
Dirk Hünniger
15:47, 26. Aug. 2021 (CEST)
Beantworten
Awesome! I'll give back by documenting this feature when I get a bit more comfortable with it. Thanks!
Sophivorus
17:11, 26. Aug. 2021 (CEST)
Beantworten
Dirk Hünniger
Hi! I just did the first integration of your tool in Appropedia! See for example
(ctrl+f for "pdf"). I'm very grateful for the help you've given me so far. I just
started documenting
the "fill" feature as a humble way to give a little bit back. That being said, I have a question/suggestion: is it possible to preload the export format and the other fields of the tool? Currently in Appropedia we're showing links to export to PDF, LaTeX, EPUB, etc. but they only preload the URL and leave the rest to the user. It would be great to save them that work and avoid possible mistakes by preloading those other fields too! This would be especially useful when integrating your tool with Appropedia "books" (collections of pages) rather than single pages. As always, thanks for your help and for developing this tool!
Sophivorus
02:06, 31. Aug. 2021 (CEST)
Beantworten
Hi
Sophivorus
it is certainly possible to prefill more fields. I would require changes in Server.hs. But the weather is currently too nice, so I prefer to go cycling today.
Yours
Dirk Hünniger
12:52, 31. Aug. 2021 (CEST)
Beantworten
Hi again! I totally share your priorities (in a few days I'll go cycling to the countryside with some friends hah). I just added an option to export collections of pages to sidebars on Appropedia (
example
, ctrl+f for "export all"). This is starting to look great, thanks!! You'll notice I had to add a note asking the user to select the right format and template expansion method. Hopefully one day I'll be able to preload those. That being said, I also notice that PDF generation may take quite a while, so I wanted to ask you if by installing mediawiki2latex locally I can expect a significant improvement in PDF generation time. If yes, then I'll probably give it a try, since having a local installation should also allow me to preload the format and template expansion method. Thanks again for your work and time, cheers!!
Sophivorus
17:45, 7. Sep. 2021 (CEST)
Beantworten
Hi
Sophivorus
local installation and web installation run exactly the same code. So in theory no speedup is to be expected. Still the web interface is running on a virtual machiene on a shared host, so in practice you could expect a speedup of maybe 1.5 if you run it on you own computer and it is not too old.
Yours
Dirk Hünniger
21:24, 7. Sep. 2021 (CEST)
Beantworten
Bilder werden teils ignoriert
Bearbeiten
Letzter Kommentar:
vor 3 Jahren
5 Kommentare
3 Personen sind an der Diskussion beteiligt
Nach längeren Tests kann ich folgendes Verhalten beobachten bei der Umwandlung zu Epub beobachten. Gilt für meine lokale (aktuelle) Version, aber offenbar auch für
Beim Testartikel
werden je nach Template-Modus nicht alle Bilder übernommen.
- Standard/default mode/HTML: 7 Bilder werden übernommen. U.a. die Schiffsgrafik gleich rechts oben (Yamato1945.png) fehlt, im Epub ist das Bild mit der Online-URL eingebunden
- Expand templates by MediaWiki: 10 Bilder werden übernommen (alle Bilder die der Artikel enthält). Jedoch ist der Artikeltext nun mit Latex-Versatzstücken (?) gespickt: "
{\itshape \allowbreak{}\setmainfont{cmunti.ttf}[Path=/usr/share/fonts/truetype/cmu/,UprightFont=cmunrm,BoldFont=cmunbx,ItalicFont=cmunti,BoldItalicFont=cmunbi]\setmonofont{cmunti.ttf}" "Marshall-{}Gruppe
" usw.
Besonders die Tabelle am Anfang ist kaum lesbar.
Beide Wege führen also aktuell nicht zu einem optimalen Ergebnis.
Für Abhilfe bin ich dankbar, da ich das Tool ansonsten überaus schätze.
2A04:4540:6602:2B00:2821:5931:5CD9:118F
12:15, 7. Nov. 2022 (CET)
--
2A04:4540:6602:2B00:2821:5931:5CD9:118F
12:16, 7. Nov. 2022 (CET)
Wolfgang D
Beantworten
Hallo Wolfgang,
ich konnte das Problem nachvollziehen und eine Änderung zur dessen Behebung in git einchecken. Ebenso habe ich den Server mediawiki2latex.wmflabs.org entsprechend aktualisiert. Mit Expand templates by MediaWiki erhällst du nun epub Dateien ohne den dort nicht sinnvollen und von dir oben beschriebenen Latex Code. Wenn du lokal arbeiten willst kannst du folgende Kommandozeile verwenden:
mediawiki2latex -c ccc -u https://de.wikipedia.org/wiki/Yamato_\(Schiff,_1941\) -o dirk.epub -b -m
Du musst jedoch vorher mediawiki2latex auf die neueste Version im git aktualisieren und neu aus den Quellen kompilieren und installieren. Viele Grüße
Dirk Hünniger
13:48, 7. Nov. 2022 (CET)
Beantworten
Hallo Dirk,
lieben Dank dir für die super-schnelle Reaktion und Verbesserung! Das ist sehr freundlich.
Ich habe einen Test vorgenommen auf mediawiki2latex.wmflabs.org, mit dem Yamato-Artikel und "Expand templates by MediaWiki".
Das Ergebnis ist schon viel besser. Beim Überfliegen des Epubs fallen mir aber noch folgende, mehrfach auftauchende, Stellen auf:
"Fehler im Ausdruck: Nicht erkanntes Satzzeichen"
"Vorlagenfehler/Vorlage:Webarchiv/veraltete Parameter‎UNKNOWN TEMPLATE Webarchiv/archiv-bot"
Von außen betrachtet, hätte ich immer noch den Eindruck, dass die Variante "Standard/default mode/HTML" bis auf die fehlenden Bilder bessere/robustere Ergebnisse liefert. Daher hätte ich intuitiv vermutet, es wäre einfacher die beschriebene Problematik des Verlust der Bilder zu bearbeiten. Diese Art Fehler betrifft übrigens auch einige ähnliche Tools, vielleicht hat die Wikipedia hier etwas an der Technik geändert, mit die Scripts nicht zurechtkommen.
Jedenfalls, vielen Dank für die Mühen und ich freue mich auf weitere Verbesserungen.
2A04:4540:6600:1300:B83C:4C21:1247:1760
11:41, 9. Nov. 2022 (CET)
Wolfgang D.
Beantworten
Hallo Wolfgang,
in der Tat werden im HTML Modus Bilder innerhalb von Navigationsboxen und Infoboxen entfernt, weil irgendwer das als Feature bei mir bestellt hatte. Wenn du in der Datei MediaWikiParser.hs die Zeilen 1936 und 1937 durch dass voranstellen eine doppelten Bindestrichs deaktivierst werden die Bilder im HTML Modus nicht mehr entfernt. Die Zeilen müssen dann so aussehen.
-- printPrepareNode (Environment Wikitable (TagAttr "table" m) l)
-- | maybe False (\x->or (map ($ x) (map isInfixOf ["navbox", "infobox"]))) (Map.lookup "class" m) = [Environment Wikitable (TagAttr "table" m) (droplinks (printPrepareTree (droplinks l)))]
Da ich selber nicht weis ob nun "mit Bildern" oder "ohne Bilder" besser ist lasse ich bei mir erst einmal alles auf "ohne Bilder". Aber wie gesagt es ist alles Quelloffen und du kannst deinen Eigenen Fork machen bei dem "mit Bildern" gilt.
Was die Fehlermeldungen mit UNKNOWN TEMPLATE Vorlagenfehler und so weiter angeht denke ich dass die von mediawiki beim expandieren der templates erzeugt werden und sich daher ausserhalb meines Einflussbereichs befindet.
Viele Grüße
Dirk Hünniger
13:43, 9. Nov. 2022 (CET)
Beantworten
Vielen, vielen Dank!
Tatsächlich hat es nur die Deaktivierung dieser beiden Zeilen und ein neues Build gebraucht. Jetzt funktioniert es im HTML-Modus einwandfrei. Ich bin sehr zufrieden, perfekte Ergebnisse.
Dir eine schöne Woche noch und nochmals ein großes Dankeschön für die umgehende und freundliche Hilfe.
2A04:4540:6600:1300:B83C:4C21:1247:1760
19:08, 9. Nov. 2022 (CET)
Wolfgang D.
Beantworten
Abgerufen von „
Kategorie
Seiten mit dem veralteten source-Tag
Versteckte Kategorie:
Seiten mit Syntaxhervorhebungsfehlern
Benutzer Diskussion
Dirk Huenniger/wb2pdf/Requests
Abschnitt hinzufügen