URL hart brechen

Antwort erstellen


Diese Frage dient dazu, das automatisierte Versenden von Formularen durch Spam-Bots zu verhindern.
Smilies
:D :) :( :o :shock: :? 8) :lol: :-x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen:

BBCode ist eingeschaltet
[img] ist eingeschaltet
[flash] ist ausgeschaltet
[url] ist eingeschaltet
Smilies sind eingeschaltet

Die letzten Beiträge des Themas

Ich habe die Datenschutzerklärung gelesen und bin damit einverstanden.

   

Wenn du eine Datei oder mehrere Dateien anhängen möchtest, gib die Details unten ein.

Ansicht erweitern Die letzten Beiträge des Themas: URL hart brechen

von royalware » Do 7. Mai 2009, 18:33

Wunderbar. Dann sollte dieses - leicht zweckentfremdete - Thema hiermit abgeschlossen sein. Danke!

von KOMA » Do 7. Mai 2009, 18:28

Bei mir gibt es die Datei dvipdfmx.def unter TEXMFDIST/tex/latex/dvipdfmx-def/dvipdfmx.def. Wenn man aber die Option dvipdfmx verwendet, dann ist zu beachten, dass hyperref im Gegensatz zu color und graphics/graphicx keinen speziellen Treiber für dvipdfmx kennt. Aktuelle Versionen von hyperref laden bei Option dvipdfmx einfach denselben Treiber wie bei Option dvipdfm. Eventuell kannten frühere Versionen von hyperref überhaupt keine Option dvipdfmx. In dem Fall wird dann der Default-Treiber (in der Regel dvips) geladen, wenn dvipdfmx nur als globale Option angegeben ist. Man kann das in der Log-Datei sehen.

Übrigens sprach ich in meinen Hinweis, dass man dvipdfmx verwenden sollte, von dem entsprechenden Programm, weniger von der entsprechenden Option für die genannten Pakete. Die paar Mal, die ich dvipdfmx verwendet habe, habe ich im Dokument für das »x« genau gar keine Vorsorge getroffen, sondern schlicht das Programm dvipdfmx als verbesserten Ersatz von dvipdfm verwendet.

von royalware » Do 7. Mai 2009, 16:01

Als Nachtrag noch das Minimalbeispiel zum Nachvollziehen der Fehlermeldung
\documentclass[a4paper,dvipdfmx,11pt]{report}

\usepackage{graphicx,color,amsmath,amssymb,amsbsy,fancyhdr}
\usepackage[german]{babel}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}

\PassOptionsToPackage{hyphens}{url} %Umbrüche nach '-' erlauben
\usepackage[colorlinks=true, linkcolor=blue, pdfstartview=Fit, pdfpagelayout=OneColumn,
	bookmarksopen=true, bookmarksnumbered=true, 
	breaklinks=true]
{hyperref} 

\begin{document}
Minimalbeispiel
\end{document}
Die Fehlermeldung lautet bei mir
LaTeX Error: File 'dvipdfmx.def' not found.
Das Paket ist aber installiert.

von royalware » Do 7. Mai 2009, 15:42

Also ich musste leider grad feststellen, dass die dvipdfm-Option in der letzten Zeile offenbar doch notwenidig ist. Ich habe nämlich vorhin mit einigen Optionen aus dem Handbuch von "hyperref" herumexperimentiert. Und da gab es Fehlermeldungen, wenn die Option nur global definiert ist. Sobald ich "dvipdfm" direkt beim Laden von "hyperref" wieder eingesetzt, hat es wieder richtig funktioniert.

Und dvipdfmx habe ich bei meiner letzten Studienarbeit auch verwendet, weil dvipdfm einige EPS-Grafiken seltsamerweise unter großen Qualitätseinbußen ins PDF eingebettet hat, während dvipdfmx das ordentlich angestellt hat. Aber leider bekomme ich beim globalen Definieren von dvipdfmx in der ersten Zeile auch Fehlermeldungen. Spricht denn etwas dagegen, dvipdfm zu deklarieren und am Ende zum Umwandeln dann doch dvipdfmx zu benutzen?

Und als Argument für das Umwandeln in DVI und anschließend PDF möchte ich anbringen, dass mit "Yap" als Preview-Applikation gut gefällt, weil er direkt an die entsprechende Stelle des gerade kompilierten Files springt. Und das hatte ich beim direkten Umwandeln mittels pdflatex nicht hinbekommen. Gilt dieses Argument? ;-)

von KOMA » Do 7. Mai 2009, 15:27

Das dvipdfm in der letzten Zeile kann in der Tat weg. Übrigens sollte man besser dvipdfmx als dvipdfm verwenden. Das Programm arbeitet in einigen Punkten besser als sein Vorfahre. Natürlich wäre zu überlegen, ob man nicht gleich pdflatex nehmen kann, um das PDF zu erzeugen. Damit spart man sich den Zwischenschritt DVI gleich auch noch. PS-Tricks ist übrigens kein Argument, dass das nicht geht. Dafür gibt es Pakete (z. B. pst-pdf). Ebenso wenig sind EPS-Abbildungen ein Argument. Die kann man einfach mit epstopdf in PDFs umwandeln.

Pakete ohne oder mit identischen Optionen kann man durchaus zusammen laden. Allerdings empfiehlt es sich, das dann so zu schreiben:
\usepackage{%
graphicx
,color
,amsmath
,amssymb
,amsbsy
,fancyhdr
}
Das gibt ggf. die Möglichkeit, mal schnell einen Kommentar anzufügen oder eine Zeile auszukommentieren. BTW: Ich würde xcolor statt color empfehlen. Schon allein die dort gebotene Möglichkeit, Standardfarben über Namen anzusprechen ist ein gutes Argument dafür. Außerdem bietet das Paket die Möglichkeit, Farben in ein anderes Modell zu konvertieren, bzw. anzugeben, was das Standardmodell sein soll. Das ist beispielsweise nützlich, wenn man irgendwann erfährt, dass in der Druckstufe alle Farben in CMYK statt RGB anzugeben sind. Außerdem bietet das Paket direkt eine Unterstützung beispielsweise für colortbl.

von royalware » Do 7. Mai 2009, 15:02

Danke für Deine Tipps.

Die Option "dvips" beim Laden von "graphicx" ist natürlich Blödsinn und erklärt jetzt möglicherweise auch, warum ich mit manchen EPS-Bildern Konvertierungsprobleme hatte. Ich hab den Header "blind" einer Vorlage für die Diplomarbeit von einem Prof. entnommen. Nunja...

dvipdfm verwende ich in der Tat, da ich keine Notwendigkeit sehe, von der DVI-Ausgabe über PostScript zum PDF zu gelangen.

Und Du hast richtig gelegen. Dass "ngerman" die bessere Wahl ist, wusste ich tatsächlich nicht. Vielen Dank!

Das mit der globalen Option sieht dann jetzt so aus:
\documentclass[a4paper,dvipdfm,11pt]{report}

\usepackage{graphicx,color,amsmath,amssymb,amsbsy,fancyhdr}
\usepackage[german]{babel}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}\usepackage[ngerman]{babel}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}

\PassOptionsToPackage{hyphens}{url} %Umbrüche nach '-' erlauben
\usepackage[dvipdfm, colorlinks=true, bookmarksopen=true, bookmarksopenlevel=4, breaklinks=true, pdfstartview=Fit, linkcolor=blue]{hyperref}
Das Zusammenfassen von Paketen, die ohne Optionen auskommen (Zeile 3) ist doch unbedenklich, oder?
Ich hoffe, dass es jetzt ein einheitlicheres Bild ergibt. Danke nochmals für die Tipps...

EDIT: Das "dvipdfm" aus der letzten Zeile kann ja nun auch entfernt werden, oder?

von KOMA » Mi 6. Mai 2009, 14:55

Die Zeile solltest Du rauswerfen. Wenn Du Umbrüche nach »-« erlauben willst, dann geht das per url-Paket-Option »hyphens«. Da hyperref url selbst lädt und AFAIK keine Möglichkeit bietet, Optionen an url durchzureichen, muss man die Option per
\PassOptionsToPackage{hyphens}{url}
vor dem Laden von hyperref setzen. Vermutlich hat derjenige, von dem Du den Code hast, nicht gewusst, dass es so eine Möglichkeit gibt.

BTW: Option dvipdfm solltest Du natürlich nur verwenden, wenn Du wirklich mit dvipdfm arbeitest. In dem Fall sollte man aber eigentlich auch color und graphicx mit dieser Option laden und nicht mit Option dvips. Man könnte dann auch gleich dvipdfm als globale Option (also bei \documentclass) angeben. Dann muss man das ggf. nur an einer Stelle ändern.

BTW2: Option german bei babel ist für obsolete deutsche Rechtschreibung. Die aktuelle deutsche Rechtschreibung bekommt man mit ngerman.

Diese Anmerkungen nur so für den Fall, dass Du es noch nicht wusstest.

Ansonsten: Wenn Du der Meinung bist, dass das url-Paket etwas anders machen sollte, dann schick dem Maintainer/Autor einen Feature-Request. Nebenbei schätze ich mal dass min. die Hälfte der Features in KOMA-Script auf Feature-Requests zurück geht. Mich wundert dabei immer wieder, dass sich Anwender wundern, wenn ich eine Nachfrage beantworte.

von royalware » Mi 6. Mai 2009, 12:58

Hervorragend!Vielen Dank für die Hilfe. Jetzt sieht es so aus wie es sein soll. Ich finde es allerdings eigenartig, dass das im URL-Paket nicht von Haus aus so definiert ist...

Die Zeile
\def\do@url@hyp{\do\-}
verstehe ich allerdings noch nicht ganz. Wird damit einfach nur festgelegt, dass kein "-" am Zeilenende gesetzt wird? Notwendig scheint das bei mir nicht zu sein. Das Resultat ist mit und ohne identisch.

von KOMA » Di 5. Mai 2009, 14:46

Das Problem ist, dass Du eine ganze Zeile mit einem Teil der URL füllst. Dadurch kann nirgendwo in der Zeile zusätzlicher Leerraum eingefügt werden, also muss die Zeile entweder über- oder unterfüllt werden. Das bedeutet, dass es keinen korrekten Umbruch gibt. Das macht TeX mit einer overfull \hbox deutlich. Eine Lösung könnte beispielsweise sein, zusätzlichen Abstand nach einem Slash zu erlauben:
 \g@addto@macro\UrlSpecials{\do\/{\mbox{\UrlFont/}\hskip 0pt plus 1pt}}

von royalware » Di 5. Mai 2009, 13:20

Ich hatte das selbe Problem wie Deni und die von Stefan angebotene Lösung hat mir schon zum Großteil geholfen. Die URL wird korrekt getrennt, aber leider erst hinter dem Seitenrand, so dass eine overfull box entsteht.

\documentclass[a4paper,11pt]{report}
\usepackage[dvips]{graphicx}
\usepackage{amsmath,amssymb,amsbsy}
\usepackage{color}
\usepackage[german]{babel}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage{fancyhdr}
\usepackage[dvipdfm, colorlinks=true, bookmarksopen=true, bookmarksopenlevel=4, breaklinks=true, pdfstartview=Fit, linkcolor=blue]{hyperref} 

\makeatletter
\g@addto@macro\UrlBreaks{
  \do\a\do\b\do\c\do\d\do\e\do\f\do\g\do\h\do\i\do\j
  \do\k\do\l\do\m\do\n\do\o\do\p\do\q\do\r\do\s\do\t
  \do\u\do\v\do\w\do\x\do\y\do\z\do\&\do\1\do\2\do\3
  \do\4\do\5\do\6\do\7\do\8\do\9\do\0}
% \def\do@url@hyp{\do\-}
\makeatother

\begin{document}

\chapter{Minimalbeispiel}

Diese URL soll umgebrochen werden. Das funktioniert auch recht gut, aber leider entsteht eine Overfull Box, die "`4.63574pt too wide"' ist: \url{http://www.heise.de/security/Neues-Rating-System-fuer-Sicherheitsfehler-vorgestellt--/news/meldung/64047}

\end{document}
Lässt sich das irgendwie geschickt ändern?


EDIT:
Wenn die Code-Zeile
\def\do@url@hyp{\do\-}
vor "\makeatother" verwendet wird, wird der Rand sogar um 10pt überschritten (erst beim zweiten Zeilenumbruch). Eigenartig...

Nach oben