# One method to convert Text to SVG-File.

The problem can exist, that we want to import text into an application, which nevertheless expects a graphics file, but that the application is strong enough to accept SVG-Files as an available graphics-file format.

In studying this problem, I came to a discovery which was new to me about what SVG-Files are. In fact, SVG is a markup-language similar to HTML or to XML, so that by default, SVG-Files are actually text-files ! This also means, that if our Web-authoring software offers to embed SVG, this is not done with an <embed> -tag, as if the file was to be treated as some sort of image, but rather, using an actual <svg> -tag.

The main difference in SVG-Files would seem to be, that they prepend an <xml> -tag, making the file a self-contained document.

What this also means, is that text can be converted into SVG-Files most-efficiently, using a text-editor, where we’d first set up a template, then copy that to a new file-name every time we need a working SVG-File, and then just edit the text…

The following is a type of template which has worked for me, in experiments I carried out:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<!--
Instructions for Windows users:
This file will probably need to be renamed
From: Template.svg.txt (where .txt was hidden)
To:   Template.svg

And then placed in a folder with other images.
A console window would need to be navigated to
the same directory...

Linux Usage:

cp Template.svg TextFile.svg
edit text/*:TextFile.svg

Windows Usage:

copy Template.svg TextFile.svg (Hypothetical Name)

For either Linux or Windows,
assuming Inkscape is installed and in the PATH:

inkscape -z -e TextFile.svg.png TextFile.svg

OR

inkscape -z -T -l TextFile-G.svg TextFile.svg

-->

<svg height="90" width="200">
<g>
<text x="10" y="15" style="fill:black;"
font-size="12" font-family="Liberation">Several lines:
<tspan x="10" dy="15">Second line.</tspan>
<tspan x="10" dy="15">Third line.</tspan>
</text>
</g>
</svg>


One assumption made in creating this template was, that Inkscape is installed in such a way, as to recognize the stated font-family. This parameter can just be omitted, in which case Inkscape would use whatever its default font is. But, to state such information provides consistent, predictable results. In contrast, I needed to set the font-size. Inkscape could default to an unexpected font-size, which in turn would lead to garbled output, in the resulting PNG-File. And, the default font-size Inkscape uses, appears to be the one last-set when the GUI was used.

(Edit 03/15/2018 :

By now, this template only serves as a working basis, for a shell-script I have written, which allows me to create such text-images with a single command. I have posted the script to my blog. But, if readers are nevertheless interested in understanding the workings of SVG-Files, I’m always leaving my existing ruminations as written blow… )

If the user was to change the font-size to 30, but use all the other parameters in the above script unchanged, he or she would notice, that the first line is cut off, while any following lines are advanced by only half the distance vertically, of the font-size / font-height.

Many target-programs fail to define the <tspan> -tag, which Inkscape defines. Without that, setting up multi-line text becomes much more difficult. In that case each line of text would need its own <text> … </text> tag-pair, and the style-info would need to be restated, while also, the absolute positioning of each line would need to be recomputed.

I hope the reader might find this to be useful,

Dirk

(Edit 03/14/2018, 17h35 : )

Even though both Inkscape and GIMP seem tolerant enough to accept this form of SVG-snippet, if I try to embed it into an actual Web-page using BlueGriffon, which has an SVG-import feature, the last of these 3 programs does not show any added content for the effort. Apparently, this naked style of writing SVG, lacks some of the required formatting.

Yet, if I first create an SVG-File using the GUI of Inkscape, then BlueGriffon imports that 100%. This suggests that the initial problem (with importing my snippet) is the fault of this spartan coding-style, not of BlueGriffon.

And, simply adding the <g> -tags, did not change the behavior in any way I can discern.

(Edit 20h25 : )

Apparently, in order to insert this ‘image’ in BlueGriffon, from the GUI of that Web-authoring application, we may choose ‘Insert -> SVG’, in the ‘SVG Edit’ window that opens, click on the first icon in the top-left corner, and from there, select “Open Image”, rather than “Import SVG”. Then, it works.

The significance of the <g> -tag is, to declare one nameless layer. In principle, any SVG-document is supposed to consist of one or more layers. And, the way SVG works in general, layers may additionally take the form of (nested) sub-layers. This is the effect obtained, when we use ‘Open Image’ from within BlueGriffon, as described in the previous paragraph.

I don’t think the previous absence of a <g> -tag from the code-snipped I published above, ever made any difference.

Another observation to add would be, that if we next import this snippet into a GUI-based editor, and then try to drag the bundle of text-lines around, all the Y-positions will be edited, but the X-position of the first line will remain altered, while the following lines’ X-positions will snap back to their original position. Technically, this is incorrect behavior, which I was willing to ignore, because my initial goal was to convert text into an image as fast-and-dirty as possible. But in reality, this behavior can be corrected, by making all the lines of text <tspan> -elements.

The idea would be, to leave the <text> -element empty except for the <tspan> -elements, and to give it ‘ x=”10″ y=”0″ ‘ . The result will be that they can all be dragged, but that they’ll all snap back to their initial X-position, at the left side of the image.

One reason I don’t post that solution however, is the fact that initial previews of the image, which could be too weak to recognize <tspan> -tags at all, will appear empty, while proper renderings will be as they should be. This could lead my readers to give up on the idea that the SVG-File is actually an SVG-File, early on in any attempts to analyze what I’ve posted. I leave it to the ingenuity of the reader to implement that, if he or she wants an SVG-File that’s fast-and-dirty to create, yet that can be edited visually.

Dirk