Seitenränder in Fremdcode bestimmen

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: Seitenränder in Fremdcode bestimmen

von MoonKid » Di 21. Apr 2015, 18:07

Noch ne kleine Ergänzung.

Wenn man das vor Ort selbst cuttet, machen die Schnittmarken in dem obigen Code nicht viel Sinn.

Vor allem sollten Sie nicht nur im Rand sein, sondern auch im Bereich der Karten. Andernfalls schneidet man sich Stück für Stück die Orientierung weg. Kann das schwer beschreiben - sitzt man aber am Schnitttisch merkt man, wo das Problem liegt.

Und die Schnittmarken sollten bleicher (grauer) sein. Mehr Unauffälligkeit durch geringere Strichstärke oder Punkte lässt sich sicher auch noch erzeugen.

Leider ist nicht überliefert, wie der ursprüngliche Codeschreiber, diesen Kram in die Realität umgesetzt hat.

Hab noch einen Thread zum Thema der Passgenauigkeit beim Duplex-Druck geöffnet.

von u_fischer » Mi 15. Apr 2015, 19:01

MoonKid hat geschrieben: Ich bekomme aber immer noch diese Meldung, welche ich nicht ganz nachvollziehen kann.
Overfull \hbox (241.84715pt too wide) detected at line 32
\dashbox hat drei Argumente. Da fehlt also ein Klammerpaar:
\dashbox{1}(85,55){}

von MoonKid » Mi 15. Apr 2015, 18:41

Besserwisser hat geschrieben:Es gibt übrigens Pakete für Visitenkarten.
Die ersten drei sind hier scheinbar für Vistenkaarten, wobei nur das erste wirklich dokumentiert ist. Wundere mich immer wieder über die niedrigen oder nicht vorandenen Quali-Standards für CTAN-Pakete.

bizcard sieht auf den ersten Blick brauchbar aus. Aber naja, nun hab ich hier schon meinen Code so gut wie fertig.
Ob bizcard den Inhalt tatsächlich exakt zentriert, so das man auch beidseitig bedruckte Vistenkarten erzeugen könnte, kann ich aus dem Code in der Doku (bei meinem Mini-Verständnis) leider nicht exakt ableiten.
Ich hab mal ne Mail an den den Entwickler geschickt.

von MoonKid » Mi 15. Apr 2015, 18:35

Johannes_B hat geschrieben:\setlength{\parindent}{3cm}
Aber davon abgesehen, willst du die selbst drucken und dann ausschneiden?
Ah, die doofe Einrückung schon wieder. Wie oft bin ich da schon reingefallen!? Die muss natürlich auf 0, dann passt die dashbox auch mit dem frame von geometry (optisch) genau übereinander.

Ich bekomme aber immer noch diese Meldung, welche ich nicht ganz nachvollziehen kann.
Overfull \hbox (241.84715pt too wide) detected at line 32
Der Druck geht in den Copyshop, wo es auch gecuttet werden soll. Cutmarken setze ich dann noch passend in den Rand. Möchte nur sicher gehen, dass das generierte PDF exakt ist, so dass ich den Hiwi dort im Copyshop auch zu recht zur Sau mache, weil er nicht in der Lage ist die (default) Skalierung bei seinem Reader/Drucker auszuschalten. ;)

von Besserwisser » Mi 15. Apr 2015, 07:43

Es gibt übrigens Pakete für Visitenkarten.

Achja: Wenn der Kopf nicht zum Textbereich gehört, liegt der Kopf im Rand. Damit bezieht sich die Angabe für den oberen Rand auf den Teil zwischen oberer Blattkante und Anfang des eigentlichen Textes. Gehört der Kopf hingegen zum Textbereich, dann liegt der obere Rand darüber. Damit bezieht sich die Angabe für den oberen Rand auf den Teil zwischen oberer Blattkante und Kopf. Siehe dazu auch Abbildung 2a+b der [d]geometry[/d]-Anleitung, bei der das sehr schön illustriert wird.

von Johannes_B » Di 14. Apr 2015, 23:05

\setlength{\parindent}{3cm}


Aber davon abgesehen, willst du die selbst drucken und dann ausschneiden?

von MoonKid » Di 14. Apr 2015, 21:24

https://en.wikibooks.org/wiki/LaTeX/Pag ... dimensions sieht hier ganz interessant dabei aus. Ist das noch aktuell?

Hab jetzt mit geometry ein bisschen gedoktert, aber es haut noch nicht ganz hin.
% b.tex
\documentclass{article}
\usepackage{xltxtra}
\defaultfontfeatures{Mapping=tex-text}
\usepackage{polyglossia}
\setdefaultlanguage[spelling=new]{german}
\usepackage[usenames]{xcolor}

\usepackage[showframe,
            a4paper=true,
            twoside=false,
            noheadfoot,
            nomarginpar,
            bindingoffset=0mm,
            vmargin=11mm, % top & bottom
            hmargin=20mm  % left & right
        ]
    {geometry}

\pagestyle{empty}

\begin{document}
\setlength{\unitlength}{1mm}
\begin{picture}(170,275) % 2x5 Vistenkarten je 85mm breit und 55mm hoch
    \multiput(0,0)(0,55.0){5}{% 5 rows je 55mm
        \multiput(0,0)(85,0){2}{% 2 columns je 85mm
        \begin{picture}(85,55)
        \put(0,0){\color{red}\dashbox{1}(85,55)} % for help
      \end{picture}}}
\end{picture}
\end{document}
Nur nochmal zum Überblick, es sollen 2x5 Felder (Vistenkarten) in der Größe je 55x85mm aufs A4 Blatt.
Das ergibt bei den A4-Maßen (210x297mm) bei mir Seitenränder von 20mm links/rechts und 11mm oben/unten.

1.
Die dashbox ist insgesamt immer noch nach rechts verschoben. Warum kann ich nicht nachvollziehen. Habe (meiner Meinung nach) eigentlich alle relevanten marings auf 0 gesetzt.
Mache ich vielleicht mit picture/put etwas falsch?

2. includehead/foot
Diese Werte stehen per default auf false. Setze ich sie auf true reicht der Platz oben/unten nicht mehr aus. Ich dachte "false" bedeutet, dass z.B. der Kopf NICHT zum Textkörper gerechnet wird, also mehr Platz benötigt wird (Kopfzeilenhöhe plus Textkörperhöhe). Aber es scheint anders herum zu sein.
Versteh ich nicht, sieht aber gut aus, wenn ich meine dashbox mit dem von geometry gezeichneten Frame vergleiche.

von Besserwisser » Di 14. Apr 2015, 19:45

-0,8 Inch sind doch kein relativer Wert. Das ist ein ziemlich absoluter Wert. Es ist aber nicht der komplette linke Rand, weil TeX da immer noch 1 Inch draufschlägt. Das ist einer der Gründe, warum es einfacher ist, geometry zu verwenden. Da muss man solche Spezialitäten von TeX nämlich gar nicht erst wissen. Genauso muss man nicht wissen, dass \evensidemargin keineswegs der rechte Rand ist, wie manche Menschen seltsamerweise glauben, und dass der Wert dafür im gezeigten Beispiel nie zur Anwendung kommt.

von MoonKid » Di 14. Apr 2015, 19:06

Johannes_B hat geschrieben:Klar, nimm geometry.
Danke, die Aussage ist ja mal klar und deutlich. ;)

Aber um meinen Lerneffekt zu vergrößern, würde ich den bestehenden Code schon gerne besser verstehen.
Scheinbar werden hier die Ränder gar nicht wirklich fest eingestellt? oddsmargin z.B. ist ja auch nur ein relativer Wert - wegen dem '-' davor. Oder?
Was wird da insgesamt wirklich gesetzt?

von Johannes_B » Di 14. Apr 2015, 18:24

Klar, nimm geometry.

Dinge von Hand zu regeln ist nicht Sinn der Sache.

Nach oben