Summary of Modified Fonts

[anacreon]

Originally Posted by GeoffR

Caudex has been updated to version 1.06. This version includes fixes to the PANOSE profile and TTF names that prevented the previous version 1.05 from working properly with the KePub reader.

Thank you for the info. I gather that the maintainer applied your corrections, but did he correct the high hyphen thing? If not, I'll keep your "Caudey" adjusted version.

[chrisridd]

Originally Posted by GeoffR

Caudex has been updated to version 1.06. This version includes fixes to the PANOSE profile and TTF names that prevented the previous version 1.05 from working properly with the KePub reader.

Thanks!

[GeoffR]

Originally Posted by anacreon

Thank you for the info. I gather that the maintainer applied your corrections, but did he correct the high hyphen thing? If not, I'll keep your "Caudey" adjusted version.

Caudex 1.06 has the corrections for the problems that made the KePub reader select the wrong font styles, and also a minor adjustment to the kerning that made the space too small after a word ending with a single right quote (most noticable in books with British-style punctuation.)

But the high hyphen isn't really a fault with the font, so it wasn't changed. I've edited my post #346 to add an alternative version based on Caudex 1.06 but with the hyphen-minus replaced by a hyphen.

The real problem is that the hyhen-minus is a character that is supposed to be usable as both a hyphen and a minus sign, but in practice the height of these two characters are not always compatible (minus should match plus, while hyphen should match en-dash, em-dash, etc.) so I think the font just has to choose between making the minus sign too low or the hyphen too high. The real solution would be for publishers to avoid using hyphen-minus as a hyphen, but I doubt that will ever happen.

From my own point of view it is better to make hyphen-minus to be a hyphen, because the books I read have thousands of hyhens (when including automatic hyphens added to break lines) and often no minus signs at all.

One new thing I discovered is that the automatic hyphens added by the KePub reader are hyphen, while the ones added by the ePub reader are hyphen-minus. That means that in a font like this where the hyphen-minus is a minus sign, the automatic hyphens in KePub will look different to the hard hyphens used by the publisher, but in the ePub reader they will look the same. With the alt-hyphen font they will look the same in both KePub and ePub.

[chrisridd]

Originally Posted by GeoffR

One new thing I discovered is that the automatic hyphens added by the KePub reader are hyphen, while the ones added by the ePub reader are hyphen-minus. That means that in a font like this where the hyphen-minus is a minus sign, the automatic hyphens in KePub will look different to the hard hyphens used by the publisher, but in the ePub reader they will look the same. With the alt-hyphen font they will look the same in both KePub and ePub.

Interesting, so it sounds like in theory the ACCESS (kepub) engine is more typographically correct than the RMSDK (epub) engine?

OpenType fonts can support "alternate" characters within the font - for example numerals might come in monospaced and proportional versions - and I wonder if that's a good way to include your adjusted hyphen? Adobe documents how to access these alternates in some CSS engines at https://helpx.adobe.com/typekit/usin...ntax.html#salt but whether these work in ACCESS/RMSDK is another question.

[GeoffR]

Caudex has been updated to version 1.07. This version has a new hyphen-minus glyph that sits at the same height as a hyphen but with spacing like a minus sign. This seems like a good compromise.

[anacreon]

I've just started to read Denise Bosler's "Mastering Type", which I of course set to Default font, and I liked it. I saw from the files that it is Charis SIL, which I abandoned some time ago because when I selected it, it generated wide line spacing.

I compared my ttf files to those in Bosler's book, and they have the exact same weight in ko (much bigger than all the other fonts I have), so I assume they are identical.

Why do they act differently? Is there some (simple) way to correct that behavior for all books? I read only kepubs, F/W 3.15.0.

[GERGE]

Could you send the font files? I will check the differences.

[anacreon]

Here are the files.
Thank you, anacreon

[GERGE]

The files are same. Completely same. Your must have fixed line spacings in the CSS.

[anacreon]

Originally Posted by GERGE

The files are same. Completely same. Your must have fixed line spacings in the CSS.

Thank you for confirming the files are identical. As for the CSS, I have line height at 1.2, but that is for ALL books, and it is only with Charis SIL that there is the wide line spacing. I had eliminated it from my lists, on both Aura H2O and Glo HD, but I was surprised that the native Charis SIL on Bosler's "Mastering Type" didn't have the same effect.

[GERGE]

http://scripts.sil.org/ttw/fonts2go.cgi

You can download Charis with custom line spacing from here.

[anacreon]

Originally Posted by GERGE

http://scripts.sil.org/ttw/fonts2go.cgi

You can download Charis with custom line spacing from here.

Perfect! Now in the book produced with Charis SIL, the thin line spacing produces the same result as the original, BUT I can thicken/thin the font itself thanks to Geoff's tweak, AND I can use Charis in any book.

Thank you very much.

[chrisridd]

I was trying out Bookerly and Ember on my Kobo yesterday* and encountered the known issues with the PANOSE weights and letterforms being "wrong" and confusing the ACCESS engine.

I ended up just deleting the entire PANOSE settings using fontforge - which made ACCESS happy - but wondered if anyone has worked out what the ACCESS engine is actually looking for in these fields? The values in the fonts did look reasonable although I'm not a typographer.

(* copyright Amazon, I'm not sharing them or information about where to get them from.)

[sherman]

To be honest, while I'm no expert, I'm leaning towards the conclusion that Qt is the main issue with font problems. Qt + non-system fonts = pain.

Some here may remember last year I created a script to modify font files for our Kobos. Over the summer, I worked at slapping a GUI on top, and after a while after playing with wxPython and Tkinter, I settled on learning the basics of PyQt.

Well, I have a mostly working GUI, however there is one problem...

I wanted to be able to offer a preview of what the font changes look like, however I still have not managed to get it working. To put it simply, Qt font handling is downright weird, especially once you start adding the various styles for one font.

I bring this up, because I'm pretty sure that Nickel uses Qt (please correct me if I'm wrong!), and I would in no way be surprised if ACCESS also uses Qt (on the Kobo at least - I assume the underlying engine is not tied to any specific UI toolkit)

[chrisridd]

Originally Posted by sherman

I bring this up, because I'm pretty sure that Nickel uses Qt (please correct me if I'm wrong!), and I would in no way be surprised if ACCESS also uses Qt (on the Kobo at least - I assume the underlying engine is not tied to any specific UI toolkit)

libnickel.so.1.0.0 depends on a lot of libQt5:

• libssl.so.1.0.0
• libcrypto.so.1.0.0
• libQtSolutions_IOCompressor-2.3.so.1
• libzip.so.1
• libxml2.so.2
• libxslt.so.1
• liblz4.so.1
• librmsdk.so.1
• libQt5WebKitWidgets.so.5
• libQt5MultimediaWidgets.so.5
• libQt5Svg.so.5
• libQt5PrintSupport.so.5
• libQt5Multimedia.so.5
• libQt5WebKit.so.5
• libQt5Widgets.so.5
• libQt5Concurrent.so.5
• libQt5Sensors.so.5
• libQt5Xml.so.5
• libQt5Sql.so.5
• libQt5DBus.so.5
• libQt5Script.so.5
• libQt5Network.so.5
• libQt5Gui.so.5
• libQt5Core.so.5
• libpng16.so.16
• libjpeg.so.62
• libicuuc.so.46
• libicudata.so.46
• libicui18n.so.46
• libdbus-1.so.3
• libdl.so.2
• librt.so.1
• libz.so.1
• libpthread.so.0
• libstdc++.so.6
• libm.so.6
• libgcc_s.so.1
• libc.so.6
• ld-linux-armhf.so.3

Nothing else font-ish stands out - except librmsdk? - so I think your assumption is good.