Kerning

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Kerning

Marc Sabatella
I am noticing inconsistencies in kerning between systems in the text fonts we provide (FreeSerif, FreeSans, MuseJazz in particular), and want to start a discussion here rather than IRC where it will disappear into the ether like it did in the days leading up to Beta 1 when I last looked at this.

Back then, I determined that the key to kerning on MacOS was to check OpenType (under the TrueType options); no other options seemed relevant.  But the key to kerning on Linux was to *not* check that box.  And in particular, the advice I now see in fonts/README.md to uncheck "Old style kern" seemed to have no bearing on anything.  I ended up producing two different versions of MuseJazz - one with OpenType off (for Linux and Windows), one with it on (for Mac).  I observed that FreeSerif and FreeSans seemed to also have kerning issues, but I chose not to worry about that at that time.

Now that I am needing to generate updated versions of MuseJazz (I'm adding double flat and double sharp glyphs), I've had the opportunity to revisit this, and I am confused again.

I find that on one of my Ubuntu systems, FreeSerif and FreeSans do *not* kern at all in my self-builds from current sources.  On my other Ubuntu system as well as my Windows system, FreeSerif kerns but FreeSans does not.  MuseJazz kerns on all three systems.

The check I am using is the the text "Terj" which should be a good obvious case in most fonts.  Serif fonts should show kerning more noticeably on the "rj" whereas sans fonts will show it more noticeably on the "Te".

The one thing I know of that is different about the system where even FreeSerif does not kern is that it is running Qt 5.4 whereas the others are 5.3.  No idea if that's relevant or not, but it seems it could be.  I can get FreeSerif to kern on this system by regenerating it with OpenType turned off.  But paradoxically to me, MuseJazz kerns on this system even when generated with OpenType left on (the default), and FreeSans won't kern no matter what I do.  Regarding FreeSans, if I bring up a metrics window in FontForge and try to examing kerning info for pairs like Te, there is none.  So maybe the kerning is just plain broken for that font.

Anyone know anything about any of this?  Anyone want to test "Terj" (or some other string where you know what you are looking for) using all three fonts on your system and report the results?    chenlung reports that for him, only MuseJazz kerns on Mac.
Reply | Threaded
Open this post in threaded view
|

Re: Kerning

Marc Sabatella

Some additional information and corrections:

I have downloaded the latest sources for FreeSerif (normal and bold) and FreeSans and done some more testing.

I have realized that another difference between my two Linux systems is that the Qt 5.3 system had FreeSerif & FreeSans already installed system-wide, so I was not actually testing our version.  I have since updated that system to Qt 5.4, and disabled FreeSerif and FreeSans system-wide.  But it still behaves differently from my other Linux system.  On this system, FreeSans still will not kern no matter what I do.  But on the other Linux / Qt 5.4 system, I can get FreeSans to kern by tuning OpenType "off".

I have determined that FreeSerif will kern *partially* for me with the OpenType option turned "on".  But not totally.  Some combinations that have kerning info do in fact kern, but others don't.  I think it has to do with the different type of tables - some are direct character pairs, some are "class" based.  Only by turning the OpenType option "off" can I get FreeSerif to kern fully on my Linux system.  And as mentioned, that also allows FreeSans to kern on at least one of my systems.

So unless someone has additional information - and I hope someone does, because this is all just trial and error for me, not based on any particular understanding - I plan to submit new versions of FreeSerif and FreeSans, based on latest sources, with separate versions for Mac versus Linux/Windows.  Until I hear otherwise, though, I'm going to continue to assume MuseJazz kerns on all systems with the OpenType option "on".

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Kerning

Maurizio M. Gavioli
In reply to this post by Marc Sabatella
I start by limiting my observations to Linux, where I can analyse things more thoroughly. My system: Linux Mint 17 64bit, with self compiled sources with Qt Creator 3.1.2 and Qt lib 5.2.1. MuseScore built-in .ttf fonts are used as they come in the current master.

I had the additional problem that Free Sans/Serif font is installed by default on my distro and hides the font which comes with MuseScore. For cleaner results, I removed the system font, but this might not be what the average user wants to do (or knows how to do!): possibly another detail to keep in mind.

A) By adding a staff text element and setting a specific font, I can notice the following:

- Free Sans is NOT kerned;
- Free Serif IS kerned;
- MuseJazz IS kerned;
- all the 'standard' textual fonts I tried are kerned (by 'standard', I mean textual fonts which either comes with my distro or I got from well-known foundries, for instance Liberation, DejaVu, Droid, Gentium, Linux Libertine and others. I ignored non-textual fonts, like dingbats or symbols).
____________________

B) Notice: care should be used in the string used for showing the kerning.

For instance, for the "Terj" string used by Marc as a test bed: in the Free Serif/Sans, the digraph "Te" is kerned very little (-30 FU in Serif and -25 FU in Sans) and the offset is in many cases not easily noticeable. The digraph "VA" is kerned significantly more: -70 FU in Serif and -60 FU in Sans and should give more visible results.

Even more: "rj" is not kerned at all in Free Sans, but heavily kerned in Serif (-70 FU).

In practice, a string like "VA" or "AV" should show rather evident kerning for any font which has kerning data.
____________________

C) Kerning tables in .ttf fonts. If I open the current FreeSerif.ttf and FreeSans.ttf fonts with FontForge, I notice that for both it raises a warning:

"This font contains both a 'kern' table and a 'GPOS' table. The 'kern' table will only be read if there is no 'kern' feature in 'GPOS'."

It looks like the fonts have been generated from the .sfd with the "Old style kern" box checked.

Actually, after loading into FontForge the .ttf's, FreeSerif has kerning data in GPOS for Latin, but FreeSans lacks such data (only has kerning for Cyrillic).

By examining the lookup tables of the source FreeSans.sfd, it appears that the GSUB kern table for Latin has no feature at all. By adding a 'kern' feature for latn{dflt} to the kern lookup for Latin, re-generating the font and re-compiling MuseScore, also the Free Sans is kerned.

For the font generation, I used the following options:

"Apple": OFF
"OpenType": ON
"Old style 'kern'": OFF
_________________________

D) About discrepancies between Windows and Mac (two systems I cannot work with, as I no longer have machines running either), I simply want to remind that Microsoft and Apple succeeded in making TTF and OTF specs a mess by disagreeing in several details (kerning being one of them) and issuing conflicting specs. Then I am not surprised that the same font may work differently under Windows and under OSX but, as I said, I am not an expert of these areas.

Anyway, we may have to accept the idea that different versions of the fonts should be used under the two OSes.
____________________

E) About the advice in fonts/README.md to uncheck "Old style kern", I originally put it in, because somebody (possibly Marc himself?) noticed kerning issues under Windows with this box checked (this is also connected with D) above).

I still believe that turning the "Old style 'kern'" on, may confuse some font stack in some OS, but I will welcome reports of successful font generation with this box turned ON.

Thanks,

Maurizio
Reply | Threaded
Open this post in threaded view
|

Re: Kerning

Maurizio M. Gavioli
A small detail: I discovered that the 'standard' FreeSans.ttf coming with my distro has a different structure than FreeSerif: if open with FontForge, it lacks kerning data for Latin (as 'our' FreeSans does); possibly they are in the old-style 'kern' table rather than in the GPOS table / 'kern' sub-table.

This 'standard' FreeSans also DOES NOT kern with MuseScore, as 'our' FreeSans.

Maurizio
Reply | Threaded
Open this post in threaded view
|

Re: Kerning

Marc Sabatella
Thanks for the investigation!  That's good information about the reason for the lack of kerning in FreeSans.  Also good advice about the string to test with.  You are of course correct that VA is an easy case to test.  But FWIW, I found that this pair will *not* kern for me if I build FreeSerif.ttf using the OpenType option.  "rj" kerns, but neither "Va" nor "Te" do.  Only by turning that option *off* can I get a version of FreeSerif I build myself to kern fully.  This is Ubuntu 14.04 with Qt 5.4.  Same for FreeSans, but I didn't try moving the tables around, because I have no idea how to do that.

In any event, I have submitted PR https://github.com/musescore/MuseScore/pull/1506 that includes two version each of FreeSerif, FreeSerifBold, and FreeSans.  The regular version with OpenType *off*, the Mac version with OpenType *on*.

On Thu, Dec 4, 2014 at 6:33 PM, Maurizio M. Gavioli <[hidden email]> wrote:
A small detail: I discovered that the 'standard' FreeSans.ttf coming with my
distro has a different structure than FreeSerif: if open with FontForge, it
lacks kerning data for Latin (as 'our' FreeSans does); possibly they are in
the old-style 'kern' table rather than in the GPOS table / 'kern' sub-table.

This 'standard' FreeSans also DOES NOT kern with MuseScore, as 'our'
FreeSans.

Maurizio



--
View this message in context: http://dev-list.musescore.org/Kerning-tp7579040p7579043.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer



--
Marc Sabatella
[hidden email]

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Kerning

Maurizio M. Gavioli
Ok, let's use the big guns...

I run ttx on the current MuseScore FreeXxxx.ttf fonts and on your Mac and non-Mac variants (downloaded from your github PR). Leaving aside for the moment being the bold variants, these are the results.

1) Common tables: All fonts contains the following tables (which are more or less mandatory):

'GlyphOrder'
'head'
'hhea'
'maxp'
'OS/2'
'hmtx'
'cmap'
'cvt '
'loca'
'glyf'
'name'
'post'
'gasp'
'FFTM'

2) The current MuseScore fonts in addition contain:

*) FreeSans.ttf Tables:
        'fpgm'
        'prep'
        'kern' for Cyrillic only
        'GDEF'
        'GPOS' kern for Cyrillic, Latin and 'bn'(?), but only Cyrillic is linked to main lookup table
        'GSUB'

*) FreeSerif.ttf Tables:
        'fpgm'
        'prep'
        'kern' for Cyrillic and Latin (and several others)
        'GDEF'
        'GPOS' kern for Arabic, Cyrillic, Devanagari, Latin, Thai all properly linked
        'GSUB'

Note that:
2.1) both 'kern' and 'GPOS'/'kern' are present
2.2) 'GPOS'/'kern' for FreeSans.ttf is bogus; in fact FreeSans.ttf lacks any usable kerning data for Latin.

2.1) is in general not good, as the presence of both tables may confuse some font stack and/or make unpredictable which table a given font stack will use. The cure for this is to have only one of the 'OpenType' and 'Old-style kern' check boxes checked at a time.

2.2) is also obviously not good! There is a cure for this which I gave in my previous post and will repeat below.

3) Your font variants in addition to the common tables also contain:

*) FreeSans.ttf Tables:
'kern' for Latin only

*) FreeSans-Mac tables:
'GDEF'
'GPOS' kern for Latin only
'GSUB'

*) FreeSerif.ttf Tables:
'kern' for Latin only

*) FreeSerif-Mac.ttf Tables:
'GDEF'
'GPOS' kern for Latin only
'GSUB'

Note that:

3.1) non-Mac versions have the 'kern' table and lack the OpenType tables (as you turned off the OpenType check box) and that Mac versions have the OpenType tables and lack the 'kern' table (as you turned on the OpenTypeType check box and possibly kept off the Old-style kern check box). Having only one of the two tables is generally positive, as I said above.

3.2) Having different sets of tables for different fonts is sub-optimal, as it complicates maintenance and development and might be a source of problems difficult to track. My opinion is that there should a very good reason for this.

3.3) All fonts lost the non-Latin kern data. This may be secondary right now, but has to be kept in mind, given the international coverage of MuseScore. It would be nice to know from which editing / choice of settings this happened.

3.4) All fonts lack the 'fpgm' and 'prep' tables. They are not related with kern (at least, they should not be), but with font instructing: loosing these tables is generally not good, as very few (and usually rather simple) fonts can have instructing without them. We probably do not want to loose them.
__________________________

4) Some conclusions?

4.1) Of the two possibilities surfaced above:

'kern' table only without 'GPOS'/'kern'
vs.
'GPOS'/'kern' (and in general OpenType) tables only without the 'kern' table,

I believe the latter is generally preferable, because the former is a rather outdated setup and because other OpenType tables may contain useful data; for instance the FreeType-based font stack in (most) Linux automatically recognizes the 'GSUB'/'liga' sub-table for ligature substitution.

4.2) Of course, this implies that data in OpenType tables are correct. In current MuseScore FreeSans.sfd font, 'GPOS'/'kern' data are inconsistent, this is why it does not behave correctly.

4.3) Fixing FreeSans.sfd is easy: it is enough to add the missing 'kern' feature in the 'GPOS'/'kern' sub-table. With this change, the rebellious "VA" pair -- among others -- kerns correctly!

4.4) IMHO, until something solid surfaces against, the way to go is to generate all fonts from FontForge with:
*) Correct table data!
*) "OpenType" turned ON
*) "Old-style kern" turned OFF
*) "TrueType hints" turned ON

in order to have 'GPOS'/'kern' sub-table (and other potentially useful OpenType tables) without the 'kern' table messing in.

If helpful, I can submit a PR along 4.3) and 4.4) guidelines. If this would be more messy than helpful, I'll happily leave it to someone else.

4.5) For Mac/OSX, the impact of the "Apple" generation option possibly requires some investigation. I cannot do that; if someone is willing, is welcome! I would start with the options listed above, though.

Hoping it helps...

Maurizio
Reply | Threaded
Open this post in threaded view
|

Re: Kerning

Marc Sabatella
Thank again.  As you can see, I don't really know this stuff.  For the record, I did not use "old style kern" at all.  I always had apple and old style kern off.  I had tested the apple option and it seemed to have no effect with respect to kerning back in August.  The only relevant option appeared to be OenType, which had to be on for Mac, off for everyone else.

Losing kerning for non-Latin charcaters is not good.  So I am certainly open to alternatives to what I did, and indeed had no idea that would result.  But I am still struggling to reconcile what you are saying with what I am seeing  If I don't turn off the OpenType option option, I cannot get FreeSerif to kern on my Ubuntu machine running Qt 5.4.  I notice you say you are on 5.2 - maybe that is the difference?  Or maybe there is something else I am missing?  Maybe you could post a font you think should work, so I can check it out on my machines?

BTW, did you try grabbing the latest SFD sources?  Ours are pretty out of date.  You can use the ones from my branch.

Marc

On Fri, Dec 5, 2014 at 3:57 AM, Maurizio M. Gavioli <[hidden email]> wrote:
Ok, let's use the big guns...

I run ttx on the current MuseScore FreeXxxx.ttf fonts and on your Mac and
non-Mac variants (downloaded from your github PR). Leaving aside for the
moment being the bold variants, these are the results.

*1) Common tables*: All fonts contains the following tables (which are more
or less mandatory):

'GlyphOrder'
'head'
'hhea'
'maxp'
'OS/2'
'hmtx'
'cmap'
'cvt '
'loca'
'glyf'
'name'
'post'
'gasp'
'FFTM'

*2) The current MuseScore fonts* in addition contain:

*) FreeSans.ttf Tables:
        'fpgm'
        'prep'
        'kern'          for Cyrillic only
        'GDEF'
        'GPOS'          kern for Cyrillic, Latin and 'bn'(?), but only Cyrillic is linked
to main lookup table
        'GSUB'

*) FreeSerif.ttf Tables:
        'fpgm'
        'prep'
        'kern'          for Cyrillic and Latin (and several others)
        'GDEF'
        'GPOS'          kern for Arabic, Cyrillic, Devanagari, Latin, Thai all properly
linked
        'GSUB'

Note that:
2.1) *both* 'kern' *and* 'GPOS'/'kern' are present
2.2) 'GPOS'/'kern' for FreeSans.ttf is bogus; in fact FreeSans.ttf lacks any
usable kerning data for Latin.

2.1) is in general not good, as the presence of both tables may confuse some
font stack and/or make unpredictable which table a given font stack will
use. The cure for this is to have *only one* of the 'OpenType' and
'Old-style kern' check boxes checked at a time.

2.2) is also obviously not good! There is a cure for this which I gave in my
previous post and will repeat below.

*3) Your font variants* in addition to the common tables also contain:

*) FreeSans.ttf Tables:
'kern'          for Latin only

*) FreeSans-Mac tables:
'GDEF'
'GPOS'          kern for Latin only
'GSUB'

*) FreeSerif.ttf Tables:
'kern'          for Latin only

*) FreeSerif-Mac.ttf Tables:
'GDEF'
'GPOS'          kern for Latin only
'GSUB'

Note that:

3.1) non-Mac versions have the 'kern' table and lack the OpenType tables (as
you turned off the OpenType check box) and that Mac versions have the
OpenType tables and lack the 'kern' table (as you turned on the OpenTypeType
check box and possibly kept off the Old-style kern check box). Having only
one of the two tables is generally positive, as I said above.

3.2) Having different sets of tables for different fonts is sub-optimal, as
it complicates maintenance and development and might be a source of problems
difficult to track. My opinion is that there should a very good reason for
this.

3.3) All fonts lost the non-Latin kern data. This may be secondary right
now, but has to be kept in mind, given the international coverage of
MuseScore. It would be nice to know from which editing / choice of settings
this happened.

3.4) All fonts lack the 'fpgm' and 'prep' tables. They are not related with
kern (at least, they should not be), but with font instructing: loosing
these tables is generally not good, as very few (and usually rather simple)
fonts can have instructing without them. We probably do not want to loose
them.
__________________________

*4) Some conclusions?*

4.1) Of the two possibilities surfaced above:

'kern' table only without 'GPOS'/'kern'
vs.
'GPOS'/'kern' (and in general OpenType) tables only without the 'kern'
table,

I believe the latter is generally preferable, because the former is a rather
outdated setup and because other OpenType tables may contain useful data;
for instance the FreeType-based font stack in (most) Linux automatically
recognizes the 'GSUB'/'liga' sub-table for ligature substitution.

4.2) Of course, this implies that data in OpenType tables are correct. In
current MuseScore FreeSans.sfd font, 'GPOS'/'kern' data are inconsistent,
this is why it does not behave correctly.

4.3) Fixing FreeSans.sfd is easy: it is enough to add the missing 'kern'
feature in the 'GPOS'/'kern' sub-table. With this change, the rebellious
"VA" pair -- among others -- kerns correctly!

4.4) IMHO, until something solid surfaces against, the way to go is to
generate all fonts from FontForge with:
*) Correct table data!
*) "OpenType" turned ON
*) "Old-style kern" turned OFF
*) "TrueType hints" turned ON

in order to have 'GPOS'/'kern' sub-table (and other potentially useful
OpenType tables) without the 'kern' table messing in.

If helpful, I can submit a PR along 4.3) and 4.4) guidelines. If this would
be more messy than helpful, I'll happily leave it to someone else.

4.5) For Mac/OSX, the impact of the "Apple" generation option possibly
requires some investigation. I cannot do that; if someone is willing, is
welcome! I would start with the options listed above, though.

Hoping it helps...

Maurizio



--
View this message in context: http://dev-list.musescore.org/Kerning-tp7579040p7579045.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer



--
Marc Sabatella
[hidden email]

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Kerning

Maurizio M. Gavioli
OK, one .ttf is worth a thousand words... ;)

you (as well as everybody else) can download my attempts so far from:

http://vistamaremusica.com/extras/FreeSans.ttf

and

http://vistamaremusica.com/extras/FreeSerif.ttf

Both kerns correctly in my MuseScore and contain all the original data. I didn't try all the kerning pairs, of course, as many are not easy to spot visually, but the most obvious ones ("AV", "VA", and on Serif, "rj") do kern.

I downloaded the latest FreeFont sources and they have perhaps more glyphs but still have the same problems 'our' older sources have. The fonts linked above come from 'our' older sources.

Thanks,

Maurizio
Reply | Threaded
Open this post in threaded view
|

Re: Kerning

Marc Sabatella
No dice.  Neither of those fonts kern correctly for me on any of my three systems.  Again, both Linux systems are running Qt 5.4; there, neither font kerns at all.  My Windows machine has Qt 5.3.  On that machine, your FreeSerif will kern the "rj" but not the "Te" or the "VA".  Your FreeSans will kern the "VA" but not either of the other pairs.  I assume the difference has to do with different types of tables, but you know more about that than I. 

Again, only by *unchecking* the OpenType box can I get these fonts to kern correctly on my Linux machine running Qt 5.4 or my Windows machine running 5.3.  And I found the same for Linux with 5.3 back in August; that's why I went to two different MuseJazz fonts back then.  But I have no idea why MuseJazz will kern for me on Qt 5.4 even with OpenType checked but the other fonts won't.

BTW, I checked other "system" fonts.  On my Windows / Qt 5.3 machine, Arial and Times New Roman kern just fine, others are more hit and miss, but overall I'd say kerning "works" in MuseScore on Windows.  On my Linux / Qt 5.4 machines, very few fonts kern well.  Many work like your FreeSerif does on Windows - some pairs you expect to see kern do, but others don't.  Others don't kern at all.

It's looking like there is probably a Qt issue with OpenType on Linux and Windows, but I still don't know how to quantfiy it.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Kerning

Maurizio M. Gavioli
Marc Sabatella wrote
No dice.  Neither of those fonts kern correctly for me on any of my three systems.  Again, both Linux systems are running Qt 5.4; there, neither font kerns at all.  My Windows machine has Qt 5.3.  On that machine, your FreeSerif will kern the "rj" but not the "Te" or the "VA".
Results for "rj" and "Te" are correct: FreeSerif does contain a kerning pair for "rj" but it DOES NOT contain a kerning pair for "Te": obviously the latter will not kern under any circumstance!

About "VA" / "AV": are you sure it does not kern? For this pair the overlap is very tiny: in practice the tip of the serif of the 'A' just overlaps the tip of the serif of the 'V'.  This is a screen shot of the result to be expected:

"VArj" in FreeSerif

Your FreeSans will kern the "VA" but not either of the other pairs.  I assume the difference has to do with different types of tables, but you know more about that than I.
This also is correct: FreeSans has a kern pair for "VA" (stronger than Serif's) but NOT for "rj" or "Te".

Again, only by *unchecking* the OpenType box can I get these fonts to kern
correctly on my Linux machine running Qt 5.4 or my Windows machine running
5.3.
Well, I do not understand this: as far as your description goes, the fonts DO kern correctly (with the possible exception of Serif "VA"); if by unchecking the box, the fonts kern more than their data or for pairs which have no kern data, I don't think this to be "correct". Am I missing something?
 And I found the same for Linux with 5.3 back in August; that's why I
went to two different MuseJazz fonts back then.  But I have no idea why
MuseJazz will kern for me on Qt 5.4 even with OpenType checked but the
other fonts won't.
Is it possible that MuseJazz simply has more aggressive kerning data and then it is easier to spot by eye?

Just for completeness, which Linux do you have?

BTW, I checked other "system" fonts.  On my Windows / Qt 5.3 machine, Arial and Times New Roman kern just fine, others are more hit and miss, but overall I'd say kerning "works" in MuseScore on Windows.  On my Linux / Qt 5.4 machines, very few fonts kern well.  Many work like your FreeSerif does on Windows - some pairs you expect to see kern do, but others don't. Others don't kern at all.
Have you tried these fonts with other aplications, perhaps non-Qt-based?

It's looking like there is probably a Qt issue with OpenType on Linux and Windows, but I still don't know how to quantfiy it.
A difference in font support among the various Qt versions is definitely possible, but I would expect it to go toward a better support for OpenType tables not away from it... As soon as Linux Mint 17.1 will be released I'll upgrade another machine of mines to it and install the latest Qt (I'm not eager to upgrade Qt on my main machine: I have other Qt projects on it and "if it ain't broken, don't fix it").

Thanks,

Maurizio
Reply | Threaded
Open this post in threaded view
|

Re: Kerning

Marc Sabatella-2
There might not be an individual pair for "Te", but apparently it's covered by one of the "kern class" tables or whatever it is called.  Because it most definitely *does* kern in both FreeSerif and FreeSans, but *only* if I uncehck the OpenType option.  This is true for both Ubuntu 14.04 with Qt 5.4 and Windows 7 with Qt 5.3. And yes, I am positive about "VA".  The difference may be small but easily noticeable.  One check I like to do is move the cursor between the letters.  Overlap can be easy to see in those cases.

Marc


Marc Sabatella


On Fri, Dec 5, 2014 at 4:35 PM, Maurizio M. Gavioli <[hidden email]> wrote:

Marc Sabatella wrote
> No dice. Neither of those fonts kern correctly for me on any of my three
> systems. Again, both Linux systems are running Qt 5.4; there, neither
> font kerns at all. My Windows machine has Qt 5.3. On that machine, your
> FreeSerif will kern the "rj" but not the "Te" or the "VA".

Results for "rj" and "Te" are correct: FreeSerif does contain a kerning pair
for "rj" but it DOES NOT contain a kerning pair for "Te": obviously the
latter will not kern under any circumstance!

About "VA" / "AV": are you sure it does not kern? For this pair the overlap
is very tiny: in practice the tip of the serif of the 'A' just overlaps the
tip of the serif of the 'V'. This is a screen shot of the result to be
expected:

<http://dev-list.musescore.org/file/n7579049/test_kern_VArj_FreeSerif.png>


> Your FreeSans will kern the "VA" but not either of the other pairs. I
> assume the difference has to do with different types of tables, but you
> know more about that than I.

This also is correct: FreeSans has a kern pair for "VA" (stronger than
Serif's) but NOT for "rj" or "Te".


> Again, only by *unchecking* the OpenType box can I get these fonts to kern
> correctly on my Linux machine running Qt 5.4 or my Windows machine running
> 5.3.

Well, I do not understand this: as far as your description goes, the fonts
DO kern correctly (with the possible exception of Serif "VA"); if by
unchecking the box, the fonts kern more than their data or for pairs which
have no kern data, I don't think this to be "correct". Am I missing
something?

> And I found the same for Linux with 5.3 back in August; that's why I
> went to two different MuseJazz fonts back then. But I have no idea why
> MuseJazz will kern for me on Qt 5.4 even with OpenType checked but the
> other fonts won't.

Is it possible that MuseJazz simply has more aggressive kerning data and
then it is easier to spot by eye?

Just for completeness, which Linux do you have?


> BTW, I checked other "system" fonts. On my Windows / Qt 5.3 machine,
> Arial and Times New Roman kern just fine, others are more hit and miss,
> but overall I'd say kerning "works" in MuseScore on Windows. On my Linux
> / Qt 5.4 machines, very few fonts kern well. Many work like your
> FreeSerif does on Windows - some pairs you expect to see kern do, but
> others don't. Others don't kern at all.

Have you tried these fonts with other aplications, perhaps non-Qt-based?


> It's looking like there is probably a Qt issue with OpenType on Linux and
> Windows, but I still don't know how to quantfiy it.

A difference in font support among the various Qt versions is definitely
possible, but I would expect it to go toward a better support for OpenType
tables not away from it... As soon as Linux Mint 17.1 will be released I'll
upgrade another machine of mines to it and install the latest Qt (I'm not
eager to upgrade Qt on my main machine: I have other Qt projects on it and
"if it ain't broken, don't fix it").

Thanks,

Maurizio



--
View this message in context: http://dev-list.musescore.org/Kerning-tp7579040p7579049.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer



------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Kerning

Marc Sabatella-2
Hmm, actually looking at your picture, I won't swear there was *no* kerning of the VA.  Might have been that much.  But there is definitely noticeably more if I turn off OpenType.  Did you try that - either yourself or using the fonts I built?  I'm away from my computer but will try to post images tomorrow.  Also, did you try looking at the metrics window within FontForge with the SFD file loaded?  Typing letters into that is how I know how much kerning I should be expecting in the TTF.


Marc Sabatella


On Fri, Dec 5, 2014 at 4:40 PM, Marc Sabatella <[hidden email]> wrote:

There might not be an individual pair for "Te", but apparently it's covered by one of the "kern class" tables or whatever it is called.  Because it most definitely *does* kern in both FreeSerif and FreeSans, but *only* if I uncehck the OpenType option.  This is true for both Ubuntu 14.04 with Qt 5.4 and Windows 7 with Qt 5.3. And yes, I am positive about "VA".  The difference may be small but easily noticeable.  One check I like to do is move the cursor between the letters.  Overlap can be easy to see in those cases.

Marc


Marc Sabatella


On Fri, Dec 5, 2014 at 4:35 PM, Maurizio M. Gavioli <[hidden email]> wrote:

Marc Sabatella wrote
> No dice. Neither of those fonts kern correctly for me on any of my three
> systems. Again, both Linux systems are running Qt 5.4; there, neither
> font kerns at all. My Windows machine has Qt 5.3. On that machine, your
> FreeSerif will kern the "rj" but not the "Te" or the "VA".

Results for "rj" and "Te" are correct: FreeSerif does contain a kerning pair
for "rj" but it DOES NOT contain a kerning pair for "Te": obviously the
latter will not kern under any circumstance!

About "VA" / "AV": are you sure it does not kern? For this pair the overlap
is very tiny: in practice the tip of the serif of the 'A' just overlaps the
tip of the serif of the 'V'. This is a screen shot of the result to be
expected:

<http://dev-list.musescore.org/file/n7579049/test_kern_VArj_FreeSerif.png>


> Your FreeSans will kern the "VA" but not either of the other pairs. I
> assume the difference has to do with different types of tables, but you
> know more about that than I.

This also is correct: FreeSans has a kern pair for "VA" (stronger than
Serif's) but NOT for "rj" or "Te".


> Again, only by *unchecking* the OpenType box can I get these fonts to kern
> correctly on my Linux machine running Qt 5.4 or my Windows machine running
> 5.3.

Well, I do not understand this: as far as your description goes, the fonts
DO kern correctly (with the possible exception of Serif "VA"); if by
unchecking the box, the fonts kern more than their data or for pairs which
have no kern data, I don't think this to be "correct". Am I missing
something?

> And I found the same for Linux with 5.3 back in August; that's why I
> went to two different MuseJazz fonts back then. But I have no idea why
> MuseJazz will kern for me on Qt 5.4 even with OpenType checked but the
> other fonts won't.

Is it possible that MuseJazz simply has more aggressive kerning data and
then it is easier to spot by eye?

Just for completeness, which Linux do you have?


> BTW, I checked other "system" fonts. On my Windows / Qt 5.3 machine,
> Arial and Times New Roman kern just fine, others are more hit and miss,
> but overall I'd say kerning "works" in MuseScore on Windows. On my Linux
> / Qt 5.4 machines, very few fonts kern well. Many work like your
> FreeSerif does on Windows - some pairs you expect to see kern do, but
> others don't. Others don't kern at all.

Have you tried these fonts with other aplications, perhaps non-Qt-based?


> It's looking like there is probably a Qt issue with OpenType on Linux and
> Windows, but I still don't know how to quantfiy it.

A difference in font support among the various Qt versions is definitely
possible, but I would expect it to go toward a better support for OpenType
tables not away from it... As soon as Linux Mint 17.1 will be released I'll
upgrade another machine of mines to it and install the latest Qt (I'm not
eager to upgrade Qt on my main machine: I have other Qt projects on it and
"if it ain't broken, don't fix it").

Thanks,

Maurizio



--
View this message in context: http://dev-list.musescore.org/Kerning-tp7579040p7579049.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer




------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Kerning

Marc Sabatella-2
FYI, I just posted a reply including three screenshots, but it got routed to the moderation queue for veing slightly over the 40 KB limit...

On Sat, Dec 6, 2014 at 12:51 PM, Marc Sabatella <[hidden email]> wrote:
If one ttf is worth a thousand words, what are three PNG's worth? :-)  I think these will clarify *what* I am seeing, but doesn't completely answer *why* I see it or *what to do* about it.

Here is how Miwarre's FreeSerif and FreeSans look in MuseScore on my Ubuntu 14.04 system with Qt 5.4:


​If that's not "no kerning at all", it's pretty close.  I see no obvious kerning in "Te", "rj", or "VA" in either font.

Whereas here is how it looks with my versions:


​All three pairs kern very noticeably in both FreeSerif and FreeSans in my versions.  And this is what has set my expectations for how the kerning could potentially look.

Now, as I trace my steps, I am somewhat mystified by what I am seeing here in my version.  I would have sworn I had downloaded the most recent SFD files from ftp.gnu.org.  But as I look into this, it seems I actually got a much older version.  And in fact we already *are* using the most recent versions in our own Git repository.  So Miwarre's are actually built from the latest sources; mine apparently are not.  And if I built from the latest sources with OpenType *off*, I get the results I apparently am "meant" to get:


​This is somewhere between the completely unkerned look of Miwarre's versions and the fully kerned look of my previous versions.  Here, the "rj" kerns as expected (at least for FreeSerif), and I guess I get the very slight kerning of VA as well.  None to speak of in "Te", although it does somehow look tighter in my FreeSerif version, like maybe different bearings or something.  Or maybe that's an illusion.

Loading the correct (latest) SFD into FontForge, I can verify ne aspect of what Miwarre says - there is no kerning at all for "Te", and very little for "VA".  Whereas with the older sources I had accidentally downloaded, there was pretty significant kerning - a value of -86 for that "Te", for example.

The bottom line for me is still that I still get kerning with OpenType turned *off* but don't get it with it turned *on*.  I just don't get as much kerning as I'd like ever with OpenType *off* - apparently because, indeed, the info just isn't there in the SFD for some reason, even though it was present in older sources.

Hopefully this clarifies my concerns.  I guess it's not our problem if for some reason Gnu removed a bunch of the kerning info that was present in older versions of these fonts, but I do still think we need to build TTF's with OpenType *off* for Linux and Windows in order to get whatever kerning there is to work under Qt 5.4.

Marc



------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Kerning

Marc Sabatella-2
Trying again as the attachments in my previous reply exceeded the size limit:

If one ttf is worth a thousand words, what are three PNG's worth? :-)  I think these will clarify *what* I am seeing, but doesn't completely answer *why* I see it or *what to do* about it.

Here is how Miwarre's FreeSerif and FreeSans look in MuseScore on my Ubuntu 14.04 system with Qt 5.4:


​If that's not "no kerning at all", it's pretty close.  I see no obvious kerning in "Te", "rj", or "VA" in either font.

Whereas here is how it looks with my versions:


​All three pairs kern very noticeably in both FreeSerif and FreeSans in my versions.  And this is what has set my expectations for how the kerning could potentially look.

Now, as I trace my steps, I am somewhat mystified by what I am seeing here in my version.  I would have sworn I had downloaded the most recent SFD files from ftp.gnu.org.  But as I look into this, it seems I actually got a much older version.  And in fact we already *are* using the most recent versions in our own Git repository.  So Miwarre's are actually built from the latest sources; mine apparently are not.

At this point, I will continue in another message to get around the size limit.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Kerning

Marc Sabatella-2
(continued)

If I built from the latest sources with OpenType *off*, I get the results I apparently am "meant" to get:


​This is somewhere between the completely unkerned look of Miwarre's versions and the fully kerned look of my previous versions.  Here, the "rj" kerns as expected (at least for FreeSerif), and I guess I get the very slight kerning of VA as well.  None to speak of in "Te", although it does somehow look tighter in my FreeSerif version, like maybe different bearings or something.  Or maybe that's an illusion.

Loading the correct (latest) SFD into FontForge, I can verify ne aspect of what Miwarre says - there is no kerning at all for "Te", and very little for "VA".  Whereas with the older sources I had accidentally downloaded, there was pretty significant kerning - a value of -86 for that "Te", for example.

The bottom line for me is still that I still get kerning with OpenType turned *off* but don't get it with it turned *on*.  I just don't get as much kerning as I'd like ever with OpenType *off* - apparently because, indeed, the info just isn't there in the SFD for some reason, even though it was present in older sources.

Hopefully this clarifies my concerns.  I guess it's not our problem if for some reason Gnu removed a bunch of the kerning info that was present in older versions of these fonts, but I do still think we need to build TTF's with OpenType *off* for Linux and Windows in order to get whatever kerning there is to work under Qt 5.4.

Marc

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Kerning

Maurizio M. Gavioli
Well, it seems to me we are stuck: the results Marc gets by generating fonts with "OpenType" OFF are the results I get by generating fonts with "OpenType" ON, practically down to the pixel.

There is still the possibility it depends on the Qt lib version (mine 5.2.1 and his 5.4), but it would greatly surprise me if more recent versions of Qt stepped back in font support.

Anybody else want to try his luck in the matter?

Two questions for Marc:

1) had you any chance to check the fonts (mine and yours) in other applications?

2) Which Linux distro do you run and which version of FontForge do you use?

Marc Sabatella-2 wrote
[...]The bottom line for me is still that I still get kerning with OpenType turned *off* but don't get it with it turned *on*[...]

I guess it's not our problem if for some reason Gnu removed a bunch of the kerning info that was present in older versions of these fonts,
Kerning in FreeFonts sources is arguably a bit sloppy, but I agree it is not our concern at all.
 but I do still think we need to build TTF's with OpenType *off* for Linux and Windows in order to get whatever kerning there is to work under Qt 5.4.
I see and understand, but I am still not convinced there is no other way, because it looks like a step back of decades and also because this leads to loosing all the other data in GPOS and GSUB, for instance the 'liga' sub-table for ligatures.

Thanks,

Maurizio
Reply | Threaded
Open this post in threaded view
|

Re: Kerning

Marc Sabatella
I am using Ubutnu 14.04, and 31 the July 2012 version of FontForge.

As for other applications, no, I had not tried that.  Good idea.  With your version of the fonts placed in "~/.fonts", they do show up in LibreOffice, and they look like they do on your system: "rj" kerns, "Te" does not, "VA" does but just barely.  So it is indeed looking like a Qt difference.  BTW, with LibreOffice, even my version of FreeSerif build from older source with OpenType off does not kern well - it looks the same as when built from new sources, which is basically the same as how your version looks in LibreOffice.  It's enough to make me wonder if I am really testing the differenct versions of the fonts or somehow getting the same version over and over, but I am pretty sure I am doing it right.  If I remove the files from ~/.fonts, they don't show up at all in LibreOffice, then one at a time I try swapping in dofferent versions restarting LibreOffice each time.

I don't doubt there is another way to get the kerning to work, including perhaps pushing on Qt to resovle whatever issue 5.3 and 5.4 might have.  lasconic had pointed me to https://bugreports.qt-project.org/browse/QTBUG-11387 which sure sounds like the same thing - and as I have mentioned, I do see the same results on Windows 7.  But that was reported against 4.6.2.  Seems odd that it would have been fixed for 5.2 then broken again for 5.3 & 5.4, but you never know.

Regarding the loss of info  - are you saying that turning off OpenType necessarily means losing data, or are you just observing that the versions of the TTF files in my PR were missing data?  Remember, it turns out those were built from much older sources.  Do we know we'd lose the same data building with OpenType off from the current sources?

Marc

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Kerning

Maurizio M. Gavioli
Marc Sabatella wrote
I am using Ubutnu 14.04, and 31 the July 2012 version of FontForge.
Linux Mint 17 here, which is a derivative of pretty much the same as your OS (I never manage to remember the correspondence between the two lines). I used the same FontForge as you up to 3 days ago, when I upgraded to the latest release (2014-11-27), without noticing any difference in this area.

With your version of the fonts placed in "~/.fonts", they do show up in LibreOffice [...]
This seems to me to indicate that LibreOffice renders the fonts as they are intended to be rendered!

lasconic had pointed me to https://bugreports.qt-project.org/browse/QTBUG-11387 which sure sounds like the same thing - and as I have mentioned, I do see the same results on Windows 7.  But that was reported against 4.6.2.  Seems odd that it would have been fixed for 5.2 then broken again for 5.3 & 5.4, but you never know.
That bug is probably related, but it is not precisely the same: according to the report, it affects .OTF fonts with Type1 (PostScript) glyphs, not .TTF (with TT glyphs) which happen to include GPOS tables. It may indicate that font managing code is not that stable in Qt...

Regarding the loss of info  - are you saying that turning off OpenType necessarily means losing data, or are you just observing that the versions of the TTF files in my PR were missing data?  Remember, it turns out those were built from much older sources.  Do we know we'd lose the same data building with OpenType off from the current sources?
By generating TTF fonts with the "OpenType" option turned OFF, FontForge generates fonts without GSUB and GPOS tables (which is correct) and whatever data was in these tables is not exported into the font (with the exception of kerning, for which a TT-specific table exists and is generated by FF).

So, all data in GSUB and GPOS are lost (except kerning); this is perhaps less sever for Latin script (the average user can probably survive without the "fi", "ffi", "fl", "ffl" ligatures) but is a limitation anyway (and -- as I said -- a step back to the 80's in font management), and it might be much more problematic for non-Latin scripts (for instance for Indic scripts).

Thanks,

Maurizio
Reply | Threaded
Open this post in threaded view
|

Re: Kerning

robert leleu
Mint 17 is Ubuntu 14.04.
Its PPA are trusty labelled