Closed bai-yi-bai closed 8 months ago
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).
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