Bug: Tables with ☑ or ☐ in Header Row Rendered as Missing Glyph

[bai-yi-bai]

While working on a font-fallback issue, I created a table with a header which has all the characters required by AsciiDoctorPDF (☑ ☐) in the header row. However, the characters are rendered as missing glyphs.

This impacts both hard-coded and csv included files.
This appears to impact ONLY the default-theme; when I specify my own theme (using Windows fonts), the characters display correctly. To rule out any Windows issue, I re-created a minimal example on a Linux machine with a fresh install of AsciiDoctor-PDF and created it in Visual Studio Code.

asciidoctor-pdf version details:
Asciidoctor PDF 2.3.9 using Asciidoctor 2.0.20 [https://asciidoctor.org] Runtime Environment (ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux-gnu]) (lc:UTF-8 fs:UTF-8 in:UTF-8 ex:UTF-8)

This bug was discussed on the zulipchat:
https://asciidoctor.zulipchat.com/#narrow/stream/288690-users.2Fasciidoctor-pdf/topic/Bug.20-.20Tables.20with.20Headers.20Render.20.E2.98.91.20or.20.E2.98.90.20as.20Missing.20Glyph

Minimal Example

= Testing Tables with Ballot Box Table Header
This minimal example shows a problem with some characters in the asciidoc header.
This was generated on a Windows and a Linux system from Visual Studio Code using the default theme/settings.

* [*] Ballot Box with Check
* [ ] Ballot Box without Check

.Table Hard-Coded AsciiDoc Table
[options="header",cols=3]
|===
|► \u25ba BLACK RIGHT-POINTING POINTER
|☑ \u2611 BALLOT BOX WITH CHECK
|☐ \u2610 BALLOT BOX

|► \u25ba BLACK RIGHT-POINTING POINTER
|☑ \u2611 BALLOT BOX WITH CHECK
|☐ \u2610 BALLOT BOX
|===

.Table Hard-Coded AsciiDoc Table
[%header,cols=3]
|===
|► \u25ba BLACK RIGHT-POINTING POINTER
|☑ \u2611 BALLOT BOX WITH CHECK
|☐ \u2610 BALLOT BOX

|► \u25ba BLACK RIGHT-POINTING POINTER
|☑ \u2611 BALLOT BOX WITH CHECK
|☐ \u2610 BALLOT BOX
|===

[mojavelinux]

I can explain what's going on here, and it is specific to the ballot box characters. The glyphs for the ballot boxes are only in the regular (normal) default font (Noto Serif), not in the bold variant. However, when the code analyzes the glyphs, it does not consider inherited styles and ends up looking for the glyph in the regular variant. Since it finds it there, it assumes the font has it. However, when it goes to actually get the glyph, it takes it from the bold variant. The mismatch in the analysis led to a missing glyph and no warning.

I've corrected this logic so that it looks in the correct font (family and variant).