Glo Rosarivo font is not display properly.

[PeterT]

epub extension uses the Adobe RMSDK based renderer. kepub.epub uses the ACCESS based renderer.

Sent from my Nexus 7 using Tapatalk

[JSWolf]

Check the font in a font editor to see if something is wrong with the j.

[hwanjongyu]

I don't know what was problem.
But GeoffR sent modified font and it worked for me.
Thank you, GeoffR.

[GeoffR]

Originally Posted by hwanjongyu

I don't know what was problem.
But GeoffR sent modified font and it worked for me.
Thank you, GeoffR.

I don't know what the problem was either, but I suspect there was something wrong with the way the j glyph was drawn in the original font. I don't know enough about manipulating glyphs in fontforge to say exactly what it was though.

I made these changes:

* Changed name of ligature tables from 'lig' to 'liga'.
* Increased weight of Regular/Italic by 4 em units.
* Created Bold/BoldItalic versions with weight increased by 50 em units.
* Changed PANOSE weights to book/bold.
* Added 'old-style' kern tables.

I think the slight change in weight, which causes the glyphs to be re-drawn, was probably what fixed the problem with the 'j'.

I just need to change the name of the font to be able to distribute it under the OFL licence, so if anyone wants me to post it here, just think of a new name.

[PeterT]

Josarivo in honour of the J?

[GeoffR]

I changed the name from Rosarivo to Rojarivo, Rosa (pink) to Roja (red) as the new font is slightly heavier, and appears to fix the problem with the 'j'.

It is a nice font and it is a shame to mess with it, maybe someone more knowledgable could take a look at the 'j' glyph in the original font and fix it without changing the weight. Also the bold versions I just created by using the default fontforge parameters, someone else might be able to do a better job.

I made these changes:

* Changed name of ligature tables from 'lig' to 'liga'.
* Increased weight of Regular/Italic by 4 em units.
* Created Bold/BoldItalic versions with weight increased by 50 em units.
* Changed PANOSE weights to book/bold.
* Added 'old-style' kern tables.
* Changed font name from Rosarivo to Rojarivo.

Edit: I've attached an alternative with the Bold/BoldItalic versions created by increasing the weight by only 36 em units. This is not a full bold, more of a semi-bold I think, but it doesn't distort the shape of the glyphs as much.

[ZodWallop]

Originally Posted by GeoffR

I changed the name from Rosarivo to Rojarivo, Rosa (pink) to Roja (red) as the new font is slightly heavier, and appears to fix the problem with the 'j'.

It is a nice font and it is a shame to mess with it, maybe someone more knowledgable could take a look at the 'j' glyph in the original font and fix it without changing the weight. Also the bold versions I just created by using the default fontforge parameters, someone else might be able to do a better job.

I made these changes:

* Changed name of ligature tables from 'lig' to 'liga'.
* Increased weight of Regular/Italic by 4 em units.
* Created Bold/BoldItalic versions with weight increased by 50 em units.
* Changed PANOSE weights to book/bold.
* Added 'old-style' kern tables.
* Changed font name from Rosarivo to Rojarivo.

Edit: I've attached an alternative with the Bold/BoldItalic versions created by increasing the weight by only 36 em units. This is not a full bold, more of a semi-bold I think, but it doesn't distort the shape of the glyphs as much.

Thank you very much!

[anacreon]

Thank you Geoff. This is a beautiful font, but I find that it needs a very wide line spacing to avoid the dreaded cut-off lines at the bottom for kepubs (latest F/W), and it looks strange with the line spacing practically as wide as the line itself.

What I find stranger is that when I go back to Palatino linotype without changing the line spacing, the page looks much better.

[GeoffR]

Originally Posted by anacreon

Thank you Geoff. This is a beautiful font, but I find that it needs a very wide line spacing to avoid the dreaded cut-off lines at the bottom for kepubs (latest F/W), and it looks strange with the line spacing practically as wide as the line itself.

I don't know how to change that unfortunately, I think it is just a problem with the KePub reader. I could increase the internal line spacing in the font, but that would just make it like the Kobo Nickel font, with very wide line spacing in both the ePub and KePub readers. The way it is, at least it works fine in the ePub reader, and those using the KePub reader can increase the spacing to avoid the problem.

Edit: If anyone wants to have a go at fixing that problem, you can try adjusting the HHead ascent offset and/or HHead descent offset in OS/2 > Metrics, I have a feeling the only way to avoid the KePub cut-off problem is to use settings that increase the overall line spacing though -- either the font's internal spacing, or the spacing in the device/book stylesheet.

[GeoffR]

I have made a small change to the font metrics which seems to help with the KePub problem where the page break cuts off the top of the glyphs leaving them on the bottom of the previous page when the line spacing is very narrow.

This doesn't change the line spacing, it just shifts the glyphs downward on the line, so there is more space above and less below. After a little testing on my Glo it seems to avoid the cut-off problem, as long as the line spacing is not so narrow that the ascenders and decenders actually touch.

(Edit: If this change works for this font, then I think the same could work for any font with this problem.)

The only change from v1 is:

* Changed HHead ascent/descent offset to 120/120.

[anacreon]

The limit before the cut-off makes a somewhat wider line spacing than I would otherwise choose, but it is much better, and I will read with it. Thank you very much.

[bartveld]

May I suggest you also post this font here. For completeness sake...

[GeoffR]

This version has been rescaled in an attempt to make it fit in with the default Kobo fonts (Georgia, Avenir). The dark option appears similar in weight to Georgia on my Glo.

It should also work better at narrow line spacings in the KePub reader, On my Glo I can read KePubs with a line spacing setting as low as 0.9 (0.1 lower than the minimum setting on an unpatched device) before lines start to be cut off.

I have also added a few missing hyphen, dash, and spacing glyphs.

Changes since v2:

Spoiler:

* Added the following missing glyphs, by copying/scaling existing glyphs:
no-break space (U+00A0), thin space (U+2009) narrow no-break space (U+202F)
soft hyphen (U+00AD), hyphen (U+2010), non-breaking hyphen (U+2011)
figure dash (U+2012), horizontal bar (U+2015)

* Changed font size from 1000 to 1152, then re-scaled to 2048. Intention is to make the size of the font compatible with the default Kobo fonts, i.e. serif (Georgia) and sans-serif (Avenir).

* Dark vesion: Increased weight of Regular and Italic versions by 30, created Bold and BoldItalic versions with weight increased by 96. Intention is to make the weight closer to that of the default Kobo fonts.

* Changed HHead ascent/descent offset to 224/284. This is an attempt to work around a bug in the Kobo KePub reader, where page breaks leave the top part of the glyph on the previous page when the line spacing is narrow.

Edit: Updated to v3.2, which tries to find a medium between the line split problem which appears in KePubs at narrow line spacings, and the clip problem that appears at larger font sizes.

[GeoffR]

I've added v3.1 to the above post. It turns out that trying to avoid one KePub problem just causes another.

* v3 is probably better for those who read KePubs with very narrow line spacing.

* v3.1 is probably better for those who read KePubs with a large font size.

Either version is fine for reading ePubs.

Edit: The only difference between v3 and v3.1 is the HHead ascent/descent offsets. If you want to play with them in fontforge you might be able to find a setting that works better for you. Increasing both offsets improves the split problem and worsens the clip problem, decreasing both offsets does the opposite.

[GeoffR]

I've updated the attachments in post #28 to v3.2, which uses HHead ascent/descent offsets of 224/284. I think this version will avoid the KePub clip problem in most cases, but still allow the line spacing to be set a bit lower than in v2.