Thank you for understanding. It's been nice virtually dealing with you.

Let's hope the dev team look at this and thinks it's a good idea to progress with.

I can understand the desire for a simplified workflow. I self-implemented something for myself that is conceptually similar a few years ago, if not functionally the same, using PDF exports from Illustrator while retaining the illustrator format working files.

I just had a set of actions set up on a F5-F9 keys to save out a PDF with a specific set of joboptions with a single keystroke. However they all save out to one location and then need to be manually filed/placed into whatever location our automation needs to look for them.

This doesn't work all that well for you though, if you're editing files and saving them in the location where the workflows need to access them. It's ideal for our processes because it's critical we have some means of version tracking various art and production files.

As far as this issue goes, it looks like I suspected. It's just how illustrator writes PDF data structures for objects. I'm not sure there's a workaround, Adobe devs would need to change how illustrator creates PDF data.

The reason why the PDF shell is because as long as you have compatible turned on you can just keep working in Illustrator and then just save the file, once this is done Esko is connected to your servers and folders so you can see your file and just run the workflows.

If you were going to export a PDF, you would be working in Illustrator, then finish your work, then have to export out as a PDF to run your workflows.

The software is set up to be process driven so the first way does this, the second way is not process driven at all. By the way I get the same problem when exporting out as a PDF as well.

Here are some images to show you how the Illustrator file looks compared to what the PDF shell looks like.

Sure I'll take a look.

General question, since I've only heard of Esko software but never used it. Is there a reason why you don't just use PDF's rather than PDF-compatible illustrator files?

Honestly I'm thinking your issue with it is mostly down to how illustrator creates PDF object structures and data. It's... not the best. In that light, I think the request is a very valid one.

Around here, we use PDFtoolbox. I cannot count the number of times I've had a facepalm moment when analyzing illustrator's PDFs in PDFtoolbox. This is a good example of one; the PDF standard clearly has object/data structures for stroked text but Illustrator doesn't use them.

The reason why we use the PDF shell of the Illustrator file is because of a packaging application the industry uses called Esko Automation Engine. We do all our work in Illustrator and then save the file with compatible turned on. We then use Esko AE to run workflows and for this to happen it uses the PDF shell.

Would you like me to send you the file in question, so you can see how the text is made up? I will not be able to send you the fonts but a least you can see how the text is done?

*** update ***
Kind of answered my own question, regarding how illustrator saves PDF's vs other applications.
InDesign saves stroked text as a text object with a stroke, rather than illustrator's way of saving the text object separately from a stroked vector copy of the glyps. See screenshot 3.

Do you have a means of verifying or testing this? I can't think of a way to do so.

Note that I am somewhat skeptical only because I know the PDF format itself retains live strokes(1,2) so I don't know why PDF compatibility wouldn't do the same.

1. if they're applied to a vector object *and* center-aligned, not if they're aligned inside or outside of a vector object (which cannot be done on live text). Inside or outside aligned strokes are converted to compound shapes in the PDF.

2. text objects remain live (not outlined) but the stroke is split off into separate vector objects of the glyphs which have a live stroke. The text itself is not stroked in a PDF. see screenshot.

Also note in the 2nd screenshot that the text glyphs themselves do not have a stroke in the PDF. I'm not sure if this is just an illustrator thing, but PDF's saved from illustrator with live text having a stroke applied do not preflight as stroked text. It might just be how illustrator saves PDFs.

I'm uncertain how this all relates to "PDF compatibility" though. I know that a PDF saved in illustrator while retaining illustrator editing capabilities has the illustrator file data embedded in the PDF as private data that is not readable by anything but illustrator.

Hi Lance, It does. The pdf shell of the Illustrator file converts the stroke of the text to outline while keeping the main body of the text live.

I'm not sure I understand this request. As far as I know, enabling PDF compatibility on an illustrator document when saving it doesn't outline text or strokes.