Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overline Character U+0305 Not Rendering Correctly #1360

Open
bai-yi-bai opened this issue Aug 27, 2024 · 2 comments
Open

Overline Character U+0305 Not Rendering Correctly #1360

bai-yi-bai opened this issue Aug 27, 2024 · 2 comments

Comments

@bai-yi-bai
Copy link

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

@bai-yi-bai
Copy link
Author

bai-yi-bai commented Aug 27, 2024

That's not suspicious at all.
Edit for context a spammer had posted a link to a .zip file, thanks mods for deleting it.

@gettalong
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants
@gettalong @bai-yi-bai and others