Which Kobo Embedded Font Do You Use Most Often?

[dmapr]

Originally Posted by jackie_w

I don't know of anyone else who has reported trying to replace an existing Kobo built-in font with a sideloaded font of the same name. I deliberately only sideloaded fonts without a built-in equivalent already present.

Regarding Gill Sans, I wonder if it's a coincidence that the only one of your test fonts which DID work is the one whose built-in equivalent DOESN'T currently work properly (bold instead of italics problem)? The other built-in fonts which are currently known to be problematic are Kobo Nickel and Avenir Next.

As an aside, I've also occasionally wondered whether it's a coincidence that the 3 problematic built-in fonts are the ones containing a space in their name?

Good questions -- I was wondering about those, too. With respect to the name, the Gill Sans has a space in the name, but not in the filename. I tried both with and without space, but it was still picking up the sideloaded font. For what it's worth, I do not have the bold instead of italics problem with the sideloaded Gill Sans (with the space in the name, haven't tried without) . Also, the Avenir Next filenames in the Kobo are just Avenir (not Avenir Next) and the Kobo Nickel filenames are missing spaces.

P.S. I deliberately tried to sideload the fonts with the same name to get full range of characters & the advanced font options without resorting to renaming the fonts.

[dmapr]

Update: I have completely removed the Amasis, Caecilia and Malabar from the Kobo f/w. I also renamed Avenir to Avenir Next and KoboNickel to Kobo Nickel, then applied the update.

The Cyrillic characters still don't show in those three fonts which leads me to believe there may be some other issue in play. The bold vs. italics problem went away for Avenir Next and Kobo Nickel fonts.

[dmapr]

OK, finally got it to work. I don't know what makes Gill Sans good enough to be picked up from the /fonts directory, but Amasis, Caecilia & Malabar were apparently still on the device even after I removed them from the upgrade file, being preferred to sideloaded versions. So, I added

rm -rf /usr/local/Trolltech/QtEmbedded-4.6.2-arm/lib/fonts/Amasis*.ttf
rm -rf /usr/local/Trolltech/QtEmbedded-4.6.2-arm/lib/fonts/Caecilia*.ttf
rm -rf /usr/local/Trolltech/QtEmbedded-4.6.2-arm/lib/fonts/Malabar*.ttf

to the end of /etc/init.d/rcS and voila! Both advanced settings and Cyrillic letters are working. Happy camper

[jackie_w]

@dmapr,

Just to backtrack a little... Am I understanding this right? Are you saying that the only reason that the standard built-in fonts Gill Sans, Avenir, Kobo Nickel are currently problematic with italic/bold is because those font files have incorrect filenames deep within the zipped up fw upgrade files? And this is the problem that the Kobo Developers have so far refused to fix because 'everything's OK in kepubs'.

If I've understood you correctly, I'm utterly gob-smacked This surely would be a <30sec fix for whoever is creating the fw zip files? Personally, I never use those 3 fonts but it must be affecting a lot of users.

Update: Well I've answered my own question, I couldn't resist testing it myself. I have a Glo which was still on fw 2.6.1a, so I took a copy of the Glo 2.6.1b zip file and renamed the font filenames inside KoboRoot.tar (inside KoboRoot.tgz) using 7-zip

4 x Avenir*.ttf to Avenir Next*.ttf
4 x GillSans*.ttf to Gill Sans*.ttf
4 x KoboNickel*.ttf to Kobo Nickel*.ttf

Then I sideloaded fw 2.6.1b in the normal way. The 3 problematic fonts do indeed seem 'cured'... and it was painless.

Thanks, dmapr

[dmapr]

@jackie_w,

Yes, it's amazing they're refusing to fix something as trivial as this. Your modification is exactly the same as what I did.

[meeera]

Originally Posted by dmapr

@jackie_w,

Yes, it's amazing they're refusing to fix something as trivial as this. Your modification is exactly the same as what I did.

Wow, such a quick fix, too!

Maybe it could be useful to share the fixed zipped upgrade files, either here or in the firmware-for-sideloading thread?

[PeterT]

I think refuse is way to strong a term.

[dmapr]

Originally Posted by meeera

Wow, such a quick fix, too!

Maybe it could be useful to share the fixed zipped upgrade files, either here or in the firmware-for-sideloading thread?

I'm not sure what the legal status of such modification is, so I don't know if it is possible to do so.

[dmapr]

Originally Posted by PeterT

I think refuse is way to strong a term.

Ok, how about ignoring such a simple fix?

[PeterT]

Trust me when I say a fix is forthcoming,

[davidfor]

Originally Posted by dmapr

Ok, how about ignoring such a simple fix?

It is likely that there is something else going on that prevents them using this fix. A possible reason is a license that means they can't rename the files. Or some other code that is relying on the current file names.

And as PeterT said, a fix IS coming. And it wasn't a file name change.

[dmapr]

Originally Posted by davidfor

It is likely that there is something else going on that prevents them using this fix. A possible reason is a license that means they can't rename the files. Or some other code that is relying on the current file names.

And as PeterT said, a fix IS coming. And it wasn't a file name change.

I'm all for it. The less I have to mess with firmware, the better

[sos_sifou]

Malabar for me :-)

[ewphoenix123]

Originally Posted by dmapr

Ok, how about ignoring such a simple fix?

I spent the last days wading through the last patches with an hex editor and am slightly optimistic that we will see more fixes in the future, and hopefully a somewhat a more systematic approach.

A lot of old legacy code was removed from 2.5.1->2.6.1, like f.e. broken plugins for the adobe reader app, and many internal modules were updated.

The size of the reader and nickel module alone shrunk by 20%, that's a lot of old apparently unused code gone.

[jackie_w]

Originally Posted by meeera

Wow, such a quick fix, too!

Maybe it could be useful to share the fixed zipped upgrade files, either here or in the firmware-for-sideloading thread?

Since we are assured the official fix is well on the way, probably not a good idea. After all, we've no idea whether the DIY fix may cause unforeseen problems down the line. I'm prepared to live with the risk on 1 of my 2 Kobos, but now, with the benefit of hindsight, I'm not sure I'd recommend others do it.

I still think that letting this problem fester for several fw revisions (all since 2.1.5 ???) was a bad management decision. Losing 3 of the advertised TypeGenius-aware built-in fonts is a big percentage. Especially for those preferring to read in sans-serif, who lost both of the only 2 available.