These diagrams are in .svg format.
versions are also available.
The Postcript equivalent can be found in examples.ps of the distribution.
Click on the link to view the source of each diagram.
These diagrams have been adapted from the Circuit_macros examples in
order to test the experimental svg output of dpic.
Generating the line art is relatively straightforward, but
the labeling is not created by a text processor and therefore must be
more basic. Some of these diagrams might benefit from a little more
tweaking of fonts and labels.
There are a number of issues:
Embedding .svg files in html documents with the <embed> or
<object> tag seems to be a perennial issue.
This file has been tested mainly by using the Firefox browser,
which works well except for a problem placing subscripts.
Internet Explorer versions 8 and lower are problematic. Version 9 seems
to place text differently than other browsers. The Chrome
browser seems to work well with two issues detected to date:
a difference handling color fills and text links in svg. Left and right
justified text is also different from Firefox. Is there a definitive
list of differences somewhere?
The Adobe reader apparently requires a line of the form
<embed src="figure.svg" width="x" height="y" type="image/svg+xml"
This means that the html file has to contain dimension
information for each figure, whereas Firefox can
determine the figure size
from the <svg ... object. Currently, dpic includes a comment line
giving reasonable dimensions in pixels but this has to be insterted into
the <embed or <object line. A makefile does it easily but
otherwise this could be tedious.
The font face is not specified by default in these diagrams but is
inherited from the enclosing document. The default appearance of labels can
differ according to the browser.
The <svg tag may require modification
from the default used for this test. Dpic might be modified to
allow the generation of custom headers but that has not yet been done.
Diagrams such as these contain a considerable number of text labels
that have to be treated differently from the LaTeX-compatible versions.
Apparently there is no direct way to know the bounding box of arbitrary svg
Consequently, text placement is approximate and may require
Rather than patch the original source files for svg production, edited copies
have been used. The configuration file svg.m4 read by m4
prior to libcct.m4 contains the following macros defined for svg.
Others should be defined to exercise some of the media capabilties of svg.
They are subject to change:
Change font face, size, and dpic textoffset parameter.
If arg4 is blank, the font is changed and
requires command "</g>" to cancel the font change.
Examples: svg_font(Times) svg_font(Times,11bp__,1bp__,"text" at A) svg_font(font-family="Times") svg_font(font-family="Times" font-style="italic") svg_font(style="font-family:Times; font-style:italic")
svg_it: for italics
svg_tt: for monospace (courier)
svg_norm: for normal text
svg_bf: for bold face
svg_small: to set a smaller text size, default 66%
svg_fsize: for setting larger or smaller text size
link to external file using
<a xlink:href=...>...</a> (default is
arg 3 = B)
svgLinkString as above but for strings attached to objects
Inkscape: It may be efficient to define elements by macro and to
place them using a wysiwyg graphics editor. A draft page intended
for Inkscape is included. A reasonable variety of elements is defined
but many more could be added and they should be customized for
Link experiments: Click on the resistor or source of quickSVG
to go to external
files in new windows. Click on "n-port" in NportSVG to replace the diagram
and then "back" to return.
Some of the assumptions used to create this draft may be naive. Comments