As suggested by egreg, I will turn my comments into an answer to at least part of your question:
One would think that perhaps the Computer Modern fonts themselves
might exist in some form (encoding + format) that would allow them to
be used from within Emacs, and if so has anyone had success using them
for this purpose?
You could use the CM-Unicode fonts, which are installable under Windows on OS level and therefore usable from all applications using the system fonts. I use these fonts in Inkscape, Word and PowerPoint.
Quoting from the CM-Unicode homepage:
Computer Modern Unicode fonts were converted from metafont sources
using mftrace with autotrace backend and fontforge (former pfaedit).
Their main purpose is to create free good quality fonts for use in X
applications supporting many languages. Currently the fonts contain
glyphs from Latin1 (Metafont ec, tc, vnr), Cyrillic (lh) and Greek
(cbgreek when available) code sets and IPA extensions (from tipa).
You also ask about STIX fonts. These fonts are also available in otf format, so I would say it should be easy to install these fonts on system level.
I've done a little experimenting, and have some code that I hope will help you. It's not a complete solution by any means.
It appears that an adviedit
able macro has to be of the form \macro{x=<value>,y=<value>}
for whizzytex
to be able to feed the numbers back in. My first idea was simply to add a style to a \node
so it looked something like \node[advi={x=<value,y=<value>}]
but that didn't seem to work (maybe more experimenting would reveal a way to make this work). So I defined a wrapper around the \node
command which took the coordinates at the start and then handed control over to the original \node
. Because of the way that \node
executes the options it is given (as in \node[draw]
), there's no problem with this.
Here's the code. I'll comment on it in the code.
\documentclass[12pt]{article}
%\url{http://tex.stackexchange.com/q/50468/86}
\usepackage{advi}
\usepackage{tikz}
% We need to use some internal commands with `@`s in them for getting
% the widths of the nodes
\makeatletter
\tikzset{
% This is the workhorse style
advi/.style={
% We do the advi stuff after the node has been placed so that we can
% get access to its width and height. What this means is that our
% node ends up being equivalent to
% \node[at=(x-value,y-value)] {node text} [advi/set advi={x=,y=}];
append after command={[advi/set advi={#1}]},
% As the advi boxes are specified by lower-left corner, we anchor our
% node at the lower-left so that the given coordinate is the node
% coordinate
anchor=south west,
% The parameter #1 is of the form "x=<value>,y=<value>". We trick
% TikZ into taking that as defining some keys in the "/tikz/advi"
% directory
advi/.cd,
#1,
% We use the values that have just been set, namely `/tikz/advi/x`
% and `/tikz/advi/y` to specify the location of the node via the
% `at` key. We need to give the full path as we're currently in at
% `/tikz/advi`
/tikz/at={(\pgfkeysvalueof{/tikz/advi/x},\pgfkeysvalueof{/tikz/advi/y})}
},
% This next bit ensures that the `/tikz/advi/x` and `y` keys can be
% used to store values.
advi/.cd,
x/.initial=0,
y/.initial=0,
% This is the part that specifies the boxes in the dvi. This is
% actually executed after the node has been processed
set advi/.code={
% As the node has been processed, we can get its width and height by
% looking at a couple of anchors.
\tikz@scan@one@point\pgfutil@firstofone(\tikzlastnode.north east)
\pgf@xa=\pgf@x
\pgf@ya=\pgf@y
\tikz@scan@one@point\pgfutil@firstofone(\tikzlastnode.south west)
% We adjust the values to be multiples of `em`s as that's the default
% for advi/whizzytex
\pgfmathsetmacro{\advi@node@w}{(\pgf@xa - \pgf@x)/1em}%
\pgfmathsetmacro{\advi@node@h}{(\pgf@ya - \pgf@y)/1em}%
% Finally, we call the `\adviedit` command
\adviedit{comm=\advinode,w=\advi@node@w,h=\advi@node@h,#1}{}%}
}
}
\makeatother
% This is the command that whizzytex will look for.
\newcommand{\advinode}[1]{%
\node[advi={#1}]
}
\begin{document}
hello world, how are you?
% We use `em` units as those are the defaults for advi/whizzytex.
% Presumably this could be made configurable or some wizardry used
% to ensure that the tikz coordinates and the advi coordinates
% matched.
\begin{tikzpicture}[x=1em,y=1em]
% We can even pass ordinary styles to the node:
\advinode{x=13.6805,y=7.3048}[red,draw] {A};
\advinode{x=5.7699,y=10.5065}[circle,fill=blue!50] {B};
\advinode{x=6.464,y=6.6085} {C};
\advinode{x=7.2497,y=7.8264} {D};
\advinode{x=3.7562,y=6.9931} {E};
\advinode{x=1.8567,y=12.5472} {F};
\advinode{x=9.3650,y=7.0893} {G};
\advinode{x=13.9264,y=4.4529} {H};
\advinode{x=11.4138,y=11.5331} {I};
\advinode{x=3.3900,y=2.6800} {J};
\end{tikzpicture}
\end{document}
I don't trust trying this with the standalone
class, so here's a screenshot instead.
The blue boxes and green lines are those drawn by advi
. Note that they are drawn under the drawing, so are overwritten by the border of the A
node and the filled region of the B
node. They are draggable.
The green lines show that the coordinates are relative to something. Experimenting shows that they are relative to the (0,0)
inside the picture - which is what it should be. (A quick look at the code for advi.sty
shows that there is some interaction with PGF builtin which probably takes care of this bit).
(Lastly, this looks very intriguing and definitely worth learning about.)
Best Answer
UPDATE, 11/10/11: I've posted the code at https://github.com/blerner/auc-tikz -- the most recent version is
auc-tikz-struct.el
(the other files are older experimental versions). I haven't had time to update the code in a while, so if people want to tinker with the code, have at it! It's still rough, but it should sorta work if you'd like to try it out.Original answer
Per @egreg's request, a comment-turned-answer, and some elaboration on what's tricky about this prospect: I tried writing an AUCTeX TikZ highlighting plugin to address the first bullet point in your question, though I haven't had much time since my comment to work on it. The challenge in writing a syntax-highlighting mode (aka "font-lock" mode or "fontifying") for any part of emacs is that emacs uses regular expressions to match text. TikZ's grammar ... is not regular. In particular, the
key=value
portions are recursive, since you might havekey={key=value,key=value}
, as inWhile elisp's regular expressions do let you have backreferences (and therefore aren't true regular expressions), font-lock doesn't let you refer to the recursively matched subgroups, so you can't get the font-lock behavior you need. I've tried several possible approaches:
So I started (ab)using a more powerful approach, with Toby Cubitt's auto-overlays package (also the author of theAfter emailing the author, he recommended that I avoid this approach because emacs' performance suffers with too many overlays.cleveref
package). An overlay, in the parlance of this package, is similar to marking up a stretch of text with<span>
in HTML, so you can hook styles onto it. I don't fully understand how auto-overlays does its magic, but it allows you to dynamically create overlays based on matcher functions, and it will take care of deleting them when the text no longer matches. At least in theory it would, if I were using it properly :)There is a very contorted way to trigger an arbitrary function during font-locking, which can then be used to manually assign the
'font
properties to stretches of text. The trick is to use what's called an "anchored match", which lets you define some functions that get called in lieu of the default font-highlighting. But this leads to infinite loops for me, because font-lock is very brittle with multi-line matches.The approach that seems to be working is to hijack AUCTeX's hijacking of the font-lock mechanism, and after AUCTeX finishes, double-back and check whether there's a
tikzpicture
environment and if so, manually assign font-lock highlighting to it. There's still a subtle bug in that emacs re-highlights only chunks of the buffer at a time, so my code can correctly highlight the TikZ code but the colors won't be shown until the page is fully refreshed.The upshot is I have a new package in the works, called
auc-tikz.el
, that builds some highlighting functions that properly match the grammar of thekey=value
part of TikZ, including the recursive parts, and a hard-coded recognition of the\tikzset
command as a trigger to create an auto-overlay. It looks like this, in my current color scheme:/Key/paths
are recognized separately from the final/.command
(as iniface/.style
), so that you can see which settings are simple names (draw,fill=blue!20
) and which are somewhat meta (iface/.style
). Braces are purple when they delimit a TikZ option group (iface/.style={...}
), but are light blue when they're part of a value (mark=at position...{...}
). Comments are mostly supported, though they may still have some unintuitive behavior. Unknown commands are red, from the first parsing error up through the next uncommented semicolon.The
\node
,\path
and\draw
(and any other) commands are not parsed properly, particularly not all the locations[options]
can be interspersed in such commands. All the various coordinate forms are not parsed properly; I currently have (coord), ++(coord) and (coord)+(coord) support. Other forms, like($(coord)!calc!(coord)$)
, are not yet supported. (They kinda sorta work, because the parser just looks for a balanced paren group; if you left out a closing$
, it would mistakenly highlight as correct...)"All" that remains to do is recognize the generic TikZ
\macro ... ;
syntax, and get the highlighting to refresh properly. And support nested environments, likepgfonlayer
andscope
and such. And speed the code up considerably; it's slow to parse even a smallishtikzpicture
.