Save to PDF broken -> segmentation fault #215

Closed
angelnu opened this Issue May 11, 2013 · 3 comments

Comments

Projects
None yet
2 participants
@angelnu

angelnu commented May 11, 2013

Hi,

with the pillow version included in Ubuntu 13.04 (2.0.0) I get a segmentation fault with the following code:

from PIL import Image
im = Image.new("L",(10,10))
im.save("test.pdf")

After some debuging I think that the bug was introduced with the commit from 13-03-06 to add qtables support to the JPEG encoder. The code there assumes that the parameter qtables in PyImaging_JpegEncoderNew is set. This is not true when calling ImageFile directly (as the PDF plugin does).

My recommend fix would be setting the qtables local variable to NULL and then checking in get_qtables_arrays that the passed parameter is not NULL (in addition to the Py_None check)

Best regards,
Angel

@aclark4life

This comment has been minimized.

Show comment
Hide comment
@aclark4life

aclark4life May 11, 2013

Member

Thanks, can you send a pull request with those changes?

Member

aclark4life commented May 11, 2013

Thanks, can you send a pull request with those changes?

@angelnu

This comment has been minimized.

Show comment
Hide comment
@angelnu

angelnu May 12, 2013

With the fix my example works. On the other hand it might be a better idea to pass the JPEG settings to the encoder when saving the image embedded in the PDF. This would require exporting the code in PIL.JpegImagePlugin._save that sets im.encoderconfig. What do you think?

angelnu commented May 12, 2013

With the fix my example works. On the other hand it might be a better idea to pass the JPEG settings to the encoder when saving the image embedded in the PDF. This would require exporting the code in PIL.JpegImagePlugin._save that sets im.encoderconfig. What do you think?

@aclark4life

This comment has been minimized.

Show comment
Hide comment
@aclark4life

aclark4life May 12, 2013

Member

"better" how? I don't have a preference. If it's "cleaner" that way with no other changes (or risks) then feel free to fix

Member

aclark4life commented May 12, 2013

"better" how? I don't have a preference. If it's "cleaner" that way with no other changes (or risks) then feel free to fix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment