Department of Statistics
The University of Auckland
This document follows on from the discussion of font specification in R by looking at the user-level interface for specifying fonts and then considering new specifications for line end/joins and alpha transparency.
Adding new graphical parameters to the graphics context requires three steps: the appropriate slots must be added to the R_GE_gcontext structure (forcing a recompile of all graphics systems and graphics devices); graphics systems should then provide some interface for the user to set/get these parameters; graphics devices should attempt to honour the new parameter settings.
double cex; double ps; int fontface; char fontfamily;The following font family names are interpreted as Hershey vector fonts (and handled by the graphics engine rather than passed on to the graphics device): "HersheySerif" , "HersheySans" , "HersheyScript" , "HersheyGothicEnglish" , "HersheyGothicGerman" , "HersheyGothicItalian" , "HersheySymbol" , "HersheySansSymbol".
For base graphics, the suggestion is to allow the existing font par() to be a list specifying both family and face.
To allow the user to solve any ambiguity, each device should provide a dev.options() function, which includes a fontdb option. The fontdb is a list of named elements, where the name is a font family name and the element is a device-specific description of the font family to be used.
The fontdb must include the following "generic" font family specifications (even if the same font is used for all of them): "sans", "serif", "symbol", "mono". An example for ps.options might be ...
ps.options(fontdb=list(sans="Helvetica", serif="Times", symbol="Symbol", mono="Courier"))... and for x11.options ...
x11.options(fontdb=list(sans="-*-helvetica-*-*-*-*-*-*-*-*-*-*-*-*", serif="-*-times-*-*-*-*-*-*-*-*-*-*-*-*", symbol="-*-symbol-*-*-*-*-*-*-*-*-*-*-*-*", mono="-*-courier-*-*-*-*-*-*-*-*-*-*-*-*"))The default fontfamily will be "sans" to provide the current default behaviour.
Font family specifications which are not in the fontdb will not be modified and each device will try to satisfy the specification as well as it can. If the user decides that the device does not produce the desired behaviour for a particular font family specification, then the user can add an element to the fontdb to obtain the desired behaviour. For example, if X11 is not finding the right font for "Helvetica", the user could do something like ...
myfontdb <- x11.options("fontdb") myfontdb$Helvetica <- "-adobe-helvetica-*-*-*-*-*-*-*-*-*-*-*-*" x11.options(fontdb=myfontdb)Similarly, a windows user could enforce TrueType font selection ...
myfontdb <- win.options("fontdb") myfontdb$Arial <- "Arial [TT]" win.options(fontdb=myfontdb)For very special cases, one-off font family names could be created ...
myfontdb <- win.options("fontdb") myfontdb$ArialTT <- "Arial [TT]" myfontdb$Arial <- "Arial" win.options(fontdb=myfontdb)
I think a different approach will be necessary for file-based devices where header information needs to include a declaration of the font resources used in the document. Here I am thinking of: PostScript, PDF, SVG.
My suggestion is that in these cases the full set of fonts to be used has to be declared when the device is opened. For example, something like:
postscript(family=c("Courier", "Helvetica", "Times"))
I'm not sure yet what the situation is for xfig or PicTeX.
The first issue is with the specification of transparent colours. It would be possible (though a reasonable amount of work) to modify the colour-generating functions (e.g., rgb, hsv, ...) to accept an extra "alpha" argument. However, it is not simple to extend the specification of colours by name (e.g., col="red") to include a flexible description of transparency.
A similar problem arises in converting an internal R colour back into a user-level colour name (e.g., rgb(0, 0, 1) produces "#0000FF").
An alternative imlpementation would add a separate alpha slot in the R_GE_gcontext -- essentially make the specification of the colour and the specification of the alpha level independent. This would imply a common alpha setting for both col and fill within a single R_EG_gcontext, which is a little more restrictive (for example to get a rectangle whose border and fill have different alpha transparencies you would need to draw two separate rectangles), but would avoid some of the problems with the alpha channel approach. For example, semi-transparent red becomes something like:
(col="red", alpha=0.3)A third alternative would be to have separate "colalpha" and "fillalpha" slots in the R_GE_gcontext to allow separate border and fill transparencies in a single specification.
PDF also specifies transparency as a separate property.
In Java (Graphics2D), transparency is part of a color description.
As discussed above, the simplest thing to implement for base would be a new "alpha" par().
I think the following devices should be capable of honouring an alpha transparency: SVG (for sure), Quartz (though I'm guessing), gtk (also guessing), gnome (guess), Java, PDF (although the device would need updating to support version 1.4).
I have no idea for Windows.
I'm pretty sure the following cannot support transparency: PostScript, xfig, X11. But there are X11 extensions which do support transparency (need to determine whether the appropriate extensions [Render?] can be assumed to be available).
I totally assume that PicTeX cannot support transparency.
plot(1:10, type="h", lwd=30)The proposal is to add line end and line join specifications to R.
int linecap; int linejoin; double mitrelimit;
I haven't looked yet, but I'd be mightily surprised if these ones couldn't do it: Windows, Quartz, Gnome, gtk.
I have no idea yet whether PicTeX will support it.