Instructions for patching firmware 3.18.0 - Page 5

JSWolf · 10-17-2015, 08:35 AM

Quote:

Originally Posted by NiLuJe

You can also 'fix' the broken Gentium byte code hinting by using ttfautohint, which will rebuild them using FT's autohinter

.

I have used ttautohint and on my H2O, I see no problem with hinted fonts.

NiLuJe · 10-17-2015, 09:23 AM

Yep, the issue with Gentium (and a few other 'old' fonts) is that their truetype bytecode was optimized for some old and forgotten rendering engines, and freetype's bytecode interpreter just plain mangles it.
On a proper Linux system, you can simply workaround that by enforcing autohinting on these specific families via fontconfig.

But ttfautohint provides a 'cross-platform' answer, by rebuilding the bytecode hinting with the help of freetype's autohinter

.

JSWolf · 10-17-2015, 10:38 AM

Quote:

Originally Posted by NiLuJe

Yep, the issue with Gentium (and a few other 'old' fonts) is that their truetype bytecode was optimized for some old and forgotten rendering engines, and freetype's bytecode interpreter just plain mangles it.
On a proper Linux system, you can simply workaround that by enforcing autohinting on these specific families via fontconfig.

But ttfautohint provides a 'corss-platform' answer, by rebuilding the bytecode hinting with the help of freetype's autohinter

.

Now that makes a lot of sense. It's not proper hinting that's a problem, it's poor hinting that's a problem. Well done with this explanation. Now I know why my results are not what some others have been seeing.

NiLuJe · 10-17-2015, 10:56 AM

FWIW, you also have a number of systems that will *never* honor bytecode hinting, AFAIK: Android and anything Apple, be it iOS or OS X, for instance

.

JSWolf · 10-17-2015, 11:04 AM

Quote:

Originally Posted by NiLuJe

FWIW, you also have a number of systems that will *never* honor bytecode hinting, AFAIK: Android and anything Apple, be it iOS or OS X, for instance

.

I can say that ttfautohint's hinting works on iOS, Sony Readers, Kobo Readers, and nook Readers.

mietek81 · 10-17-2015, 02:56 PM

Quote:

Originally Posted by GeoffR

I'm not sure what you mean, but whatever font you select from the font menu on your device will be used for the font-family style on <body> (or <body> and <p>for alternative 2.) It doesn't matter what the name of the font is.

Edit: I have a feeling I might have misunderstood what you wanted when I said this patch would do what you want. There isn't any way to select more than one font from the device, the user can just select one font and all the others have to be specified in the book. This patch just prevents the user-selected font from overriding all the fonts specified in the book, making the KePub reader behave more like the ePub reader.

No, I wasn't precise enough. What I meant was that I have in ebook something like this:
pre {font-family: DejaVuSansMono;}
and nothing about styling of body or p.
So the first part of your post, before editing, answers my question - I can use specific font name (for everything that I don't want to be in user selected font) and not just font family name.

To say it simple - everything in ebook that is not <p> or <body> and has its font-family defined, will be using this defined font-family, whether it is font family (e.g serif) or specific font (e.g DejaVuSansMono).

Tomorrow I will test it after firmware update.

DNSB · 10-18-2015, 12:30 AM

Quote:

Originally Posted by Nick_1964

publishers want to let it be hard coded..it is almost impossible to make a patch for this because they don't use a standard,they just try their own rules to do it and i think 90% of them doesn't even try how it looks on a e-reader...

Which ereader? I've seen the same ebook look rather different on different ereaders. Not to mention the various tablets with different reading software (compare iBooks/PlayBooks to the Kobo, Kindle or whatever reading app you favour on iOS/Android) and be prepared to enjoy the various different renderings of the same ebook (possibly a bit unfair to include the Kindle app since epub is not a native format).

I will admit holding the opinion that many ebooks are created by high school students doing work experience -- preferably high school students who have managed to avoid any knowledge of typography or book and ebook design. After all, it's obvious that if a paragraph can indented or have a full lines worth of blank space separating it from another paragraph, it's an even better idea to use both. It is a good idea to add blank lines at the end of a chapter to make it look like a dead tree book totally disregarding the point that on any device without the same window size as the ebook was created on, you're very like to see blank pages (without even the "This page intentionally left blank" declaration). That ebooks should use absolute sizing for images so on a high-res device we get the thumbnail sized images that we all love seeing. When embedding fonts, you should choose the fugliest fonts you can find.

Nick_1964 · 10-18-2015, 06:04 AM

Quote:

Originally Posted by DNSB

Which ereader? I've seen the same ebook look rather different on different ereaders. Not to mention the various tablets with different reading software (compare iBooks/PlayBooks to the Kobo, Kindle or whatever reading app you favour on iOS/Android) and be prepared to enjoy the various different renderings of the same ebook (possibly a bit unfair to include the Kindle app since epub is not a native format).

I will admit holding the opinion that many ebooks are created by high school students doing work experience -- preferably high school students who have managed to avoid any knowledge of typography or book and ebook design. After all, it's obvious that if a paragraph can indented or have a full lines worth of blank space separating it from another paragraph, it's an even better idea to use both. It is a good idea to add blank lines at the end of a chapter to make it look like a dead tree book totally disregarding the point that on any device without the same window size as the ebook was created on, you're very like to see blank pages (without even the "This page intentionally left blank" declaration). That ebooks should use absolute sizing for images so on a high-res device we get the thumbnail sized images that we all love seeing. When embedding fonts, you should choose the fugliest fonts you can find.

Totally agree.. (maybe they can make e-readers with a small capsule of old book smell..) and they fill them with high res multi million color pictures.. for sure there are tablets who can display them,but the majority of the e-readers can't.. ( I know only very expensive readers who have color.., like the ECTACO jetBook Color 2 ) Kobo declared that they don't brink a color e-reader on the market.

StillReading · 10-19-2015, 02:01 PM

Well, there are currently no colour-ePaper-displays AFAIK, so every eBook reader with a colour display will be (more or less) a tablet, and will have to fight for market shares with a myriad of other tablets. There's 0 chance for a company like Kobo to make money in a market dominated by Microsoft, Apple, Google, etc. .

eBook layout/design: I'm glad I'n not the ony one who thinks that eBooks are created by people neither very good a typography/layout nor HTML/CSS coding (or monkeys with computer keyboards, not sure which) (; . I've also started editing my eBooks, which is probably the only way of making them display as nicely as possible. It's a lot of work, but worth it. There's so many ways if implementing stuff in HTML/CSS that there probably never will be an easy solution for "polishing" badly designed eBooks.

thatworkshop · 10-22-2015, 08:35 PM

Quote:

Originally Posted by NiLuJe

@freekobo: That's a decent possibility, the Aura is the only Kobo device using some kind of variation on the "regal" waveform tech, so it does handle eink updates in a different way.

Don't/can't other Kobos benefit from regal? I already saw this thread.

NiLuJe · 10-23-2015, 12:43 PM

@idoit: The ones using Carta screens (H2O, Glo HD) definitely *should*, but for baffling reasons, Kobo (I assume) chose not to. The waveforms are not tailored for it, and the eInk driver might not be up to the job either as-is...

Was a huge disappointment when I got my H2O, to tell you the truth. That this is *still* the case on the Glo HD even more so.

thatworkshop · 10-23-2015, 12:47 PM

Quote:

Originally Posted by NiLuJe

@idoit: The ones using Carta screens (H2O, Glo HD) definitely *should*, but for baffling reasons, Kobo (I assume) chose not to. The waveforms are not tailored for it, and the eInk driver might not be up to the job either as-is...

Was a huge disappointment when I got my H2O, to tell you the truth. That this is *still* the case on the Glo HD even more so.

Oh, so I guess I (owning Mini) have to sit quietly in the corner!

Mini uses Vizplex or Pearl?! I guess former, but there are posts referring to latter!

boriar · 10-23-2015, 01:05 PM

Sorry for the offtopic, but what is the "regal" waveform tech?, and why it's a shame that H2O don't have it?

NiLuJe · 10-23-2015, 01:43 PM

In short, a bit of trickery making non-flash refreshes much more efficient (i.e., faster and with much, much, much less ghosting, while still being as accurate as a proper refresh).

GeoffR · 10-26-2015, 02:01 AM

When fullScreenReading=true the following is added to the built-in KePub stylesheet:

Code:

img {
  display: block;
  margin-left: auto !important;
  margin-right: auto !important;
  width: auto !important;
  height: auto !important;
}

This has the bad effect of making images display centred on a seperate line when they should be displayed inline with the text of a paragraph.

The screenshots below show a book where the publisher has included an image of some hebrew letters (instead of doing a proper job and embedding a font containing glyphs for the letters) in the following way:

Code:

<p class="indent">It was quite by accident that Brother Francis finally 
discovered the pilgrim’s stone. While wandering thereabouts, he stumbled over the 
stake which the old man had driven into the ground as a marker. He found himself 
on his hands and knees staring at a pair of marks freshly chalked on an ancient 
stone: <img alt="image" height="15" src="images/Art_P11.jpg" width="18"/></p>

1. Unpatched, KePub, fullScreenReading=true
2. Patched, KePub, fullScreenReading=true

Click image for larger version

Name: fsbug3-unpatched.png
Views: 433
Size: 90.2 KB
ID: 143170

Click image for larger version

Name: fsbug3-patched.png
Views: 406
Size: 90.1 KB
ID: 143171

This patch disables that added style by replacing img --> _mg, so that images are displayed the same way in KePub full-screen mode as they are in KePub normal reading mode (and ePubs in both modes).

Multi-version patch, paste into libnickel.so.1.0.0.patch:

Spoiler:

10-17-2015, 09:23 AM	#62
NiLuJe BLAM! Posts: 13,485 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	Yep, the issue with Gentium (and a few other 'old' fonts) is that their truetype bytecode was optimized for some old and forgotten rendering engines, and freetype's bytecode interpreter just plain mangles it. On a proper Linux system, you can simply workaround that by enforcing autohinting on these specific families via fontconfig. But ttfautohint provides a 'cross-platform' answer, by rebuilding the bytecode hinting with the help of freetype's autohinter . Last edited by NiLuJe; 10-17-2015 at 10:55 AM.

10-26-2015, 02:01 AM	#75
GeoffR Wizard Posts: 3,821 Karma: 19162882 Join Date: Nov 2012 Location: Te Riu-a-Māui Device: Kobo Glo	When fullScreenReading=true the following is added to the built-in KePub stylesheet: Code: img { display: block; margin-left: auto !important; margin-right: auto !important; width: auto !important; height: auto !important; } This has the bad effect of making images display centred on a seperate line when they should be displayed inline with the text of a paragraph. The screenshots below show a book where the publisher has included an image of some hebrew letters (instead of doing a proper job and embedding a font containing glyphs for the letters) in the following way: Code: <p class="indent">It was quite by accident that Brother Francis finally discovered the pilgrim’s stone. While wandering thereabouts, he stumbled over the stake which the old man had driven into the ground as a marker. He found himself on his hands and knees staring at a pair of marks freshly chalked on an ancient stone: <img alt="image" height="15" src="images/Art_P11.jpg" width="18"/></p> 1. Unpatched, KePub, fullScreenReading=true 2. Patched, KePub, fullScreenReading=true This patch disables that added style by replacing img --> _mg, so that images are displayed the same way in KePub full-screen mode as they are in KePub normal reading mode (and ePubs in both modes). Multi-version patch, paste into libnickel.so.1.0.0.patch: Spoiler: Code: <Patch> patch_name = `Disable KePub FullSceenReading block img style` patch_enable = `yes` # Multi-version patch: 3.3.0 - 3.18.0+ find_base_address = `\0i\0m\0g\0 \0{\0 \0d\0i\0s\0p\0l\0a\0y\0:\0 \0b\0l\0o\0c\0k\0;\0` replace_string = 0001, `i`, `_` </Patch> Last edited by GeoffR; 10-26-2015 at 02:25 AM. Reason: ... some hebrew letters ...

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Instructions for patching firmware 3.15.0	GeoffR	Kobo Developer's Corner	146	05-24-2016 06:10 AM
Instructions for patching firmware 3.17.3	GeoffR	Kobo Developer's Corner	60	09-17-2015 05:35 PM
Instructions for patching firmware 3.17.0	GeoffR	Kobo Developer's Corner	49	08-16-2015 05:20 AM
Instructions for patching firmware 3.16.10	GeoffR	Kobo Developer's Corner	12	08-14-2015 03:40 AM
Instructions for patching firmware 3.3.x, 3.4.x, 3.5.x	GeoffR	Kobo Developer's Corner	285	08-27-2014 10:06 AM

10-17-2015, 10:56 AM	#64
NiLuJe BLAM! Posts: 13,485 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	FWIW, you also have a number of systems that will never honor bytecode hinting, AFAIK: Android and anything Apple, be it iOS or OS X, for instance .

10-19-2015, 02:01 PM	#69
StillReading Enthusiast Posts: 30 Karma: 10 Join Date: Sep 2014 Device: none	Well, there are currently no colour-ePaper-displays AFAIK, so every eBook reader with a colour display will be (more or less) a tablet, and will have to fight for market shares with a myriad of other tablets. There's 0 chance for a company like Kobo to make money in a market dominated by Microsoft, Apple, Google, etc. . eBook layout/design: I'm glad I'n not the ony one who thinks that eBooks are created by people neither very good a typography/layout nor HTML/CSS coding (or monkeys with computer keyboards, not sure which) (; . I've also started editing my eBooks, which is probably the only way of making them display as nicely as possible. It's a lot of work, but worth it. There's so many ways if implementing stuff in HTML/CSS that there probably never will be an easy solution for "polishing" badly designed eBooks.

10-23-2015, 12:43 PM	#71
NiLuJe BLAM! Posts: 13,485 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	@idoit: The ones using Carta screens (H2O, Glo HD) definitely should, but for baffling reasons, Kobo (I assume) chose not to. The waveforms are not tailored for it, and the eInk driver might not be up to the job either as-is... Was a huge disappointment when I got my H2O, to tell you the truth. That this is still the case on the Glo HD even more so.

10-23-2015, 01:05 PM	#73
boriar Evangelist Posts: 407 Karma: 314204 Join Date: Jan 2015 Device: bq Avant XL, Kobo Aura H2O, Onyx Boox M96C Plus	Sorry for the offtopic, but what is the "regal" waveform tech?, and why it's a shame that H2O don't have it?

10-23-2015, 01:43 PM	#74
NiLuJe BLAM! Posts: 13,485 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	In short, a bit of trickery making non-flash refreshes much more efficient (i.e., faster and with much, much, much less ghosting, while still being as accurate as a proper refresh).