(Kineme) PDF rendering on Billboard bug.

usefuldesign.au's picture

I've been tracking an bug for months now that I'm going to call a Kineme PDF Renderer bug. There's a chance it is just in the QC pipelines. It seems to be associated with multipage PDFs rather than one page PDFs.

Symptoms & things I've learnt about bug:

  1. the bug commonly appears as a 'white-out' of the image area on the billboard or sprite;
  2. the bug occassionally appears as a 'black-out' of the whole viewer on the billboard/sprite layer that is effected;
  3. the bug can appear as RAM noise/glitch;
  4. once the bug is 'on' comp can be run and stop countless times without the bug clearing;
  5. once the bug is 'on' comp QC can be Quit and Restarted without the bug clearing;
  6. the bug appears with no plugins or patches loaded (from any folder) except Kineme PDF Renderer;
  7. I may in the past have reproduced it in the Image Importer patch with extract all images using a multipage PDF but I can't repeat this and that may have occurred because:
  8. the bug can effect billboards in other compositions not using Kineme PDF Renderer in addition to any billboards/sprites in the compostion where a Kineme PDF render patch is;
  9. making the file via AI eps individual files and converting to multipage PDF in Acrobat still gets the bug
  10. I've tried every PDF standard known to the print world (not quite, but PDF1.3-1.7 with many output option combinations) and no discernible diff
  11. when you have an Editor window* partly over a Viewer window that is displaying the PDF image, even if the bug is not occuring in Viewer a glitching always occurs. Region of glitch/break-up being Editor Viewer rendering a PDF. (Hint?)
    *Editor is non-opaque so KinemeCore must be installed for this test;

Why it matters:

Wikipedia wrote:
Images are maintained in their native form for as long as possible before rasterizing for display. This means that it will keep vector images as vectors when cropping, scaling, rotating, or translating. This allows it to work with very large logical image dimensions without consuming large amounts of memory or processing time. Such functionality is most apparent when working with text-based images, or PDFs.

Despite such praise, PDFs from the image import defaults to a set resolution. When using bit map (TIFF, whatever) they scale up poorly when viewer size is increased (yuk interpolation). Less obvious is the fact that QC also scales down bitmaps poorly resulting in jaggies compared to an optimised image size. I guess mipmapping is a possible answer to this issue — only just thought of it.

Kineme PDF Renderer has dynamic resolution and therefore generally gives a much cleaner edge on line art at any Viewer size, even when just set to a high res output and just left there.

I tried a bunch of workarounds like loading single page PDF files into a queue from the Kineme PDF Renderer output but the bug eventually got me there too.

In the end I just queued the Kineme PDF Renderer output at a compromise resolution for typical display size. Made sure no bug. Then saved the file to a plist with Structure to File. Would love to see this bug ironed out! It's being wasting me ;-)

usefuldesign.au's picture
Re: (Kineme) PDF rendering on Billboard bug.

PreviewAttachmentSize
Picture 36.png
Picture 36.png65.16 KB
Picture 35.png
Picture 35.png303.16 KB
Picture 19.png
Picture 19.png83.67 KB
Picture 20.png
Picture 20.png89.71 KB
Picture 21.png
Picture 21.png37.98 KB
Picture 23.png
Picture 23.png39.71 KB
PDF Renderer bug demo.zip51.73 KB

gtoledo3's picture
Re: (Kineme) PDF rendering on Billboard bug.

It looks like your pdf uses transparency, so I'm thinking that the layers aren't flattened (despite it saying that it's 1.3). I have an older pdf tester that can't deal with that, and it crashes when looking at your file.

I don't know if the kineme pdf patch is supposed to deal with that or not. I know that OS X itself doesn't deal with it well (comments, markups, non flattened images, all don't necessarily render or render correctly, or some mix). If you have Adobe Pro then try to use the flattening tool that is in it's preflighting tools, as it seems to catch things that the CS4 doesn't for some reason. Every once in a blue moon I've seen someone prepping a file that looks like they've done the correct thing in CS4, and then have it have some kind of incompatible info that needs to be flattened out still, which has been solved through using Adobe Pro.

When you do your export, merge or flatten layers, and see if that gets rid of your bug. I don't have CS4 or any Adobe products on my computer to pull it in and and make sure it's flattened.

usefuldesign.au's picture
Re: (Kineme) PDF rendering on Billboard bug.

Thanks for the comments George, taken me a while to get back to things QC…

There is no transparency (if as you said it's PDF 1.3, that format doesn't know transparency, I tried every version 1.3-1.7). What there is, is a non-printing black layer which doesn't show in Preview.app so I can read the objects in Illustrator. Objects are simple straight line polygons coloured white at 100% opacity so I can colour and alpha fade in QC. In Preview all you see is white on white ;-). Maybe the non-print layer is a issue for the other older app you tried to open it in. Also Illustrator artboards should get interpreted as pages in regular PDF parsing apps but I've since found out the artboard implementation in CS4 is ever so slightly iffy (whole 'nother story) so that is a minor possibility for your older app.

See attached for all-printing-layers PDF and comp with same error.

As for the greater issue of Transparency being an issue for a PDF app or PDF plugin, interpreting transparency is really a must. I would expect a PDF plugin to parse the latest PDF standard above the earliest and in fact it seems to parse them all. PDF being native on OS X I'm sure it's well supported in Cocoa.

The whole print world shifted from .eps files to pdf chiefly because postscript has no transparency definition and flattening files sucks big time. (Adobe is pushing the better printer and RIP manufacturers to use their PDF engine instead of or along side the PS engine because it makes so much sense to keep transparency native all the way down the workflow).

PreviewAttachmentSize
Nail that BB bug II.zip15.12 KB