Log in to start a topic

Calibri broken in exported PDF when set as NeverEmbedFonts

Posted by: twolak on 9 August 2018, 3:35 am EST

  • twolak

    Posted 9 August 2018, 3:35 am EST

    Hello,

    we found an issue while exporting generated section report to PDF file.

    When we set Calibri font as NeverEmbedFonts, alpha character is exported using other font (MSUIGothic that is Embedded) but displayed in report preview using Calibri font. Additionally text in output PDF is cut off.

    When we don’t set Calibri as NeverEmbedFonts alpha character is properly export to PDF.

    Do you have any suggestions how to export alpha character properly while having Calibri added to NeverEmbedFonts (not Embedded)?

    Why other font (MSUIGothic) is used for rendering alpha character with font that is Embedded?

    We use AR v9.2.3032.0 and v11.2.10750.0.

    This is urgent for us to resolve this issue. Thank you for your help.

    Attachments in Zip File:

    attachments.zip

    HowToReproduce.PNG - how to reproduce

    final.rpx - template to reproduce issue in sample AR designer.

    1.rtf - rtf loaded to RTB control.

    pdf_wrong_font.jpg - alpha character font properties (wrong font) when Calibri set as NeverEmbedFonts.

    pdf_correct_font.jpg - alpha character font properties when Calibri not set as NeverEmbedFonts.

    pdf_fonts_used.jpg - font used in our case in PDF file.

    Calibri_Font_Installed.PNG - Calibri font installed in my PC

  • twolak

    Posted 9 August 2018, 3:41 am EST

    wrong attachment above (added by mistake), here is the proper one:

    attachemnts.zip

  • mohitg

    Posted 9 August 2018, 8:24 am EST

    Hello,

    Thanks for the information!

    I am able to replicate the issue at our end. I have escalated the issue to our developer team and will update you once I get any information from them.

    Sorry for the inconvenience caused.

    Regards,

  • mohitg

    Posted 16 August 2018, 1:11 am EST

    Hello,

    Unfortunately, this is the limitation of AR PDF Export.

    Could you please let me know the criticality of the issue for you?

    Also, could you use PageReport (FormattedText control which supports only HTML tags) instead of SectionReport?

    Thanks,

  • twolak

    Posted 20 August 2018, 6:46 am EST

    Hello,

    “This is the limitation of AR … bla bla bla”… This is the n-th time you are trying to name something that does not work as LIMITATION. It is not a limitation - it is a BUG so you should name that way. Pleas be honest… do you still correct ANY BUGS for Active Reports - Section Reports.

    You always suggest to use Page Reports that are completely different from Section Reports and FormattedText control that is a basic version of RichTextControl.

    You never propose any reasonable solutions or workarounds for the BUGs your software has.

    This is a CRITICAL issue for us as there is no way to guess or find out WHERE and WHY such bugs occur. We have no way to prevent from generation wrong reports or at least find and correct such wrong reports!!!

  • rwilson

    Posted 20 August 2018, 10:21 am EST

    Having a similar issue, with a very old version of ActiveReports. Probably due to this windows patch but we are not sure yet.

    https://support.microsoft.com/en-us/help/2761217/an-update-is-available-to-add-the-calibri-light-and-calibri-light-ital

    Best option might be to role it back. Another we are considering is finding and replacing the font where when we have errors.

  • mohitg

    Posted 20 August 2018, 11:40 pm EST

    Hello,

    We understand how you feel, we’re very sorry!

    I am discussing with our development team about your issue and will update you shortly.

    Thanks,

  • Sergey.Romanov

    Posted 21 August 2018, 1:16 am EST

    Hello ,

    In regard to the issue with the alpha character, it is the 2 bytes character, without additional char mapping to the original code page of the character(in our case it is Greek code page) and without embedded fonts, PDF export takes the needed glyphs for such characters from the default font. PDF export uses(has implemented) the specific mappings for Windows 1252 and CJK rendering only. therefore there is no bug, but a limitation.

    If this issue is critical for you, the development team could take it as a new feature for research.

    Thanks,

    Sergey Romanov.

  • twolak

    Posted 21 August 2018, 8:56 am EST

    Sergey, I can accept your explanation and it is obvious that there is no component that implements ALL the features, but… I cannot accept that there is NO way to prevent from wrong reports being generated. Our clients generate tens of thousands of reports per day manually or by some automated processes and there is no possibility to review each and every report to find out that a few of them are spoiled. There has to be some information on programming API level that such problem occurred so some automated actions can be taken to fix the problem or even qualify for a manual human review etc…

    It is the n-th problem of losing data on SectionReports (wrong display of data in RichTextEdit, not printing some data on a report across the pages, missing whole pages on the report etc…) that we report to GrapeCity and we never get any solution/workaround to mitigate the problems. We can accept bugs/limitations only if we can fight them, but the only option that GrapeCity gives us is “Do not use it” without providing any help of solving the consequences that the bug/limitation causes. Thanks.

  • ilia

    Posted 21 August 2018, 9:07 am EST

    Hello, Sergey,

    You are not right.

    An alpha character does not always have 2 bytes. It can be one byte

    when you use Window 1253 (Greek code page). Code page, which you can select according to Font.gdiCharset.

    P.S. In Greek code page you can display all English characters without limitations.

  • Sergey.Romanov

    Posted 21 August 2018, 10:04 am EST

    Hello, Ilia,

    on non-Greek localized OS, the alpha character entered via UI will be always represented by 2 bytes even if you select Greek input language. you can check it with Notepad in Windows EN.

    perhaps “Language for non-Unicode programs” property could help with Notepad in such case, but i am sure it won’t help for ActiveReports based on .NET Framework.

    yes, i agree in Greek code page we can show both Greek and English characters, but we save the report layouts in Unicode, because it allows to show much more than 2 alphabets in the single report.

    therefore, as i said before, PDF export needs the additional char mappings.

    also, i would like to notice RichTextbox and FormattedText controls have the independent code-bases for HTML rendering since the beginning, now developers are replacing the old rendering in RichTextbox by FormattedText rendering engine.

    Thanks,

    Sergey Romanov.

  • ilia

    Posted 22 August 2018, 12:02 am EST - Updated 30 September 2022, 6:05 pm EST

    Hello Sergey,

    “This is the limitation of AR …”.

    This is DataDynamics bug since 1998.

    When you export to PDF with NeverEmbedFont

    instead of WinAnsiEncoding you can use CP1253 for Greek Font.Charset or

    CP1255 for Hebrew or CP1251 for Cyrilic.

    See the encodings for single-byte character set in the Haru Free PDF Library

    http://libharu.sourceforge.net/fonts.html#The_type_of_encodings_

    P.S. If you need I can send you code how to convert Unicode or UTF8 to ANSI with code page.

  • Sergey.Romanov

    Posted 22 August 2018, 2:40 am EST

    Hello Ilia ,

    if your sample of code can help to convert the single Unicode string with Greek, Hebrew, Cyrillic and English words(or any random combination of 2+ non-English languages) to the single ANSI string that would be helpful.

    Thanks,

    Sergey Romanov.

  • ilia

    Posted 22 August 2018, 3:53 am EST

    Hello Ilia ,

    if your sample of code can help to convert the single Unicode string with Greek, Hebrew, Cyrillic and English words(or any random combination of 2+ non-English languages) to the single ANSI string that would be helpful.

    Thanks,

    Sergey Romanov.

    We do not need 2+ non-English languages in one single Unicode string.

    We can use two or more strings with different non-English languages on one single Page.

    What with to change WinAnsiEncoding?

  • Sergey.Romanov

    Posted 22 August 2018, 6:12 am EST

    Ilia ,

    Let’s see what we have right now – when the font is not embedded the PDF export filter takes glyphs for some 2 bytes symbols from the default system font. The data is not lost just a part of symbols look a bit different in the PDF output.

    If we get rid of the above limitation and set the specific encoding(instead of the current WinAnsiEncoding) for the string then we need a char mapping to determinate the code page for 2 bytes symbol entered by the end user or returned by any text source. That would work for text with English and 1 non-English alphabet, but for more complicated use cases e.g. with one more non-English alphabet the part of text with additional non-English alphabet will be lost.

    Thanks,

    Sergey Romanov.

  • ilia

    Posted 23 August 2018, 12:11 am EST - Updated 30 September 2022, 6:05 pm EST

    First of all, for the case with two non-English languages, you have a embedded mode or RichTextBox.

    Secondly, in the NeverEmbed mode, now non-English letters look distorted in position and in size.

    In the third, NeverEmbed mode is the mode to speed up the creation of the PDF file, opening the file and printing PDF, what you are depriving non-English languages (you use any other Embedded Font for non-English letters).

    Best regards,

    Ilia Wirobjoffs.

  • Sergey.Romanov

    Posted 23 August 2018, 2:51 am EST

    Hello Ilia ,

    the embedded mode works in all cases, with one or more non-English alphabets and the solution for issues with NeverEmbedFonts should be universal else we will need to re-fix it for the customers with 2+ non-English alphabets in the text because they can’t accept the using of Embed mode or RichTextbox control.

    i know NeverEmbedFonts property is used to decrease the size of PDF output, however the strict PDF formats like PDF/A do not allow to use it.

    Thanks,

    Sergey Romanov.

  • ilia

    Posted 23 August 2018, 3:36 am EST

    First of all, your customers cannot use

    2+ non-English alphabets in the text with NeverEmbedFonts, because the distorting of text.

    Secondary, NeverEmbedFonts property is used to decrease the size of PDF output and * “speed up”

     PDF output.

    In the third, that the strict PDF formats like PDF/A do not allow to use NeverEmbedFonts does not mean that it is forbidden to use this mode.

    P.S.

    GrapeCity Limitation:

    GrapeCity does not support NeverEmbedFonts for Non-English languages.

  • Sergey.Romanov

    Posted 23 August 2018, 5:18 am EST

    Ilia ,

    we will add a remark with this limitation to the ActiveReports documentation at NeverEmbedFonts property description.

    Thanks,

    Sergey Romanov.

  • ilia

    Posted 23 August 2018, 6:05 am EST

    Hello Sergey,

    I’ve got one more question.

    Why export to PDP (PdfExport.Export) of one page in the second time is 20 times faster than the first. In the fact that this is time of loading assemblies I do not believe.

  • Sergey.Romanov

    Posted 24 August 2018, 1:54 am EST

    Hello Ilia ,

    unfortunately, it is not just a loading of file to RAM.

    the time is consumed by JIT compilation in the most part.

    Thanks,

    Sergey Romanov.

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels

  • © 2023 MESCIUS USA, Inc. All Rights Reserved.  ·  1.800.858.2739

    All product and company names herein may be trademarks of their respective owners.