Print to pdf question

[dunbarx]

When I open a large CAD file saved as a pdf in Acrobat Reader, the drawing renders very quickly. But when I render a much smaller and simpler pdf file created with the "print to pdf" command in LC, that drawing, though far less complex with far fewer elements, takes a couple of seconds.

Is there something about the "print to pdf" command in LC? Is there something about the objects in LC?

Craig Newman

[Mikey]

Craig,
Are your CAD files scanned, or created directly by someone's software? Are they solid models are full-blown dimensioned drawings with each element spec'd separately? The first and second will render very quickly. We almost never see the third, because those take FOREVER to render, and people tend to break them. Especially in D and E size prints, we almost never get one that isn't scanned.

[dunbarx]

Mikey.

I was talking about an ordinary AutoCad or SolidWorks drawing. Either might have many hundreds of vector graphic elements. When these are saved as a pdf, that pdf will open very quickly in Acrobat Reader.

But a card in LC, with perhaps a hundred fields and vector graphics takes much longer to render. And that process is visually incremental, in that a blank page opens, and then the elements are drawn from the top down in sequence. Oddly, on a Mac, the "Preview" app will be silent for about a second or two, and then the entire completed drawing simply pops up. Same interval, just a different visual procedure.

None of this is a deal killer. The project I am building can wait the two or three seconds it takes to render the single card I have "printed" to pdf. I was just wondering if, since this I am still in v. 6.7, whether there was an issue with an "older" version of the gadget that actually prints to pdf, or whether there was something about LC controls and graphics themselves that required extra time.

Craig

[Mikey]

What I meant was are you sure that the individual elements are still in there and not converted to paths, first? I'm more curious than anything else.

[FourthWorld]

I just did a quick test to see what gets generated as vectors and what becomes rasterized. I made a stack with four buttons of "standard" style, two fields, and several graphic objects.

In the resulting PDF the text is selectable, so clearly that comes across as we'd expect.

I zoomed in to 400% to get a close look at edges of the objects.

Buttons appear to be rasterized, judging from visible pixelation at the rounded corners, likely needed since AFAIK LC lets the OS render the button shapes, and includes the OS-delivered shape in its compositing.

Graphic objects, however, have no discernible pixilation; no matter how far I zoom in, pixels appear to be re-rendered at my screen's full resolution, suggesting those are stored as vector instructions within the PDF.

Then I applied some effects to the graphic objects (inner glow, outer glow, dropshadow), and in the resulting PDF it seems those objects became rasterized, with visible pixels on angles and rounded shapes when I zoom in on them. That seems reasonable enough, since Skia is a screen-rendering system but not a Postscript system, so without a direct means of translating graphic effects to Postscript instructions the only option is to rasterize.

All in all, not bad. The things it can affordably keep as vectors it does, and the rest are rasterized.

I haven't generate large multi-page documents as PDF yet; my single-page quickie opens up instantly.

Craig, how many pages were in your PDF that took a few seconds to load?

[dunbarx]

@ Mikey.

I am not sure I understand your question. The drawings we use are "commonplace", that is, they contain objects created within, say, SolidWorks, as text objects, lines and rectangles, those usual sorts of things. Very few Bezier or other curved gadgets.

All are created by hand using the palette of tools one sees attached to such software, and a mouse. In other words, er, ordinary. These are saved and exported as pdf files from functionality native to the CAD program itself.

@Richard,

Yipes, Thanks for taking an interest down to that level.

I am talking about a single card printed to pdf, though a handful cards will eventually be required.

When I get back to my office, I will make some tests with a single class of objects to see if anything changes. A card with 100 fields, then a card with 100 rectangle graphics, etc. I will compare with CAD drawings of similar object classes and quantities.

I assumed that everyone prints to pdf, though I just started to. I do not know, but would love to, what is expected in terms of rendering time. This because a 50 page pdf might indeed be a deal killer, unless there are way to optimize somehow. At the very least, to know what object classes might take more time than others, if indeed that is an issue at all.

Craig

[richmond62]

At the risk of sounding goofy I want to mention here an experience I had about 2 years ago.

My wife started work on a PhD while we were living in the United Arab Emirates in about 1998;
she did the work on a Macintosh running Mac OS 8. In the end she had some sort of a "fight"
with her thesis supervisor (in Bulgaria) and abandoned the thing (going on to get a PhD from
St Andrews in Scotland).

About 2 years ago I found the remnants of my wife's work on a ZIP disk in PDF format.
Now these PDFs contained all sorts of stuff written in Old Church Slavic written with the aid of
a font [ Kotlenski.ttf ] I made for her. But as PDFs made on Mac OS 8 were really nothing more than
glorified pictures (no embedded text layers) they rendered on her MacBook Air very quickly indeed
(but, of course, there was no way to copy paste from them).

I also found some later versions of the same work my wife had been toying with in 2006 on
Mac OS 10.4 which had, again, been saved as PDF documents: they took far longer to render
because of the embedded text layer.