How to Control Fonts in SVG Images of Charts and Tables?

[Tex2002ans]

Originally Posted by MikeWV

No, I have not picked apart the SVG image files, as I haven't figured out how to do that yet.

SVG files are just XML files. You can just open them up with your favorite Text Editor.

Originally Posted by MikeWV

Unfortunately, Amazon's image specs are ambiguous and contradictory, so it's hard to tell what they really want and what they'll accept.

Yep, I agree.

SVG works in KF8, and shows up as a blank in the old MOBI format "KF7" (Kindle 1+2+DX). You need a JPG/GIF/PNG fallback.

Since you are going to create the JPG/GIF/PNG anyway, most publishers/converters just settle on the easiest + least labor intensive + least headache method... which "works" across all devices (although as you noticed, if an image of a table gets scaled up/down, the text starts looking like junk).

Originally Posted by MikeWV

I've attached my largest table and a chart in SVG format as requested. I've also attached a smaller SVG table and a PNG version of the large table that is low resolution and sized for a basic e-reader. When the PNG image is presented at dimensions that match the image dimensions, it looks good and is actually legible on my Kobo Touch. The files are in a zipped folder, as SVG is not a valid type for uploading.

Fantastic, thanks so much. Examples are a HUGE help!

Side Note: Fantastic work by the way, this is DEFINITELY better than a bunch of the crap that I get. SVG/Vector Graphs are a HUGE PLUS (you would be surprised how much JPG trash I have to work through... and then the source document gets lost in the abyss, and you have no way of generating a higher resolution image.... Makes me want to pull my hair out).)

Originally Posted by MikeWV

The part of my question that I haven't figured out is how to specify a non-proprietary or generic sans serif font within the SVG files, within the image tag or in the CSS that will override the font that is set in the software presenting the images to a reader. I really need a sans serif font for the larger tables, as tiny serifed fonts are not clear.

I attached an EPUB I put together testing a bunch of different stuff.

I opened up the SVG in a text editor, and spotted this:

<tspan
style="font-size:11.03999996px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Calibri Light;-inkscape-font-specification:Calibri"
x="0 5.59728 8.3793602 14.039999"
y="0"
sodipodi:role="line"
id="tspan3148">0.00</tspan>

As you can see, it is specifying a font. Anything prefaced with -inkscape can be tossed in the trash, that is only for Inkscape specific stuff if you ever wanted to reimport it back in (useless if you are sticking it in an ebook).

I did a Replace All and replaced everything in RED with what DaleDe mentioned above:

<tspan
style="font-size:11.03999996px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family: sans-serif"
x="0 5.59728 8.3793602 14.039999"
y="0"
sodipodi:role="line"
id="tspan3148">0.00</tspan>

This made the table display using a sans-serif font (I also tested on my Nook, and the font was the sans-serif font):

Before: After:

When using any non-Calibri fonts, letters ran into eachother (seen in the After picture above).

I wittled the error down to the part marked in BLUE (I think this is specifying an exact location of each letter along the x-axis?):

<tspan
style="font-size:11.03999996px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family: sans-serif"
x="0"
y="0"
sodipodi:role="line"
id="tspan3148">0.00</tspan>

I changed them almost all to x="0" and it solved a bunch of the characters running into eachother problem:



The EPUB includes:

• Your Original SVG
• An SVG where I implemented the RED change
• An SVG where I implemented the BLUE change
• 96dpi + 200dpi + 300dpi images which I generated from your SVG.
• Original + Blue expanded to 100% width via CSS
  
  • It seems to overflow off the bottom of the page on thinner devices.
    
    • Instead of that junky CSS, it would probably be much better to just emulate something along the lines of the typical SVG Cover code, which will stretch to max width and/or max height while keeping the same aspect ratio.
      
• HTML Table + a Split HTML Table (with some rough CSS to align/border cells).
  
  • This table CSS is junk, and doesn't work across devices, do not copy it. I just quickly put it together with no serious testing.
    
  • Side Note: The SVG information wasn't easily copy/pastable out. So I manually filled in a portion of the table.
    • Point proven... SVG/Images, NOT EASILY COPY/PASTABLE.

Anyway, I had a giant tome written tackling a lot of your statements/questions + a ton of screenshots... but it will take me a while to go through and edit it (and I am too tired currently). I will maybe post it tomorrow/in a few days tackling/discussing a few more of the things that were brought up.

[RbnJrg]

Originally Posted by MikeWV

I figured out part of the answer to my original question. The font used in the SVG images is the default font of the device on which it is displayed. For example, if I change the default font in Firefox to Calibri, the font in my SVG images is Calibri when I simply open an SVG file or an XHTML file containing an SVG image in Firefox. I also see Calibri in EPUBReader for Firefox. The default font in ADE is apparently Times New Roman and that cannot be changed.

The part of my question that I haven't figured out is how to specify a non-proprietary or generic sans serif font within the SVG files, within the image tag or in the CSS that will override the font that is set in the software presenting the images to a reader. I really need a sans serif font for the larger tables, as tiny serifed fonts are not clear...

When you want to use a custom font (any non-generic font) in a svg image, you have two ways:

1) Use the font of your election in Inkscape and, before saving the file, convert all the svg graph to "paths"; or

2) On the other hand, if you don't want to convert the font to paths, you have to embed it in the ebook where you are going to use that font. But before using it, you have to declare it in the svg graph by using:

    <defs>
       <style type="text/css">
         <![CDATA[
           @font-face {
              font-family: "MyFont"; /* Of course this name can vary */
              src: url("../Fonts/MyFont.ttf"); /* And here you'll write the font of your election */
           }
         ]]>
       </style>
    </defs>

You have to add that definition before using it in a <text> tag. For example:

<svg version="1.1"
     xmlns="http://www.w3.org/2000/svg"
     width="155" height="120">
    <defs>
       <style type="text/css">
         <![CDATA[
           @font-face {
              font-family: "Marnie";
              src: url("../Fonts/Marnie.ttf");
           }
         ]]>
       </style>
    </defs>
    <text x="77.5" y="117" style="font-size: 150px; font-weight: bold" font-family="Marnie" text-anchor="middle">T</text>
</svg>

If you are using Sigil, then your .ttf font must be in the Sigil "Fonts" folder and if you are going to use that font only in the svg graph, then is not necessary to include a @font-face declaration in your css stylesheet.

Regards
Rubén

NOTE: Sigil doesn't show the svg embeded fonts (a Sigil bug evidently) but if you open the ePub in ADE, you'll perfectly see your custom font in your svg graph.

[DaleDe]

Originally Posted by MikeWV

I've tried specifying the font family in about six different places, some in the HTML file and a couple in the CSS file, but none have had any effect.

Per the Amazon Kindle Publishing Guidelines, 1/1/14:
3.6.1 Image Guideline #1:
* Use Supported Input Formats The Kindle platform supports GIF, BMP, JPEG, non-transparent PNG, and Scalable Vector Graphics (SVG) images.
* When using images for schemas, charts, tables, maps, or anything that includes text, pay special attention to the legibility of the final image.
* Add images to the source using the standard HTML <img> tag.
* Use a resolution of 300 dpi or 300 ppi for all images.

Good to know that SVG is now supported in Amazon. The font family could be inside the SVG itself as part of the text according to the specs.

<text x="250" y="150" font-family="sans-serif" font-size="55" fill="blue" >
    Hello, out there
  </text>

Dale

[MikeWV]

I though I had it but I had opened an old file that had the PNGs rather than the SVGs. So no good news after all.

(I couldn't figure out how to delete my earlier post, so I just edited it.)

[MikeWV]

Yes, Dale, the font family is specified in the SVG file for every text element in the file. I opened couple of the SVGs with Notepad++ and looked for a means of specifying the font family universally or forcing the SVG font specification to override the browser/reader default font but struck out.

According to what I read earlier today, applying "font-family: sans-serif" to the parent element should set the font for the SVG. But as I said earlier, it's not working. The parent element is an inline block specified by a CSS class. I tried adding the style to the class but it had no effect. And I tried adding it to the class of the division the inline block is in and within the image tag but neither of them worked either.

I'm going to post my XHTML code and associated CSS for my images. Maybe someone will see something I'm overlooking.

[MikeWV]

The following is an example of the code I'm using for my images. Maybe someone will see a reason why applying "font-family: sans-serif" to the parent element is having no effect.

<div class="txcenter">
<p class="imcenter">
<img src="../images/13f01_eff_front_graph.svg"
width="100%"
height="auto"
alt="Efficient Frontier Plot"
title="Efficient Frontier Plot" />
</p>
<p class="figurenum">Figure 13-1</p>
</div>

img {
display: block;
text-indent: 0;
margin-left: auto;
margin-right: auto;
margin-bottom: 0;
}
.txcenter {
text-align: center;
page-break-inside: avoid;
}

.imcenter {
text-align: center;
display:inline-block;
font-family: sans-serif; This has no effect.
}

Any place where font-family has been specified in the CSS it has been specified as normal. I did that so that readers can use their preferred fonts.

.txcenter is the class for the division that contains the inline block. Adding font-family to that class has no effect either.

[DaleDe]

Originally Posted by MikeWV

The following is an example of the code I'm using for my images. Maybe someone will see a reason why applying "font-family: sans-serif" to the parent element is having no effect.

<div class="txcenter">
<p class="imcenter">
<img src="../images/13f01_eff_front_graph.svg"
width="100%"
height="auto"
alt="Efficient Frontier Plot"
title="Efficient Frontier Plot" />
</p>
<p class="figurenum">Figure 13-1</p>
</div>

img {
display: block;
text-indent: 0;
margin-left: auto;
margin-right: auto;
margin-bottom: 0;
}
.txcenter {
text-align: center;
page-break-inside: avoid;
}

.imcenter {
text-align: center;
display:inline-block;
font-family: sans-serif; This has no effect.
}

Any place where font-family has been specified in the CSS it has been specified as normal. I did that so that readers can use their preferred fonts.

.txcenter is the class for the division that contains the inline block. Adding font-family to that class has no effect either.

Ah, I do not think inheritance works to another file. Try placing the SVG code inline in the html document instead of as a separate file. However putting the SVG statements inside the SVG itself should have worked. When it is a different document the rules are different.

Dale

[MikeWV]

Tex2002ans,

When I refreshed the page this morning, your post was above where I landed after punching F5 and I just now found your post. It will take me a while to digest all of that and see what you did in the attached file.

I appreciate the time and effort you've expended on this issue.

Mike

[JSWolf]

There is a serious bug with the SVG tables. If they are too long for the page, they run over to the next page and if they are still too long, you don't see all the rows.

The HTML table splits at whatever rows don't fit and moves them to the next page properly. My suggestion is to forget SVG and stick with HTML for tables.

[Tex2002ans]

Originally Posted by MikeWV

I appreciate the time and effort you've expended on this issue.

No problem. SVG has been an area I have been quite interested in, but haven't spent as much time as I would like.

It is definitely an area that isn't well documented/tested in the ebook field.

RbnJrg has definitely fiddled around with it much more than most of us on the boards.

[MikeWV]

Originally Posted by JSWolf

There is a serious bug with the SVG tables. If they are too long for the page, they run over to the next page and if they are still too long, you don't see all the rows.

That's not good but's it's good to know. I though the problem was either attributable to my coding or some idiosyncrasy of my Kobo.

[Tex2002ans]

Originally Posted by MikeWV

That's not good but's it's good to know. I though the problem was either attributable to my coding or some idiosyncrasy of my Kobo.

Well, if you open up the SVG, you can see the internal measurements of your large table is:

width="577.20001"
height="789.90002"

To my knowledge, if you just plop the SVG into your ebook, the device will render it at a 1:1 ratio (~577px x ~780px).

If your device does not have enough pixels for that width/height, the image can flow off the edges of the device (just like your typical too large image, that isn't resized via CSS).

I attached a new EPUB with the typical "Cover" SVG Wrapper that many use.

I wrapped it around the table + tweaked the width/height, so now it should resize to fill the entire width/height of the device, while maintaining a proper ratio. (Tested it on my Nook, it works perfect).

<svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 577 789" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink">
<image height="789" width="577" xlink:href="../Images/13t04_table4_r2v_mat_full.svg"></image>
</svg>

Again, I haven't done extensive testing, and from a quick feed into Kindle Previewer, it did not look like the Kindles liked the code. (Some of the text got mangled).

Side Note: A lot of this talk got me thinking about my SVG Tutorial I had laid the groundwork on... I looked in my notes, and I haven't touched it since February. I should get back on doing thorough research/testing/writing.

[JSWolf]

After viewing the new test ePub from tex2002ans, I issues with both SVG and HTMLbtables.

I made the size of my ADE window smaller.

The SVG table in the SVG wrapper did work as expected, but because it fit the entire table on screen at once, it was too small to read.

The HTML table was good to read until I increased the font size to be too large to fit width wise without going past the edge of the window. But if the font size was not too large, it displayed best because it was more readable and the rows that didn't fit dropped to the next page (and so on).

So in either case, there are issues. If it's a small enough and simple enough table, SVG could work. HTML could work as well.

The font size did not change with the SVG table in the SVG wrapper. I could change the font size with the HTML table.

Given that you don;t know the font size nor the screen size, the HTML table is a better option. Especially when reading on a cell phone screen such as an iPhone. As for a 6" eInk screen, I would say again, the HTML table is better. given how many rows are in the SVG table, it would come out smaller and harder for to read. The HTML table as long as the font size is not too large to go off the side of the screen, it's the winner.

[Tex2002ans]

Originally Posted by JSWolf

The SVG table in the SVG wrapper did work as expected, but because it fit the entire table on screen at once, it was too small to read.

Indeed, this goes back to my first post where I mentioned it is just physically "impossible" for a very large table to fit on a very small device. The text just becomes impossibly small to read.

And while you would HOPE that your readers would choose a more suitable device for non-fiction, technical works (tablets, PCs, etc. etc.), you can't guarantee that...

Potential pro for bitmap image: Now, depending on your device, SOME of them allow you to click on a JPG/GIF/PNG, and get a full-scale version of the image, which you can then scroll around. This might be a case where a large table might MIGHT beat out a comparable SVG. I do not believe these devices can allow you to do the same thing via SVG (expand + scroll).

Pro for SVG: On devices that do not have such capabilities, the legibility of the text in the SVG image would DESTROY the shrunken JPG/GIF/PNG (image resizing algorithms on typically do HORRENDOUSLY on text).

Originally Posted by JSWolf

The HTML table was good to read until I increased the font size to be too large to fit width wise without going past the edge of the window. But if the font size was not too large, it displayed best because it was more readable and the rows that didn't fit dropped to the next page (and so on).

Yep, that specific Split Table broke the ol' "4-column rule" (it was 5 columns). This is something where you have to logically break up the tables on a case-by-case basis depending on what data is inside, while still maintaining comprehension.

For that specific table, there was the "Weights" spanning 4 columns + the "Portfolio Number"... it would be QUITE odd having Portfolio Number + 3 of the 4 "Weight"s. And then the 2nd Table with "Portofolio Number" + 1 "Weight" + the rest of the data.

This again goes back to the pro/con balancing scale... Coming up with the best way to transfer a table to be readable on a smaller device.... sometimes it is just not possible to logically split the data while maintaining comprehension.

Side Note: And here we come back to the balancing scale. Most just settle on making a bitmap image of the table, and screw the disadvantages, it works "good enough" It takes about two seconds to generate an image (and IS compatible with nearly every device).... but it takes a lot more hard work trying to make books more accessible/user/reader friendly!

Originally Posted by JSWolf

The font size did not change with the SVG table in the SVG wrapper. I could change the font size with the HTML table.

Also, you have to keep in mind the other advantages of the HTML table. For example, I would say THIS:



is better than this:



(Notice the SVG text is specified as black... Black on black, no good!).

and here is a screenshot of the 96dpi image of the table:



This is an example of the disadvantage of going the image route... while it looks fine on white background + black text, it begins to fall apart when the user decides to use anything else as their background colors.

And sure, sure, the HTML table I made isn't as pretty... but it follows user preferences. The HTML table can change font size/color, and scale to quite a large font size on the same size screen (comparable to the image/SVG).

Also, your book will become much more accessible to a person with poor eyesight (this is one of the FANTASTIC advantages of ebooks compared to their (crappy) physical counterparts!).

Originally Posted by JSWolf

Given that you don;t know the font size nor the screen size, the HTML table is a better option. Especially when reading on a cell phone screen such as an iPhone. As for a 6" eInk screen, I would say again, the HTML table is better. given how many rows are in the SVG table, it would come out smaller and harder for to read. The HTML table as long as the font size is not too large to go off the side of the screen, it's the winner.

You could also do something like split your really large tables into smaller SVG files. Maybe 15/20 rows each. This would allow the entire SVG to expand slightly larger, potentially giving slightly bigger text.

[JSWolf]

I'd still stick with the HTML. Try it on an iPhone with Bluefire and if it works well enough, go for it. But don't forget to try larger font sizes until it breaks to see if you can go large enough. I mean one thing the reader can do is when the reader gets to the table, reduce the font size for the table. Then increase again for the rest of the book.