MobileRead Forums - View Single Post - How to Control Fonts in SVG Images of Charts and Tables?

MikeWV · 06-16-2014, 12:40 PM

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.

06-16-2014, 12:40 PM	#32
MikeWV Connoisseur Posts: 54 Karma: 10 Join Date: Nov 2013 Device: Kobo Touch	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.