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

[mrmikel]

People keep bringing up accessibility as an issue with epubs and these %^&&*( tables in particular. Does anyone have any figures on whether this is a real issue or just an academic hobby horse?

If there are significant numbers of people with limited vision I am willing to spend some time on it.

[MikeWV]

Well, the rest of you have streaked out ahead of me while I was working with some of your original suggestions. Here's what I accomplished yesterday (Sunday).

I figured out what as suppressing the font family specified in the SVGs. When I imported PDFs into Inkscape, I had the "Replace PDF fonts by closest-installed font" option checked. When I tried importing with that option unchedcked, the SVGs displayed as expected, i.e., the specified font family was used rather than being overridden by the reader's default font. This doesn't make any sense, but it works. I crossed checked the first part of the XML code for images produced with and without that option checked and found no differences in the files. There's surely some difference somewhere, but the files are too large to effectively cross-check manually.

I used Tex2002ans's suggested procedure to change the table/chart font-family with the generic sans-serif. Before doing so, I changed the font in the tables and charts to Arial. Arial apparently has approximately the same proportions as the generic sans-serif, as the the spacing of the characters was good in most font sizes without doing anything with the X coordinates. I'm hesitant to change the set of character X coordinates to "X=0" as I'm afraid that although it appears to work well, it may cause the characters to stack up at X=0 on some devices. Also, although the coordinates also start at X=0 in charts, it seems like the probability of unexpected results would be greater than with tables. I looked for a way to add the generic sans-serf font to Excel but was unsuccessful. If I could do that, then I wouldn't have to worry about the character spacing.

I'll give the HTML tables some more consideration, but I'm definitely not keen on going that route. That would be a lot of work that I hadn't planned on doing and I really don't see it as an elegant solution. Plus I'd be breaking the four-column rule with about 85% of my tables. I know that font size is a concern but I'm just not going to try to accommodate anything smaller than a basic e-reader like my Kobo Touch or a Nook. Using SVGs with height=100% and width=auto, my largest table fits perfectly on the screen of my Kobo and the characters are clear and crisp even though they are downright tiny. Being that I only have two really large tables, I may just go with that. I can always post a set of images on a Website for people with poor eyesight to access with a tablet, laptop or desktop PC. Of course, they can accomplish the same thing by copying the ePub to one of those devices to view any highly compressed images and use their e-reader to read the rest of the book. I might suggest that in the preface or introduction.

All of this has me thinking about my cover images, which are PNGs in SVG wrappers. They look OK but it seems like they would look much better if they were pure SVG.

There's obviously a lot to learn about SVG; it definitely is not just another image format.

[MikeWV]

MrMikel,

I haven't done any research on accessibility for those with poor eyesight but I suspect it's probably not as big a concern now as it was a few years ago, as there are now more options for digital reading. When e-readers first hit the market, I'm sure there were a significant number of people with poor eyesight who bought e-readers to read novels and maybe some basic non-fiction. However, with a good selection of tablets now available, I would think that many of those people would have moved up to tablets to take advantage of the larger screens, on which they could see a lot more large text at one time.

Some people just aren't going to be able to read my largest tables on an e-reader. But according to recent polls, the trend in e-reading is toward tablets and I'm hoping that a substantial portion of my audience will be reading my books on tablets. Also, this particular book is 98 type-written pages with two large tables, one of which is in an appendix and very likely will not be used much. The other 33 tables range from small to medium-large and I don't see most of them being a problem for most people to read.

My main concern with all of my tables and charts is that they look good. And with what I've accomplished with a lot of help over the past few days, I now know how to make them now look good. That someone might not be able to read this one very large table is not a big concern, as the important numbers in that table are stated and their derivation described in the accompanying text.

[mrmikel]

For the ultra wide table, it might be possible to break it into a series of 3 smaller ones, each summarizing the other. Unless the readers are all experts in the subject presented, it might actually be clearer. Some of my non-fiction military works have a number of tables, but the exact number of tanks, for example, at any location is not of interest to anyone except an expert. It might be more important that there were none at one location and many many at another.

But in an academic setting with someone looking to trip you up, you may have no choice.

[MikeWV]

As I've been working may way through redoing my images in SVG, I've found a few lines of bolded sans serif in which the characters were scrunched together. It seems like the spacing should either always be good or always need adjusting, but that's not what I'm seeing.

To get the scrunched up text to display properly, I've changed the X coordinates of those lines to "X=0". I'm still uncomfortable with that but I suspect that the beginning coordinate of each character is simply information that Inkscape generates and includes in the file either so it's there for Inkscape to use at a later date if it needs it or because it was easier to include it in the file than to write the code to eliminate it. If either of those possibilities is correct, then it should be safe to eliminate all but "X=0".

[RbnJrg]

Originally Posted by MikeWV

...All of this has me thinking about my cover images, which are PNGs in SVG wrappers. They look OK but it seems like they would look much better if they were pure SVG.

Covers based on SVG only would work for ebooks that use .xhtml covers. Of that way, you never could use a SVG cover for Kindle. Take in count that. And a halfway complex svg file is quite heavy, watch the epub I attach with a pure svg file (created with Inkscape) of a leopard.

[MikeWV]

You hit the nail on the head, RbnJrg. My covers are .xhtml. I knew I was going to have to do something different for Kindle but have yet to investigate that. I'll deal with the Kindle issues after I have ePubs that are acceptable to the other vendors.

[mrmikel]

If you use html tables, I think lines which are <th> will be automatically bolded and take up more space unless you change them in the stylesheet. This can be a space consumer, which is nice in a small table, but a PITN in a wide one.