You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I use AsciiDoctor-PDF which relies upon Prawn, and while performing a document conversion, I came across some content which contains U+0305 which is the "combining overline" glyph. These glyphs are used in our technical documentation to indicate an inverted signal. For example: A̅
The trouble is that asciidoctor-pdf/prawn doesn't render it correctly. Our documentation theme uses the Windows Unicode Arial True Type font. The overline glyph starts halfway through the character using bold, italics, superscript, and subscript.
I could not get the alternative unicode-provided U203E to work correctly, even in Visual Studio Code. I didn't try Cambria Math, Asana Math, STIX fonts, Latin Modern Math, DIN 6776, ISOCP, Lucida Console, Tekton Pro, or Blueprint, which were all fonts which reportedly support overlining.
From my investigation of the Windows Unicode Arial True Type font in FontForge, it seems that the uppercase ASCII characters, 65-90, define the characters at the origin, while the overline character starts at -600, while the letters start at 0... but I suppose since it "prints" on top of the previous character that this explains why the overline character only inks on top of a letter starting at the halfway point. It seems there needs to be a corrective factor. I'm not familiar with prawn's code base to understand where such a corrective factor should be defined, and I don't think this factor is universal across all fonts. I also don't know if fonts contain additional information about how the overline character should be printed. I also don't know if there is another GEM which prawn relies upon for rendering font information.
This is a rare-enough edge case that I will go through the trouble of creating a custom font, but switching to a different font introduces a break point in Prawn, which is undesirable. If I use superscript afterwards, and there isn't enough space in the line, the superscript characters could be placed on a new line by themselves. So, having this natively supported would be nice.
This is generally a problem with combining characters because for them to work correctly Prawn/ttfunk would need to parse the respective font tables that provide the corrective information. However, parsing and applying the information in those tables is not quite as straight-forward as other parts of the font support and - as far as I know - has not been done.
For example, the Unicode character Ä can either be defined using a single codepoint or the codepoint for A and the combining codepoint for diaresis. The former usually has a separate glyph in the font and is displayed correctly by Prawn whereas the combination of A+diaresis is not displayed correctly.
Hi, I use AsciiDoctor-PDF which relies upon Prawn, and while performing a document conversion, I came across some content which contains U+0305 which is the "combining overline" glyph. These glyphs are used in our technical documentation to indicate an inverted signal. For example: A̅
The trouble is that asciidoctor-pdf/prawn doesn't render it correctly. Our documentation theme uses the Windows Unicode Arial True Type font. The overline glyph starts halfway through the character using bold, italics, superscript, and subscript.
I found a post from 2019 which stated Prawn didn't support overline characters, but it seems as though they are supported now, just with incorrect placement https://discuss.asciidoctor.org/Overline-in-Asciidoctor-pdf-td6736.html
I could not get the alternative unicode-provided U203E to work correctly, even in Visual Studio Code. I didn't try Cambria Math, Asana Math, STIX fonts, Latin Modern Math, DIN 6776, ISOCP, Lucida Console, Tekton Pro, or Blueprint, which were all fonts which reportedly support overlining.
From my investigation of the Windows Unicode Arial True Type font in FontForge, it seems that the uppercase ASCII characters, 65-90, define the characters at the origin, while the overline character starts at -600, while the letters start at 0... but I suppose since it "prints" on top of the previous character that this explains why the overline character only inks on top of a letter starting at the halfway point. It seems there needs to be a corrective factor. I'm not familiar with prawn's code base to understand where such a corrective factor should be defined, and I don't think this factor is universal across all fonts. I also don't know if fonts contain additional information about how the overline character should be printed. I also don't know if there is another GEM which prawn relies upon for rendering font information.
This is a rare-enough edge case that I will go through the trouble of creating a custom font, but switching to a different font introduces a break point in Prawn, which is undesirable. If I use superscript afterwards, and there isn't enough space in the line, the superscript characters could be placed on a new line by themselves. So, having this natively supported would be nice.
I initially rose this in the AsciiDoctor-PDF zulipchat. https://asciidoctor.zulipchat.com/#narrow/stream/288690-users.2Fasciidoctor-pdf/topic/Combing.20Overline.20Glyph.20Support.20in.20AsciiDoctor-PDF.2FPrawn
The text was updated successfully, but these errors were encountered: