Lulu Developer Forums

API Development Community

RSS Feed

Full Bleed + Cover Creation Question

  1. Hi all,

    I'm back again with another mind-bending question! Hopefully someone here is able to provide some assistance...

    When increasing the size of your "content" PDF by 0.25 so that your book has full bleed, do I need to do the same for my front cover?

    I'm printing a book that's 8.5 x 8.5 with full bleed. After reading information from this page I increased the size of my "content" pdf to be 8.75 x 8.75.

    I also increased the size of my cover to be 17.499 x 8.75. The width was calculated from the sum of 8.5 x 2 (width of book multiplied by 2), 0.249 (width of spine calculated here) and 0.25 (additional width required for full bleed).

    Is this correct?

    Message edited by Soap Creative 2 years ago

    Tags

  2. Josiah Gore – 2 years ago

    That sounds right. Whatever size the calculator indicates is appropriate, you should be able to add up to .25" to that in order to ensure that the color runs to the edge.

  3. Soap Creative – 2 years ago

    Unfortunately, it doesn't look like adding 0.25" is correct. When I add my PDF, I get the following error:

    1. stdClass Object
    2. (
    3.     [error_value] => Your cover file is 1224 points wide by 630 points high, but these are not the right dimensions. Your cover should be uploaded at 1368 x 738 points.
    4.     [error_type] => LApiPublishInvalidDocumentException
    5. )

    When I upload a PDF with the size requested above, I then get the following error:

    1. stdClass Object
    2. (
    3.     [error_value] => Error creating cover image representation, Error creating front cover image thumbnail
    4.     [error_type] => LApiPublishInvalidDocumentException
    5. )

    I've got no idea where to begin looking to resolve this issue... My PDF files seem to be fine. I can view locally, upload and download from the Lulu servers. I've even fed the "content" and "cover" pdf into the converter API... They converted correctly, but one I tried to publish, I got the 2 errors above...

    Is this issue more to do with server load? Or are my PDF's to blame?

    • Ivan.

  4. Josiah Gore – 2 years ago

    Hmm, not sure what would be causing that second error. If you want to email the file to api at lulu dot com, I can try to duplicate the error and try to find its cause.

  5. Soap Creative – 2 years ago

    Thanks Josiah, that would be great. I'm sending the files now (they are pretty large though).

  6. Josiah Gore – 2 years ago

    I've just seen your files and I am looking into it now. Thanks for bearing with me.

  7. Josiah Gore – 2 years ago

    If I attempt to create using those files, I get the opposite size problem that you encountered:

    "error_type": "LApiPublishInvalidDocumentException", "error_value": "Your cover file is 1368 points wide by 738 points high, but these are not the right dimensions. Your cover should be uploaded at 1248.98 x 630 points."

    What are you using as the options for the physical attributes? I have believe I have attempted all of the supported 8.5x8.5 books. The error above came from attempting with:

    "project_type": "softcover", "physical_attributes": {"color": true, "trim_size": "LARGE_SQUARE", "binding_type": "perfect", "paper_type": "premium"}

    When I created a cover of the size suggested in the error message, I was able to successfully create the book using that cover PDF.

  8. Soap Creative – 2 years ago

    Hi Josiah, I'm using the following physical attributes:

    1. $physicalAttributes = '{
    2.  "color": true,
    3.  "trim_size": "LARGE_SQUARE",
    4.  "binding_type": "casewrap-hardcover",
    5.  "paper_type": "premium"
    6. }';

    I've sent an email to api at lulu dot com that includes new PDF files plus a image of how I've calculated the size of the cover... I'm at a complete loss to what is wrong, I'm hoping it's a minor issue and apologise if it's something very obvious.

  9. Soap Creative – 2 years ago

    Hi Josiah, I've "resolved" the issues I was having after pulling out what little hair I have left. Hopefully this information will prove useful for other people in the future.

    1. A full-bleed cover for a hard-cover book not only needs an additional 0.25" for the "bleed", but also an additional 1.5" for "turn-in bleed" (go here for more info), this is why I was getting the following error:
    1. stdClass Object
    2. (
    3.     [error_value] => Your cover file is 1224 points wide by 630 points high, but these are not the right dimensions. Your cover should be uploaded at 1368 x 738 points.
    4.     [error_type] => LApiPublishInvalidDocumentException
    5. )
    1. For whatever reason Lulu doesn't like my cover pdf. I'm using TCPDF and PHP to generate my pdf files and each time try to publish a book with the files I create, I get the following error:
    1. stdClass Object
    2. (
    3.     [error_value] => Error creating cover image representation, Error creating front cover image thumbnail
    4.     [error_type] => LApiPublishInvalidDocumentException
    5. )

    If I upload my cover PNG file to Lulu and convert it to a PDF with the Convert API, my book publishes perfectly. I'm not sure of the exact reason, but this workaround will get me over the line.

    If anyone is able to shed some light as to why I would be getting the LApiPublishInvalidDocumentException error, it would be greatly appreciated.

  10. Josiah Gore – 2 years ago

    Using the new set of files that you emailed us, I was able to reproduce the "Error creating cover image representation, Error creating front cover image thumbnail" error in a sandbox environment. This is caused by an error occurring when attempting to rip the PDF into an image file using ghostscript. Running that command directly resulted in the following error:

    1. gs -q -dBATCH -dSAFER -dMaxBitmap=500000000 -dNOPAUSE -dAlignToPixels=0 -dUseCropBox -sDEVICE=jpeg -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -g1258x630 -r72x72  -dJPEGQ=100 -sOutputFile=cover.jpg -fcover.pdf 2>&1
    2. Error: /undefined in findresource
    3. Operand stack:
    4.    --dict:14/23(L)--   F1   12.0   --dict:6/6(L)--   --dict:6/6(L)--   ArialUnicodeMS-UniJIS-UTF16-H   --dict:10/12(ro)(G)--   --nostringval--   CIDFontObject   --dict:7/7(L)--   --dict:7/7(L)--   Adobe-Japan1
    5. Execution stack:
    6.    %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1878   1   3   %oparray_pop   1877   1   3   %oparray_pop   1861   1   3   %oparray_pop   --nostringval--   --nostringval--   2   1   1   --nostringval--   %for_pos_int_continue   --nostringval--   --nostringval--   --nostringval--   --nostringval--   %array_continue   --nostringval--   false   1   %stopped_push   --nostringval--   %loop_continue   --nostringval--   --nostringval--   --nostringval--   --nostringval--   --nostringval--   --nostringval--   %array_continue   --nostringval--   --nostringval--   --nostringval--   --nostringval--   --nostringval--   %loop_continue
    7. Dictionary stack:
    8.    --dict:1162/1684(ro)(G)--   --dict:1/20(G)--   --dict:75/200(L)--   --dict:75/200(L)--   --dict:108/127(ro)(G)--   --dict:288/300(ro)(G)--   --dict:22/25(L)--   --dict:6/8(L)--   --dict:26/40(L)--
    9. Current allocation mode is local
    10. Last OS error: 2
    11. GPL Ghostscript 8.71: Unrecoverable error, exit code 1

    It is hard to know for sure that that is the error that was encountered in production, as it is getting swallowed by the application, but it likely is. This seems to indicate the use of an unembedded font for which there is no fallback. Running this same command on a machine with japanese fonts installed worked without error.

    Does this provide any clues as to what is causing the error?

[ Page 1 of 1 ]

Please sign in to add a post.