[Maxim Nikulin]

This patch was sent to gnuplot-beta on April, 26 2013.

I have tried to check if the patch leads to memory leaks.
Valgrind reports report roughly the same amount of issues
as for the program built from original sources.

Handle font style and weight in enhanced strings
(e.g. "sin({/Serif:Italic x})") for cairo-based terminals.

Colons are replaced by spaces and the string is passed
to pango_font_description_from_string().
No parsing of 'Italic' and 'Bold' withing gnuplot
is required anymore. Font size set by pango is ignored
(e.g. "{/Times:12 x}"). Font size still managed
by gnuplot in traditional ways ("Serif,16" in term options
and enhanced strings "{/=16 x}" or "{/*1.4 x}").
Hyphens in font names should not be touched unlike current
version of gp_cairo_set_font().

I have used your patch as inspiration to implement this in a slightly different way so that it can be extended to other terminal types also. I used the LaTeX-like syntax {\bf Bold text here {\it Italic (and bold) text here}}. It currently works for the cairo terminals, for qt, and partially for the libgd terminals. Now in CVS for version 4.7

I'm not entirely happy with the syntax because the backslash needs to be escaped if you are using double quotes rather than single quotes.

Hi,

I strongly agree with using a consistent font handling for all terminals (all but the LaTeX ones). That would be one good project for version 5.

However, I wouldn't adopt the \bf, \it etc. syntax. This is TeX and not LaTeX syntax, and for LaTeX documents this syntax is even deprecated, because it has some flaws, see e.g. http://tex.stackexchange.com/questions/516/does-it-matter-if-i-use-textit-or-it-bfseries-or-bf-etc

I like the version with the colons, although one should look a bit more into it regarding the exact syntax, if it can be adapted to work with other terminals as well, were more manual intervention than replacing colons with spaces is required. How to distinguish font name, weight and style, e.g. /Times:Italic:12 vs. /Italic etc?

TeX flaws:
See below for a long answer. In short the gnuplot implementation does not have the flaws of the TeX one.

Thanks for implementing this in a more general way! Below are my 2 cents on the syntax and the implementation:

While I understand the desire to keep the interface backwards compatible, I strongly dislike passing the bold/italic info as part of the font string. Why not extend the interface with another parameter instead?

In enhanced text {/Bold bold text} and {/Italic text} seem a bit more natural to me and avoid the backslash problem. This would imply that we cannot use typefaces called "Bold" or "Italic", but I don't think that is a real problem.

It is also not unreasonable to accept italic/bold specifications in other places where a font specifier is allowed. In my opinion the syntax should be compatible in order to be consistent. This means that we probaly should go for something like "Times, Italic, 12", i.e. commas instead of colons.

I strongly dislike passing the bold/italic info as part of the font string.
Why not extend the interface with another parameter instead?

1) I thought it would be a pain to revise the _enhanced_open() definition in 20 or so terminal drivers. Also I am not fond of functions that take so many (8 in this case) parameters. At that point I'd seriously consider revising it to take a single parameter consisting of a structure or structure pointer.

2) Although internally the enhanced and plain mode text processing goes through different paths, this is not so obvious to the user. These two commands go through different paths although they appear to do the same thing:

set label "Uses non-default font" font "MyFont,12"
set label "{/MyFont=12 Uses non-default font}"

Some terminals already recognize substrings "Italic" and "Bold" if appended to the font name in path (1), but no terminals were paying any attention to this in path (2). I chose to systemetize the convention already used in path (1) and use it also in path (2).

I first tried an earlier version in which you could pass the extended font name directly to either path:

set label "{/MyFont,Italic,Bold=12 Both paths use same name}"
set label "Both paths use same name" font "MyFont,Italic,Bold,12"

I ran into problems with that and changed gears, but if that is strongly preferred I could go back and look at that variant again. One problem was that it did not lead to the nesting I expected from a recursive algorithm. Suppose you want an italic subscript for a boldface variable a_i all in Times.
This didn't work:

set label "{/Times,Bold a_{/,Italic i}}"

Whereas what I eventually ended up with does work:

set label "{/Times \bf a_{\it i}}

This, by the way, is different from the behavior of \bf and \it in TeX. It is why LaTeX deprecated these operators in favor of the functional forms \texbf{...}. I cannot speculate why TeX got this wrong, since usually Knuth is infallible. Anyhow in gnuplot they nest properly.

This means that we probably should go for something like
"Times, Italic, 12", i.e. commas instead of colons.

That is almost exactly what it does internally. "/Times \it text" is converted by the new routine term.c (stylefont) to "/Times,Italic text". As I tried to explain above, my original thought was to allow the user to give this directly if they preferred, but this imposed a requirement to list the full set of attributes everywhere a font is given rather than letting the program keep track of nesting them for you. Maybe that is fixable but I didn't see a good way to do it at the time.

Whereas what I eventually ended up with does work:

set label "{/Times \bf a_{\it i}}

This, by the way, is different from the behavior of \bf and \it in TeX. It is why LaTeX deprecated these operators in favor of the functional forms \texbf{...}. I cannot speculate why TeX got this wrong, since usually Knuth is infallible. Anyhow in gnuplot they nest properly.

It is this discrepancy between TeX and the "correct" nesting which might confuse the user. One could think of a TeX-like syntax, that gnuplot and TeX behave the same, which wouldn't be the case. Maybe one could use \bold and \italic to have this distinction?