Open KrasnayaPloshchad opened 5 years ago
Source Serif supports the Adobe Latin-4 character set, which is one level shy of AL-5 – the largest character set we define for our Western fonts. Both requested characters are supported in AL-5: http://adobe-type-tools.github.io/adobe-latin-charsets/adobe-latin-5.html
While expansion of Source Serif to AL-5 is possible, it is not very high on the list of priorities – the next step for Source Serif is code point parity between Roman and Italic.
You need to avoid the bug as https://github.com/adobe-fonts/source-sans-pro/issues/178
I'm working on this issue as I need the font for a project. I have everything sort of working for my needs, but it would be great if I could get some advice from the devs because there are still some minor issues.
Namely, the sequence o uni0358
(or any accented o
glyph followed by 0358
combining dot above right) needs some extra horizontal space.
This is an issue in sequences like:
o uni0358 h
o uni0358 ?
o uni0358 uni207F
etc, where a tall glyph on the right intersects uni0358
.
I've never quite figured out the correct OpenType feature to accomplish this. The only way I've found to do it in the past (which I have done here as well) is to simply make a precomposed glyph for ccmp
with the correct advance width. No kerning strategy seems to work correctly in all cases.
At the moment I've made precomposed glyphs for o uni0358
and o uni0358 uni030D
which mostly works, but is inelegant.
Ideally, I think, we would want:
o uni0358
( = odotabovert
)uni0358
so that precomposition happens first, then marks get attached to odotabovert
via the top mark anchor.For example: oacute uni0358
would be rearranged to odotabovert acutecmb
. I believe this would solve the issue with only a single precomposed glyph.
Perhaps there's a way to do it without any precomposed glyphs, but if so I haven't been able to figure that out.
Any help would be appreciated!
https://github.com/aiongg/source-serif/blob/poj/Roman/familyGSUB.fea#L635
Is this something that could be solved with contextual kerning?
See this file for an example of a contextual kerning pair, which adjusts the periodcentered
glyph horizontally and vertically when between two L
s: https://github.com/adobe-fonts/source-serif/blob/main/Roman/Instances/Text/Regular/kern_ctxt.fea
In your case, one could write
pos o uni0358' 20 [h question uni207F];
… which would add a bit of room between the combining dot and the following character.
However, since uni0358
is a mark glyph, the kerning might be un-done by the “ignoreMarks” lookupflag here:
https://github.com/adobe-fonts/source-serif/blob/main/familyGPOS.fea#L12
This solution might not be what you’re looking for (or I am simply misunderstanding you), but perhaps it’ll help :-)
Yes I tried that, switching IgnoreMarks
to MarkAttachmentType [dotabovert]
(so the dots are not ignored re: kerning).
That appears to display correctly in, e.g., the FontForge metrics window. However, I couldn't get it to work in a browser. (I tried all the kern
related CSS properties to no avail, in latest Chrome/Firefox).
If kerning worked, that would certainly be the easiest method.
The L·L
kerning works fine in the browser, so I'm really not sure what the issue is.
I can set that up again if you want to take a look?
Not sure if anyone else needs this but I went ahead and just set up the whole font for POJ support, feel free to download from my fork: https://github.com/aiongg/source-serif
By the way, how do I hint the variable font files? I ran checkoutlines & psautohint on the master .ufos same as for the instances, but the variable fonts then failed to compile.
@frankrolf would you have any idea why these sfntedit commands break the VF builds on my fork? I removed the tables that were causing problems and all is well, but I guess it would be nice to fix it?
@aiongg Please note that you’re welcome to distribute a fork, but you cannot use the name “Source” for it.
About your question – it seems like you are building an incomplete VF? “All is well” – is that tested? Which tables remain in your build?
When using the buildVFs.sh script, I had to:
k
option on buildcff2vf
hhea
or post
tables from the OTF to the TTFI'm not sure how to test it other than looking at the VF e.g. in a browser, and my added glyphs show up correctly with those changes. (They are garbled without the changes, and I saw some oddness in a TTX dump that disappears when I don't copy those tables.)
Regarding the name, happy to change it, but would it be possible to tell me the easiest way to get the fonts coming out with the new names? There are ... very many things labelled "Source" in the repo, I don't expect I have to change every last one, just the released font files?
It depends on what you’re doing exactly, but “distribution” means the font files. The easiest way would be doing it via fontTools, something like this:
'''
Replace names in Source Serif font binaries using fontTools
'''
import pathlib
import sys
from fontTools import ttLib
font_files = sys.argv[1:]
old_name = 'Source'
# Careful with spaces in the replacement name. Some name records can contain
# them, others can’t.
new_name = 'Target'
for font_file in font_files:
ff_path = pathlib.Path(font_file)
ttf = ttLib.TTFont(ff_path)
name_table = ttf.get('name')
name_records = name_table.names
for nr in name_records:
if(
old_name in nr.toUnicode() and
# Find-replacing in the copyright statement would result in false
# information. Change completely, perhaps?
nr.nameID not in (0, 7)
):
new_nr = nr.toUnicode().replace(old_name, new_name)
name_table.setName(
new_nr, nameID=nr.nameID,
platformID=nr.platformID,
platEncID=nr.platEncID,
langID=nr.langID)
new_ps_name = next(
nr.toUnicode() for nr in name_table.names if nr.nameID == 6)
# I am a new user of Pathlib, so there might be a more elegant way
# to do this.
new_file_name = pathlib.PurePath(new_ps_name + ff_path.suffix)
ttf.save(ff_path.parent / new_file_name)
About your VF problem – I’ll have to look into that, but I’ll do it another day! :-)
Thanks for that, much appreciated!
Pe̍h-ōe-jī is a romanization of Min Nan Chinese, which has some special diacritics not appearing in western texts. However both of them are missing in Source Serif Pro: U+0358 COMBINING DOT ABOVE RIGHT U+030D COMBINING VERTICAL LINE ABOVE
See my screenshot![screenshot](https://user-images.githubusercontent.com/10364351/49956675-b4e6b680-fefd-11e8-892e-9f11d2c170da.PNG)