Lowercase ‘a with grave’ (unicode u+00e0).Ĭreated in a font by combining the lowercase ‘a’ glyph (unicode u+0061) and the ‘combining grave accent’ glyph (unicode u+0300). Diacritical marks may appear above or below a letter, within it, or between two letters. Some diacritical marks (such as the ‘acute’ and ‘grave’) are often called accents. I have not yet investigated if Campania font behaves properly in Qt.A diacritic is a mark added to, or combining with, a letter, often used to change the sound value of the letter to which the mark is added. I found that, at least in my system, I have to delete all the tables in GSUB and all the table in GPOS not concerning kerning (to inspect it, load the font in FontForge, Element->FontInfo->Lookups) for this kerning to work, as you should see with FreeSerif5.ttf in the example.Īs a side note, I don't think Qt supports OpenType GPOS kerning out of the box, see I made FreeSerif5.ttf by playing around with MuseScore FreeSerif with FontForge until Qt decided to show the correct behavior. If line 15 of the example is changed so that FreeSerif5.ttf is loaded instead of FreeSerif.ttf, then the widget displays the correct kerning. You can see it in the example: there two identical fonts in which only the (internal) font name is changed FreeSerif.ttf and FreeSerif5.ttf. I found that if the Font calls itself "FreeSerif", then Qt loads the system font instead of the embedded resource font and I cannot see the right kerning. ![]() I ran it under Linux Mint 19.2, with Qt 5.12.5. To run it, simply open font_kerning.pro inside QtCreator, compile and run. Here is a small Qt example demonstrating the problem. Might this be related with our problem? As far as I now all kern data are equal in nature and there should be no reason for some to work and some not to work (or be listed) in some context (the same '0' value is listed in metric window for the system FreeSerifBoldItalic.ttf, so it is not an artifact of MuseScore font variant).įinally, both my system FreeSerifBoldItalic.ttf and MuseScore own FreeSerifBoldItalic.ttf contain both the kern table (“old style kern” in FontForge parlance) and the GSUB kern table so, in principle, it should be readable by ‘old’ and ‘new’ font stacks (whatever ‘old’ and ‘new’ may mean). Note however that FF has some trouble with kern data: it shows a kerning of 0 between f and e, but font lookup data show that it is actually -130, which, as afar as one can appreciate by eye, corresponds to what FF itself is showing in the metric window. Which match quite well the LibreOffice/InkScape display. This is how the MuseScore own version, as contained in the github repository, looks once opened in FontForge (one is the. (note the different spacing between f and e and possibly between r and l with respect to MuseScore example). This is how the default FreeSerif looks in LibreOffice and in InkScape (this is more solemn!): This is how the same word / same font looks in MuseScore (not very solemnly.): I think very probable that it is an unrecognised kern issue. As the OP did not declare his system, I do not how this translate in his case. So the FreeSerif (in this case, bold-italics) I see in MuseScore is the same system font coming with my distro and used by other applications too. It took me some magic, but finally I discover that the AppImage does not contain any font, evidently relying on system fonts. First, I am using the 3.3 AppImage on Linux Mint 19.1 (<= Ubuntu 18-04).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |