MERG table? ����

[Bendy]

I wonder if anyone has used the MERG table as documented on the MS site: MERG — Merge Table (OpenType 1.9) - Typography | Microsoft Learn

I’m hoping it might be helpful to overcome the double rasterisation issue we can see here, where the overlapping parts of my Khmer glyphs make the strokes a bit lumpy.

Unfortunately that MS page seems to indicate any intervening marks need to also be included in the merge sequence, but in the case of Khmer, there could be any number of marks on the first component so it wouldn’t be practical to define every possible base-to-base merge, unless there’s a clever way of including mark classes or ignoring marks totally.

Is there a way to add a MERG table in Glyphs so I could experiment with this?

[mekkablue (Rainer Erich Scheichelbauer)]

The question is also will renderers respect it. Probably the best option is to minimise the overlap, like in Arabic. There will typically still be some on-screen artefacts in the various renderers, but usually very little.

[Bendy]

Ned says it should work on Apple platforms, so I’d like to try it

[GeorgSeifert]

The spec page sais that the rasterizer should merge everything if no merge table is found. Clearly nobody is sticking to it.

Can you build the table manually with ttx? Do you need help with that?

[jkutilek (Jens Kutilek)]

AFAICS the MERG table is not implemented in fontTools, so with ttx you will only get a hex dump.

But maybe Apple‘s font tools support its creation? I haven’t checked.

[GeorgSeifert]

Adding that to ttx should be rather easy. It would be good to have a working font, though.

[Bendy]

I’d love to know how to build it manually with TTX, is there info somewhere or should we chat on Skype?

[GeorgSeifert]

The way ttx implements tables like this one is very much derived from the spec wording. We can try to figure that out together. Tomorrow at my 11am?

[Bendy]

That would be really great! Thank you, Georg

[jkutilek (Jens Kutilek)]

A surprisingly large number of system fonts contains the MERG table … on macOS:

SFCompact.ttf
SFNS.ttf
SFCompactItalic.ttf
SFNSRounded.ttf
SFCompactRounded.ttf
SFNSItalic.ttf

and on Windows:

consola.ttf
consolab.ttf
consolai.ttf
consolaz.ttf
segoeuii.ttf
seguisym.ttf
seguili.ttf
segoeuil.ttf
segoeuiz.ttf
seguisli.ttf
segoeuisl.ttf
seguisb.ttf
segoeuib.ttf
seguisbi.ttf
segoeui.ttf

[Bendy]

I’ve tried converting a couple of those with TTX but can’t see the MERG table inside. I know FontTools tells us “Other tables are dumped as hexadecimal data” but I can’t even see where it would be. Did you manage to see it?

[FlorianPircher]

This is the MERG table from SF-Pro.ttf:

<MERG raw="True">
<hexdata>
  00000002 00280003 000a0010 00180020
  000105be 00010001 000128d9 00010001
  000128dc 00010001 22000011 
</hexdata>
</MERG>

It does not look like a lot of data.

[Bendy]

I must be doing something stupid

[FlorianPircher]

Capitalization is relevant for table names:

ttx -t MERG SF-Pro.ttf

[Bendy]

Unfortunately I’m still stupid:

[FlorianPircher]

Try running the following:

sw_vers; ttx -o MERG.ttx -t MERG /Library/Fonts/SF-Pro.ttf

[Bendy]

Still the same problem. I’m probably needing to update Python/FontTools or have old versions of the fonts, or ?

[jkutilek (Jens Kutilek)]

I get this from Consolas, with the table structure annotated manually by me. It doesn’t contain much information …

<hexdata>
  00000001 000a0000 000c0000 
</hexdata>

0000 Version
0001 MergeClassCount
000a Offset To MergeEntryArray
0000 ClassDefCount
000c ClassDefOffsets
     (MergeEntryArray begins)
00   MergeEntryRow
  00 MergeEntry

[jkutilek (Jens Kutilek)]

Probably your version of Consolas doesn’t contain the table. Apparently it is only there since Windows 10.

[GeorgSeifert]

I have the decompilation working. Will try writing tomorrow.