Log in to start a topic

Winforms C1.C1Preview.Export.PdfExporter "unable to read..."

Posted by: tom.galczynski on 10 July 2026, 2:06 pm EST

  • tom.galczynski

    Posted 10 July 2026, 2:06 pm EST

    Hello support, we’ve had a customer report to us that some of their users are no longer able to save reports with Chinese or Arabic characters from the C1 Preview form. We were able to reproduce this but not on all machines. 2 machines with identical windows versions, identical installed fonts, one is able to save to pdf and one is not. The error is:

    System.IO.EndOfStreamException: Unable to read beyond the end of the stream.

    at System.IO.__Error.EndOfFile()

    at System.IO.BinaryReader.ReadByte()

    at C1.Util.FontSubSet.BigEndianBinaryReader.ReadUInt16()

    at C1.Util.FontSubSet.bs.a(Int64 a, BinaryReader b, UInt16 c)

    at C1.Util.FontSubSet.ah(Int64 a, BinaryReader b)

    at C1.Util.FontSubSet.ak(Int64 a, BinaryReader b)

    at C1.Util.FontSubSet.al()

    at C1.Util.FontSubSet.GetFontSubSet(FontKey fk)

    at C1.C1Pdf.PdfFont.GetAlternativeFont(String text)

    at C1.C1Pdf.C1PdfDocumentBase.a(PdfFont A_0, String A_1, Boolean A_2)

    at C1.C1Pdf.C1PdfDocumentBase.a(String A_0, List`1 A_1, Boolean A_2, Int32 A_3)

    at C1.C1Pdf.C1PdfDocumentBase.GetFontBlocks(String text, Boolean vertical)

    at C1.C1Pdf.PdfMetafileConverter.EmfExtTextOut(PointF pt, RectangleF rc, RectangleF rcl, String text, Int32 fOptions, Int32 lpdx, PointF pscl)

    at C1.Util.MetafileConverterBase.bx(BinaryReader a, Boolean b)

    at C1.Util.MetafileConverterBase.f(EmfPlusRecordType a, Int32 b, Int32 c, IntPtr d, PlayRecordCallback e)

    at System.Drawing.SafeNativeMethods.Gdip.GdipEnumerateMetafileDestPoint(HandleRef graphics, HandleRef metafile, GPPOINTF destPoint, EnumerateMetafileProc callback, HandleRef callbackdata, HandleRef imageattributes)

    at System.Drawing.Graphics.EnumerateMetafile(Metafile metafile, PointF destPoint, EnumerateMetafileProc callback, IntPtr callbackData, ImageAttributes imageAttr)

    at System.Drawing.Graphics.EnumerateMetafile(Metafile metafile, PointF destPoint, EnumerateMetafileProc callback)

    at C1.Util.MetafileConverterBase.a(Metafile a, ReferenceDC b, Boolean c)

    at C1.Util.MetafileConverterBase.Render(Metafile meta, Boolean parseEmfPlus)

    at C1.C1Pdf.C1PdfDocument.DrawMetafile(Metafile meta, RectangleF rcImage, RectangleF rcClip, Boolean clipAllStrings, GraphicsUnit unit)

    at C1.C1Preview.Export.PdfExporter.ProcessPage(Metafile pageImage, C1MetafileInfo metafileInfo, Int32 pageNo, Boolean firstPage)

    at C1.C1Preview.Export.Exporter.a(Metafile A_0, Int32 A_1, Int32 A_2, Boolean A_3, Boolean& A_4)

    at C1.C1Preview.Export.Exporter.c()

    at C1.C1Preview.Export.PdfExporter.InternalExport()

    at C1.C1Preview.Export.Exporter.Export(String fileName)

    I did see another topic that some users reported the windows version was a factor but that is apparently not the case for us. Nor are installed fonts a factor. Is there anything else we can look at/test for that might resolve this? Fortunately, we CAN print from the preview form to Microsoft Print To PDF printer driver without an issue. (dll version is 4.8.20232.611)

    Thanks for your help!

  • uttkarsh.matiyal

    Posted 13 July 2026, 4:42 am EST

    Hello Tom,

    Thank you for providing the stack trace. We tried to reproduce this behavior on our end. While we were unable to replicate it with Arabic, we were able to reproduce the EndOfStreamException specifically when using the Export() method with Chinese culture in the document.

    We then tested this scenario using the latest version of our package, C1.Win.Printing (10.0.20261.796), and the issue appears to be resolved.

    We suggest you test the behavior with the latest version in your environment.

    JFYI, the C1PrintDocument and C1PrintPreviewControl are now included in our multi-targeted C1.Win.Printing package, which you can easily install in both .NET Framework and .NET Core projects to test out.

    If the issue persists after updating to the latest version, please provide us with a stripped-down sample project so that we can investigate this further.

    Regards,

    Uttkarsh.

  • wknauf

    Posted 13 July 2026, 4:44 am EST

    Hi Tom,

    sounds like https://developer.mescius.com/forums/winforms-edition/unable-to-read-beyond-the-end-of-the-stream-error-c1printdocument-export-pdf

    Could you check whether the workarounds discussed in this thread help?

    Regards

    Wolfgang (not from C1 ;-))

  • tom.galczynski

    Posted 13 July 2026, 1:15 pm EST

    Hi Wolfgang, I did see that topic you mentioned but in my case my colleague on another machine with the same Windows version and same installed fonts IS able to save the report to a pdf without an error so the fixes in that thread didn’t seem relevant. I was not thinking it was a bug in the C1 exporter at all because of that fact and was really trying to get some insight as to what possible difference the machine could make since my colleague and I are running the same software and using the same data.

    I’ll keep testing and report my findings. Thanks for the comment!

    Regards,

    Tom

  • tom.galczynski

    Posted 17 July 2026, 3:12 pm EST

    Hello again. :slight_smile: After further testing I have found that on a C1Report that has a control using the Arial Unicode MS font and has a value with Chinese characters, I am getting the EndOfStream exception when trying to save to pdf from the preview form. If I use Microsoft Sans Serif font on the control I do NOT get the error. Some colleagues NEVER get the error no matter what font is on the control. I did try to set a fallback font listing for Arial Unicode MS in my registry similar to other values but that didn’t help.

    So I’m really asking support if they can think of any system setting or registry setting (or anything else) that could possibly affect this? We have the same Windows versions, the same installed fonts, yet some can save to pdf with the report control using Arial Unicode MS and some can not. Very strange!

    Thank you ,

    Tom G.

  • uttkarsh.matiyal

    Posted 20 July 2026, 5:17 am EST - Updated 20 July 2026, 5:27 am EST

    Hello,

    Thank you for providing the additional details regarding the Arial Unicode MS font. We completely understand how frustrating it can be when seemingly identical machines produce different results.

    We researched the Arial Unicode MS font and found that Microsoft has officially discontinued it, and is no longer installed as part of Office, refer to Arial Unicode MS. This discontinuation may be the discrepancy between the systems. The working machines might have a different system-level fallback font mechanism or an alternative font available that the failing machines lack.

    Additionally, please note that C1Report is a legacy control and has been marked as obsolete. We recommend using FlexReport.

    While you are still utilizing C1Report, there is a property you can test. The FontProcessingOptions property allows you to define a SubstitutionFallbackFontName. You can try changing this property to a different font to see if it bypasses the exception on the failing machines. You can find more information here: FontProcessingOptions-C1Report.

    To help us investigate further, could you please:

    1. Verify if the same behavior occurs when rendering the document using the FlexReport control.
    2. Share a simple stripped-down project, or at the very least, the report definition file containing the specific Chinese text.
    3. Provide the exact machine configurations and a list of installed fonts from both machines for comparison.

    We look forward to your response so we can help you resolve this.

    Regards,

    Uttkarsh.

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.