0

When I specify a path to my image, I get a message saying that the "image could not be read". I wanted to see if I had the wrong path so I changed this path to something made up just to test. After this I get a message saying that the image is not found.

So, it seems that I do in fact have the correct path, and I have tried this earlier on my local machine without any problems (however in another folder). The issue occurred when I tried it on my server, and it fails to load all of the images in that folder. Has this anything to do with permissions on the folder or anything like that? Why can't I read the images?

Challe
  • 866
  • 12
  • 26

2 Answers2

0

Could be related to permissions. Is the application running in full trust? IIS application? Service? Try using the Local System user account - if it works then, it's a permission problem.

Could be a problem of the image format. PDFsharp relies on the operating system/framework to read the images. Switching from GDI+ build to WPF build or vice versa could make a difference.

An exception is caught in the routine "private void CalculateImageDimensions()". Maybe you can display the exception in a messagebox or save it in a file. That would help to identify what is going wrong.

0

I've faced the same problem with PDFSharp 1.32 version. The error occurs in ImageRenderer:

A generic error occurred in GDI+. 
 at System.Drawing.Image.Save(Stream stream, ImageCodecInfo encoder, EncoderParameters encoderParams)
 at PdfSharp.Pdf.Advanced.PdfImage.InitializeJpeg()
 at PdfSharp.Pdf.Advanced.PdfImage..ctor(PdfDocument document, XImage image)
 at PdfSharp.Pdf.Advanced.PdfImageTable.GetImage(XImage image)
 at PdfSharp.Pdf.PdfPage.GetImageName(XImage image)
 at PdfSharp.Drawing.Pdf.XGraphicsPdfRenderer.GetImageName(XImage image)
 at PdfSharp.Drawing.Pdf.XGraphicsPdfRenderer.Realize(XImage image)
 at PdfSharp.Drawing.Pdf.XGraphicsPdfRenderer.DrawImage(XImage image, XRect destRect, XRect srcRect, XGraphicsUnit srcUnit)
 at PdfSharp.Drawing.XGraphics.DrawImage(XImage image, XRect destRect, XRect srcRect, XGraphicsUnit srcUnit)
 at MigraDoc.Rendering.ImageRenderer.Render()

As I see in XImage.cs:241 the EXIF format is not officially supported:

case "{B96B3CB2-0728-11D3-9D7B-0000F81EF32E}":  // exif

default:
    throw new InvalidOperationException("Unsupported image format.");

Unfortunately GDI+ defines my exif format images as JPEG, so the expected case doesn't trigger.

Currently I didn't find any ideal solution for that. On developers forum (http://forum.pdfsharp.net/viewtopic.php?f=3&t=3304) you could find some more information about the similar problem. Seems like the problem occurs cause the image is saved using one of Adobe tools.

From other point - newer versions of Windows handle this correctly, this problem was only reproduced on Windows Server 2008 R2, so maybe an update could resolve the problem.

reflash
  • 1
  • 3
  • The exception occurs at `System.Drawing.Image.Save`, so it seems the place where the exception occurs is not related to the code snippet you show. We tried to implement all image formats for which we had image files - our collection did not include any files that return the EXIF id and it seems you don't have one either. The topic in the forum also seems unrelated as it is about CMYK images that are reported as RGB by the framework. – I liked the old Stack Overflow Aug 16 '16 at 11:20
  • @PDFsharpExpert, firstly I've made an assumption that the error occurs in CalculateImageDimensions, but the ImageRenderer also displays the "Image could not be read" in several other cases. Just check ImageRenderer.RenderFailureImage, in case when we get exception in Render function we get this message also displayed. I couldn't get any lists of supported formats, but images I try have EXIF header, so this should be the case where I should get "Unsupported format" – reflash Aug 16 '16 at 20:31
  • I assume the "exif" GUID can be used to save files in that format. I assume that the "jpeg" GUID will be returned when you open a file in EXIF format. If PDFsharp only sees the "jpeg" GUID, but never the "exif" GUID, then there is no need to implement "unreachable code". There can be problems using GDI+ on a server - the WPF build of PDFsharp could be the better choice in that case. – I liked the old Stack Overflow Aug 17 '16 at 09:46
  • @PDFsharpExpert Unfortunately for WPF build I get empty images instead of error message. So maybe the problem is not only in GDI+ lib – reflash Aug 17 '16 at 11:00
  • I implemented large parts of the image handling in PDFsharp and if I get an image file that is not supported by PDFsharp then I can look what is going on. – I liked the old Stack Overflow Aug 17 '16 at 11:16