[GR] Any way to have native <text> in SVG?

[akdor1154]

Hi,
Foreward: I'm a new Julia user so apologies if I've missed anything.
Foreward 2: Thanks for maintaining this great library, and the clear effort that has gone into making a complex set of systems work well for newbies.

I'm trying to plot SVGs with the default GR backend and I'd like the text in the SVGs to be rendered as <text> elements. The default behaviour seems to "pathsterize" text, turning each letter into a path. This would
a) mean users can copy and paste labels from my plots
b) reduce the size of figures significantly.
c) hopefully eliminate the restriction of GR's limited font set (at the cost of making the output figure vary based on what's available on the user's computer).

Is this behaviour possible in the GR backend? Or in another backend that can produce SVGs without either running a headless browser or pulling in all of Python? :)

Cheers
Jarrad

[daschw]

@jheinen is this feasible for GR?

[jheinen]

In this case you will have to select another font (e.g. plot(..., fontfamily="helvetica").

[akdor1154]

ah ok, thanks. does that work for any font? or is it just a side effect of what gr does if I choose a font it doesn't know about?

[jheinen]

It works for the built-in fonts. There are more than 30 fonts in GR and Plots seems to support the following values for fontfamily: "times", "helvetica", "courier", "bookman", "newcenturyschlbk", "avantgarde" and "palatino".

[akdor1154]

Either that doesn't work on my machine or we aren't quite understanding each other.
Passing fontfamily="aaa" doesn't affect what I am seeing.

I am seeing text represented as a <path> element for each letter. E.g. my title in the resulting plot is represented as:

<path clip-path="url(#clip2900)" d="M 0 0 M1696.58 14.0809 L1696.58 22.0612 Q1691.92 19.8332 1687.78 18.7395 Q1683.65 17.6457 1679.8 17.6457 Q1673.12 17.6457 1669.47 20.2383 Q1665.87 22.8309 1665.87 27.611 Q1665.87 31.6214 1668.26 33.6873 Q1670.69 35.7128 1677.41 36.9686 L1682.36 37.9813 Q1691.51 39.7232 1695.85 44.1387 Q1700.22 48.5136 1700.22 55.8863 Q1700.22 64.6767 1694.31 69.2137 Q1688.43 73.7508 1677.05 73.7508 Q1672.76 73.7508 1667.89 72.7785 Q1663.07 71.8063 1657.89 69.9024 L1657.89 61.4765 Q1662.87 64.2716 1667.65 65.6895 Q1672.43 67.1073 1677.05 67.1073 Q1684.06 67.1073 1687.87 64.3527 Q1691.67 61.598 1691.67 56.4939 Q1691.67 52.0379 1688.92 49.5264 Q1686.2 47.0148 1679.97 45.759 L1674.98 44.7868 Q1665.83 42.9639 1661.74 39.075 Q1657.65 35.1862 1657.65 28.2591 Q1657.65 20.2383 1663.28 15.6203 Q1668.95 11.0023 1678.87 11.0023 Q1683.13 11.0023 1687.54 11.7719 Q1691.96 12.5416 1696.58 14.0809 Z" fill="#000000" fill-rule="evenodd" fill-opacity="1"></path>
<path clip-path="..." d="M 0 0 ..."></path>
...

Where the first <path /> is just the letter N.

Instead I am wanting the title to be represented in the final svg as e.g.

<text fontfamily="helvetica">NetSales</text>

which is clearly much smaller, and also semantically available as meaningful text to viewers.

[jheinen]

You have to use one of the pre-defined font names (as mentioned in my previous post), e.g:

using Plots
plot(title="Test", fontfamily="helvetica")
savefig("test.svg")

results in:

...
<text style="fill:#000000; fill-opacity:1; font-family:Arial,Helvetica Neue,Helvetica,sans-serif; font-size:84px; text-anchor:middle;" transform="rotate(0, 1253.33, 73.2)" x="1253.33" y="73.2">Test</text>
...

[akdor1154]

that's strange, I tried with both helvetica and arial and both resulted in <path>s. I'm running in a notebook, maybe IJulia's display system is interfering somehow?

[jheinen]

Unfortunately, I can't reproduce this:

[akdor1154]

huh how odd. I'll have more of a play and try and figure it out, thanks for your help with this. Are there any criteria that GR will use to decide which method to use (e.g. drawing libs available, I'm on Linux so could easily be missing libraries for example)?

[akdor1154]

ahh figured it out, I made a dumb typo adding the parameter! Sorry... thanks for your help. :) I guess this issue can be closed then, if you consider this behaviour to be a guaranteed part of GR's API?

[jheinen]

Yes - the (new) vector fonts can only be used with a new text precision (TEXT_PRECISION_OUTLINE) to ensure compatibility.