adobe-fonts / source-serif

Typeface for setting text in many sizes, weights, and languages. Designed to complement Source Sans.
https://adobe-fonts.github.io/source-serif
SIL Open Font License 1.1
2.15k stars 161 forks source link

Add some Pe̍h-ōe-jī diacritics #40

Open KrasnayaPloshchad opened 5 years ago

KrasnayaPloshchad commented 5 years ago

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

frankrolf commented 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.

KrasnayaPloshchad commented 4 years ago

You need to avoid the bug as https://github.com/adobe-fonts/source-sans-pro/issues/178

aiongg commented 2 years ago

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:

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

frankrolf commented 2 years ago

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 Ls: 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 :-)

aiongg commented 2 years ago

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?

aiongg commented 2 years ago

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.

aiongg commented 2 years ago

@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?

https://github.com/aiongg/source-serif/commit/b8dce5209ad74bf22135642cab51f2ef09245404#diff-c8c6dcceef0df3b545b174dab6d1eb13c0f5e69052b7a1af8a65ed5b7fbb1fff

frankrolf commented 2 years ago

@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?

aiongg commented 2 years ago

When using the buildVFs.sh script, I had to:

I'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?

frankrolf commented 2 years ago

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! :-)

aiongg commented 2 years ago

Thanks for that, much appreciated!