Index was outside the bounds of the array

PDFsharp is a .NET library for creating and modifying PDF documents.

Brought to you by: pdfsharp, stefan_lange

This project can now be found here.

#16 Index was outside the bounds of the array

Milestone: v1.0 (example)

Status: closed

Owner: nobody

Labels: None

Priority: 5

Updated: 2016-09-28

Created: 2013-03-07

Creator: SLavaLL

Private: No

Hello.

In some cases I have an exception "Index was outside the bounds of the array"
Callstack:
at PdfSharp.Fonts.OpenType.GlyphDataTable.GetOffset(Int32 glyph)
at PdfSharp.Fonts.OpenType.GlyphDataTable.GetGlyphSize(Int32 glyph)
at PdfSharp.Fonts.OpenType.FontData.CreateFontSubSet(Dictionary`2 glyphs, Boolean cidFont)
at PdfSharp.Pdf.Advanced.PdfCIDFont.PrepareForSave()
at PdfSharp.Pdf.Advanced.PdfType0Font.PrepareForSave()
at PdfSharp.Pdf.Advanced.PdfFontTable.PrepareForSave()
at PdfSharp.Pdf.PdfDocument.PrepareForSave()
at PdfSharp.Pdf.PdfDocument.DoSave(PdfWriter writer)
at PdfSharp.Pdf.PdfDocument.Save(Stream stream, Boolean closeStream)

Discussion

Richard Pennenga - 2013-05-09

What is the use case here? Is there an unusual font being used, or something else noteworthy? I'm using PDFsharp (0.9, .NET 1.1) and wondering whether I can run into this problem, or have more information to investigate it myself.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Richard Pennenga - 2013-05-09

I see in the stack backtrace a call to PdfSharp.Pdf.Advanced.PdfCIDFont.PrepareForSave(), which appears to be handling a CID font. Is this then for Hangeul/ Chinese/ Japanese text?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

PDFsharp Team - 2013-05-13

AFAIK CID fonts are also needed for Unicode. PDFsharp support Unicode, but not CJK.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

PDFsharp Team - 2013-05-13

status: open --> closed

Group: --> v1.0 (example)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

PDFsharp Team - 2013-05-13

Not reproducible.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bradley Peet - 2016-09-28

I've been battling this thread safety bug and finally figured it out. As you may know, FontData instances are stored in a dictionary and shared globally (via FontDataStock and FontDescriptorStock). FontData.CreateFontSubset() calls over to GlyphDataTable.CompleteGlyphClosure() which calls AddCompositeGlyphs() and that's where the trouble really begins. You wind up with multiple threads changing the FontData instance's Position property simulanteously while trying to read from its buffer. The whole concept of FontData having a "current position" for reading the internal buffer is just asking for trouble in a multi-threaded environment where FontData instances are widely shared.

I've got a fix for this that involves significant (but non-breaking) changes to the FontData class and small changes to GlyphDataTable. If anyone is interested I can elaborate and/or share the code. The PDFSharp version I'm working with is 1.3.2608.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Log in to post a comment.