MegaMerged Noto Sans and Noto Serif?

[davelab6]

Is there a single mega-merged Noto Sans file available publicly, that users can substitute for eg Arial Unicode MS?

Use case: Rendering user generated text into PDFs after eSignature. This is possible with mixed language strings, but the PDF AcroForm Text field format only allows a single font to be set per text field (see eg stackoverflow.com/questions/47995062/pdfbox-api-how-to-change-font-to-handle-cyrillic-values-in-an-acroform-field), and has no support for a fallback stack.

I guess it would be helpful to have access to both OT1.9.x/BE versions, with 65k/all characters :)

[simoncozens]

There isn't one yet, but we can certainly look at putting one together...

[davelab6]

@simoncozens do you think you could make this happen in January, or Q1?

[simoncozens]

Yep, nearly there. Currently debugging some issues with merging some fonts which have vhea tables and others which don't. (Related mystery: Find out why some non-vertical fonts like Canadian Aboriginal and Ethiopic have vhea tables. Third-order digression: Write a fontbakery check to WARN if non-vertical scripts have a vhea table.)

[moyogo]

@simoncozens some glyphs have vertical metrics. It can happen by mistake.

[davelab6]

@simoncozens some glyphs have vertical metrics. It can happen by mistake.

Could you say more about this? I'm not sure what you mean exactly

[moyogo]

some glyphs have vertical metrics. It can happen by mistake.

Could you say more about this? I'm not sure what you mean exactly

The vhea, vmtx, VORG and VVAR tables are created when sources have vertical layout metrics.

Noto Sans Ethiopic and Noto Serif Ethiopic have vertWidth = 0; defined for tons of glyphs. Noto Sans Canadian Aboriginal has openTypeVheaVertTypoAscender, openTypeVheaVertTypoDescender and openTypeVheaVertTypoLineGap defined.

[simoncozens]

There we go: https://github.com/notofonts/notofonts.github.io/tree/main/megamerge

[anthrotype]

so you're using fontTools.merge tool to merge the font binaries. I thought you'd try to merge the sources. The binary merge script for Noto already existed as you may know already, at https://github.com/notofonts/nototools/blob/main/nototools/merge_noto.py

[simoncozens]

I didn't know of that, to be honest. I always forget about nototools because there is so much in there that is no longer relevant; none of the scripts there are used in the current production process.

There are some good things about that merge script, but also some bad things; it doesn't handle Serif, we don't need stub GSUB tables any more. But more importantly: I'm trying to keep all the data about repos etc. in a single source of truth so we don't have to edit a whole bunch of scripts every time a new repo is added.

But it does fix up the name table, which is a useful thing. I can add that as a one-liner with gftools.fix.rename_font.

A source merge across hundreds of repos is a scarier prospect; it might allow for doing a VF build, which would be quite exciting. But not a priority. We trust fontTools.merge, don't we? ;-)

[davelab6]

none of the scripts there [in nototools] are used in the current production process

I've therefore set the repo to Archive mode

[anthrotype]

I think the noto-emoji build toolchain for the bitmap CBDT color font still uses some of those nototools, perhaps we should wait before archiving it for good.

[davelab6]

@anthrotype the archive status in github is easily reversible, and won't effect usage, only pushing commits into the repo. Please ping me if you see that's needed :)

[anthrotype]

@davelab6 given that @rsheeter pushed some updates to some Unicode data files exposed via nototools API and used in noto color emoji toolchain as recently as 4 months ago for Unicode 15.1, I would say yes we do need to revert the archiving, at least until we find another place for those bits that are in fact still used.

[davelab6]

FYI It is un-archived :)