..korrumpierte Tasten Symbole, paket menukeys..

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: ..korrumpierte Tasten Symbole, paket menukeys..

von Gast » Mo 8. Okt 2012, 07:43

Die Standardklassen rufen \normalsize eigentlich auch unmittelbar nach \ProcessOptions indirekt via \input{size1\@ptsize.clo} bzw. \input{bk1\@ptsize.clo} auf. Warum das für menukeys nicht genügt und erst das \normalsize in \begin{document} tatsächlich die Schriftgröße einstellt, ist mir auch nicht klar.

von iTob » So 7. Okt 2012, 22:34

Nabend,

ich verstehe das richtig und bin hocherfreut, dass ihr das für mich rausfindet, danke :-) Das ex habe ich benutzt, damit die Symbole sich der Größe anpassen, das die Größe aber wegen der Box fest bleibt hatte ich nicht bedacht. Das ursprüngliche Problem war, dass die Symbole die TikZ-Optionen der umgebenden Rahmen erben, wenn sie nicht durch eine Box gesichert werden. Ich muss mir das noch mal durch den Kopf gehen lassen, aber vielleicht wechsle ich einfach auf Grafikdateien …

Gute Nacht
Tobi

von bloodworks » So 7. Okt 2012, 19:39

Recht hast du ein \normalsize irgendwo am Anfang des Paketes tuts auch. Die Frage ist jetzt natürlich ob so ein mehrfaches Aufrufen von normalsize besser bzw schneller ist als es nur einmal aufrufen zu lassen (imho machen das die Std-Klassen recht kurz vor begin{document}) und eben die Ausgabe zu verzögern.

Abgesehen davon denke ich auch dass das koppeln von Zeichengröße und den Bildern via ex recht gefährlich ist. Ich denke was Gast mit dem Vorteil von Macros gegen Boxen meint ist folgendes:
\documentclass[12pt]{article} 
%\usepackage[T1]{fontenc} 
\usepackage{menukeys_test} 

\begin{document} 
 CMD+S: \keys{\cmd+S}. 

 ESC: \keys{\esc} 
  ESC: \keys{\del} 
\Huge
 ESC: \keys{\esc} 
  ESC: \keys{\del} 

\end{document}
Die Größe der Keys wird eben am Anfang mit der Grundschrift bestimmt und ändert sich nach Umschaltern nicht mehr.

@Tobias: Ich hoffe du verstehst das jetzt richtig und zwar nicht als Kritik sondern als konstruktive Hinweise. Und ich hoffe dass du da dran bleibst;)

von Gast » So 7. Okt 2012, 18:07

KOMA-Script (bzw. typearea) benötigt für die Berechnung des Satzspiegels die Schriftgröße und führt deshalb eventuell schon vor \begin{document} ein \normalsize aus (ggf. auch mehrfach). Bei KOMA-Script kann man übrigens auch noch nach \begin{document} die Schriftgröße per \KOMAoptions{fontsize=…} ändern. Ich habe jetzt nicht ausprobiert, was sich daraus für die Verwendung von menukeys ergibt (ich habe kein lauffähiges LaTeX auf meinem Handy), aber ich vermute, dass die festen Boxen dabei eher von Nachteil sind und Macros dann besser wären. Allerdings ist für die Änderung der Grundschriftgröße innerhalb des Dokument in der KOMA-Script-Anleitung (oder zumindest im Buch) auch angegeben, dass eventuell nicht alle Pakete damit zurecht kommen.

von bloodworks » So 7. Okt 2012, 17:24

Deine Vermutung Clemens ist absolut richtig! Die Boxen in denen die Bilder (zB der Blumenkohl) leben werden zu früh definiert. Ersetzte ich LOC 764-776 in menukeys.sty mit
\AtBeginDocument{
\tw@define@mackey{%
   \def\tw@mk@cmd@mac{cmd}%
}{%
   \tw@make@key@box{cmd@mac}{%
      \begin{tikzpicture}[yshift=-0.15ex,baseline={(0,0)},semithick,red]
         \draw (0.5ex,0.7ex) -- (0.5ex,1.25ex) arc (0:270:0.25ex) -- %
               (1.25ex,1ex) arc (-90:180:0.25ex) -- (1ex,0.25ex) %
               arc (-180:90:0.25ex) -- (0.25ex,0.5ex) arc (90:360:0.25ex) %
               -- cycle;
      \end{tikzpicture}%
   }%
}}
Dann sieht das Ergebnis richtig aus. So können alle Keys-Boxen verzögert werden. Dann sollte es mit allen Dokumentenklassen (ausser vll minimal) funktionieren, egal ab wann in der Präambel der ex definiert wird. (Was logischer Weise erst nach dem "laden" der Schrift der Fall ist. Ich denke KOMA z.B. lädt selbst irgendwo die Schriften.)

Es kann vll sogar der ganze Abschnitt der Boxen in dem sty auf einmal verzögert werden, das muss ich mal ausprobieren ;). Es scheint aber zu funktionieren. Also einfach in LOC 688 ein AtBeginDocument und gut ist...

grz Tobias

von iTob » So 7. Okt 2012, 16:55

Ich hatte dieses Ergebnis auch schonmal, zumindest kommt mir die Ausgabe bekannt vor. Ich weiß aber nicht woher – im Moment habe ich leider auch keine Zeit, an dem Paket zu arbeiten, dass wird wohl frühestens Weihnachten wieder was …

von cgnieder » So 7. Okt 2012, 16:10

Das vergesse ich auch immer wieder, da ich alle meine Dokumente mit KOMA erstelle…

Ich habe auch keine Idee, was hier eigentlich passiert. Der Versuch, das Phänomen in einem MWE nachzubasteln, ist bisher gescheitert.

Grüße

von iTob » So 7. Okt 2012, 15:59

Hi Clemens,

danke für den Hinweis :-) Für mich sind die KOMA-Klassen inzwischen einfach so selbstverständlich, dass ich gar nicht an die anderen gedacht habe. Ich dachte allerdings auch nicht, dass diese sich bei so grundlegendem voneinander unterscheiden.

Grüße
Tobi

von cgnieder » So 7. Okt 2012, 15:25

Das muss was mit dem Zeitpunkt zu tun haben, wann festgelegt ist wie groß ein ex ist... das hier funktioniert:
\documentclass[12pt]{article}
\usepackage[T1]{fontenc}
\usepackage{menukeys}

\begin{document}
CMD+S: \keys{\cmd+S}.

ESC: \keys{\esc}

\end{document}
Grüße

PS: IMHO sollten Tests immer zuerst mit Standardklassen stattfinden (und dann auch mit KOMA und memoir) (so hab ich schon einige Überraschungen erlebt mit Code von mir...)

von iTob » Sa 6. Okt 2012, 21:26

Ne, darauf weise ich nicht hin, weil mir dieses Verhalten nicht bewusst war und ich nur mit KOMA-Klassen arbeite (und auch nur damit getestet habe :oops: )

Nach oben