Unfit for Prepress

[nresnik]

If only Designer would get

- decent Pantone implementation,
- selecting by attributes,
- decent printing options for drawings exceeding printer size
- Lock/hide/unlock/show option outside the layer pallette,

I wouldn't think of Adobe products again for pro work.
Until then, we in our design studio are stuck with Adobe.
The Developers should better address those issues for PRO PREPRESS users, otherwise Designer is going the way Inkscape is now.. close-but-no-cigar state, unfit for PRO PREPRESS work just because of a few minor missing, but crucial fetures.
I think that for the time being, the developers have been too concertrated on web interface designers. No offence to nobody, but graphic design WITH prepress is lightyears more challenging, and prepress people WILL pay for a good Ai alternative.
Designer is almost there and I think that it is just plain stupid to ignore the prepress features in favour to some nice gimmicks.
If you remember, Freehand and Quark were so much used not because of their gimmicks, but because of their robustness.
 

[MikeW]

1) Pantone implementation. I have my own thoughts about the swatches in general, but what do you see wrong with the current Pantone implementation?

 

2) Selecting by Attributes. Yep, that would be beneficial for users. How exactly does that aid in "Pro Prepress" work?

 

3) Decent printing options for drawings exceeding printer size. I worked prepress for a number of years. I never used the in-application printing process. How does that aid in "Pro Prepress" work?

 

4) Lock/hide/unlock/show option... Again, how is this an aid in "Pro Prepress" work?

 

I'm not saying that there ought not be a better prepress work-flow, I just don't understand the list in relation to professional prepress.

[Fixx]

I haven't done real PRO PREPRESS work but a few days, more in the preprepress, but.

 

2. Select all rich black elements, change to K100. 

3. Yes, more often it is printing PDF with some dedicated application. AD should have more robust PDF export. None of this "rasterize everything that touches pixel element" stuff. InDesign had this right right from the beginning. (I should test if AD CAN print better quality right from the app, but somehow I think same restrictions apply as in PDF export.)

4. There is cmd-L and cmd-shift-L. No shortcut for hiding though. Yes, this has to do with selecting elements when there are a lot of them bunched together. Lock the ones that must stay as they are, select and troubleshoot the rest.

[MikeW]

In pre-press, I would desire to change small text formatted as rich black (i.e., sub 11 point text). Select Same function in Illy is great for that and while not for pre-press work per se, I would welcome Illy's Select options. But I would opt to use Acrobat or Pitstop for this as in all likelihood. If I were still in pre-press work I am going to get a PDF and it's been that way for the majority of work since the mid-1990s.

 

Depending upon the client and/or the press-up time, the sales rep would have just communicated with the client to re-submit the work and why. It's not that we didn't get original files, we did and do. But they are not and have not been the majority of file types since the year 2000 where I have worked.

 

I have mixed feelings about AD's PDF export. I do want Serif to advance its PDF exporting (and importing for that matter). But in the end, the RIP is going to convert everything to a bitmap even if plain type is held off until the end of the rasterization process. So ultimately as long as the rasterization in the PDF is good, so is the print.

 

But the PDF thing wasn't listed in the OP's complaint.

 

I also don't think that locking has much to do with pre-press. It is a work-flow issue for the designer. Just how many pre-press shops are (1) going to get AD native files, and (2) have AD to deal with them? AD doesn't have a Package or Collect for output command. Which means even if people desired for a service bureau to deal with native AD files, they will need to at least gather the fonts used. As well, once linking is involved, they are going to need to gather any linked resources.

 

Dealing with native files is all well and good for a service bureau. But I reckon most printing today is done via automated services. One better understand what they are designing and why because if the PDF is not rejected for an error on the part of the designer, it is going to print that error.

 

There is a real list for professional pre-press floating around in this section somewhere. While I didn't necessarily agree with all of it, it was a real list for an in-application pre-flight and features for the do-it-yourself pre-press stuff.

 

But this list isn't.

[MikeW]

Heck, I'll take advantage of the forum double-posting my reply...because I didn't finish my last though. I ended with:

 

But this list isn't.

 

This list and your thoughts, Fixx, are really about work-flow, in-application stuff. Not about the requirements of professional pre-press.

[Fixx]

OK, prepress would not touch in-application files too much. It is mostly dealing with PDF files. AD though could be a tool to modify incoming PDF files.

 

the sales rep would have just communicated with the client to re-submit the work and why

 

well.. no. Usually prepress just silently fixes files and assures customer everything is ok.

 

 

Seems there is some ambiguity what is prepress and what is production. I don't know if this is a problem though. I think there is still some improvements to be made before we can say we have a robust tool for creating print ready art in AD.

[MikeW]

We still don't know what the OP really means...

 

The prepress departments I have worked in did fix some issues without notifying the client(s) involved. But what we wouldn't do is second guess the designer's intention. So even for rich blacks on smaller text, we would send an email or call the appropriate rep, who would in turn contact the client and inquire. If the fix was approved by the client, and only if approved by the client, would we run the fix. In no way would we fix something that was not approved. Else if the job went south we were left paying for the job. Most often the client would resubmit new PDFs.

 

Production jobs, we did those too (a different department). And those jobs went through the same scrutiny and once in a blue moon, those too were rejected for some reason and the designer--though an in-house designer--redid what was wrong and resubmitted them just like everyone else.

 

I can understand the need for certain prepress things. Dunno if AD, APub or APh will ever get them, though. One would be a truly color managed separation preview. The ability to map inks and spots, control screen angles, traps for non-PDF work-flows, maybe even imposition, etc., etc. (Imposition will always be best left to a dedicated imposition solution, though I can see why people may want it.)

 

But some vague notion as expressed by the OP of "decent Pantone implementation" isn't "prepress." Of the 4 items listed, only one even is vaguely a prepress thing (the whole direct printing using a tiled format), but even it isn't really a prepress thing--produce a PDF and tile it from Acrobat. Pantone works in AD, but I think the notion of swatches needs rethought and implemented better. Locking, hiding, etc.,  and selection by attributes are simply production issues and those things have been requested and should be added to AD et al.

 

So yeah, pre-press and production are separate things and attention definitely needs paid to the production/work-flow features in Serif software. Whether it is beyond the purview of the software as regards pre-press is up to Serif though it never hurts to ask for these things.

Imposition will always be best left to a dedicated imposition solution, though I can see why people may want it.