-
Notifications
You must be signed in to change notification settings - Fork 498
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
Character set warning after page break #2453
Comments
Please provide a full reproducible example so I can run it. If this is, in fact, an issue, it seems to depend on a very specific set of circumstances that I don't want to have to spend time trying to figure out how to reproduce. |
Here's a minimal AsciiDoctor file:
And this might be an example image This minimal example is converted by the following command line call:
And I'm using Windows 10. I suspect the warning won't appear on GNU/Linux nor macOS. |
I also tried to minimize the base theme. It is indeed possible to reduce the used theme to an empty file. But it is nonetheless essential to refer to a theme, even if it is empty. I think that the default values without any given theme contain something special that triggers this encoding warning. |
I see what's happening here. The text for the fragment of an inline image is temporarily set to a placeholder character (\u2063) in order to reserve space where the image will be inserted. That placeholder character is never rendered. However, when the text containing that fragment is advanced to a new page, it causes the text to be normalized again. If the font is an AFM font, as is the case when using the base theme, it checks that the character can be encoded into the Windows 1252 character set, a requirement of using an AFM font. In this case, \u2063 cannot be encoded. This is when the converter normally looks for a fallback character. However, the fallback character for \u2063 is not defined in the map. (See https://github.com/asciidoctor/asciidoctor-pdf/blob/v2.3.9/lib/asciidoctor/pdf/ext/prawn/font/afm.rb#L6-L12). The fix that is needed here is to add a fallback character for \u2063 to the aforementioned map so that the text normalization operation succeeds. That character is never rendered, so the fallback value doesn't really matter. I will apply a fix and add a test for this. With that said, the base theme is not intended to be used directly. Rather, it is intended as a theme that you extend to add your own fonts and styles. The base theme defaults to AFM fonts, but these fonts are extremely limited. You are encouraged to use TrueType fonts, as described in the docs at https://docs.asciidoctor.org/pdf-converter/latest/theme/font-support/. If you use the default theme instead of the base theme, you would not receive this warning. Also, this is just a pedandic/verbose warning, not an error. It just communicates when the converter encounters a character that it cannot deal with. If that character isn't important, which is the case here, it does not impact the result. |
…acter when using AFM font
Thank you for the explanation and the immediate bug fix! Are there any plans when Version 2.3.10 will be published? I don't use the base theme directly but extend it in my own theme. But you're right, I didn't overwrite the font properties. I already suspected that this warning doesn't mean much. But I'd like to rise the failure level to warnings in order to fetch other bugs early enough. For example if images are missing I'd like to abort the conversion. It is very tedious to scan manually through our large documentation in order to spot those missing images. |
When I get to it. Though I am interested in getting a release out as the fixes are starting to accumulate.
You could still do that, just take away the |
If a sufficiently long text is followed by a block image such that the image must be positioned on a new page I got a warning about not fully convertible characters. The minimal example is a bit dull:
This file must be converted by the following call:
The automatic page break seems to be the problem. But interestingly enough the base theme seems to play an important role too, since omitting it fixes the issue.
The text was updated successfully, but these errors were encountered: